1. Introduction.

High-level design involves making important architectural decisions. Previous design stages should have provided a clear overall context for the product, and the projected content should have been specified. The analysis of the content should have provided a set of natural divisions which will help determine the structure of the product (expressed in the thematic/conceptual map), and go some way towards establishing a navigation model. It should also have have determined the range of media needed to represent the content (expressed in the prototype asset list). Important technological decisions have to be made at this point. The overall context should have established a product concept, which includes a general view of the kind of implementation technologies envisaged; but this must now be specified precisely - and content mapped onto specific technologies.

Make sure that you have a detailed idea of the content you require, and that you have organised this by a set of progressively more detailed thematic maps and storyboards. You shouldn't yet have developed a final storyboard - this will happen below - but you should have a good idea of the structure and flow you require.

2. Overview of Activities.

High-level design involves:

1. Establishing the architecture of the product, as a set of structural units which can be developed in relative isolation (respecting the important principle of modularity). This will be based on natural conceptual divisions in the content; but may also be based on divisions forced by differences in implementation technology.
2. Establishing a coherent and comprehensible navigation model: a refinement of the thematic/conceptual map which takes into account the properties of the implementation technologies, and the need which the user has to envisage and move through an understandable structure.
3. Establishing a design style ('look and feel', design aesthetic) which is appropriate to the content and to the way in which it is presented to the user.
4. Making a precise statement of the implementation and delivery technologies for the product and mapping the content onto these technologies.

These activities cannot really be done in the order set out above, since they are heavily interdependent. Rather the designer has to hold our three basic dimensions of any multimedia product (technical, cognitive, aesthetic) in his/her mind at once; and to produce solutions in all three dimensions which interlock and work together.

3. Architecture.

In general, multimedia product development is content-driven: the structure of the product corresponds to natural divisions in the content. A web site is divided into sub-webs which deal with different themes; an animation is broken into scenes which convey different ideas; a multimedia database divides its content into different tables; a multimedia encyclopedia is broken up into the different branches of human knowledge along well-established lines; etc. Each of these different structural units, once they have been defined, can be developed in relative isolation - probably by different development teams. Such a product can be said to have a modular architecture.

Modular system architecture is important for two reasons. Firstly, as indicated above, different modules can be developed by (relatively) independent teams working to a specification prepared by the system designer. Secondly, modular architectures are usually easier to test and correct; and hence are more robust in operation.

Static system architecture can be represented by refining the thematic/conceptual map of the content into a definitive structural diagram for the product; this diagram should only show major units - low level design will break these up into their smallest constituents. For example, a structural diagram of a departmental web site may only need to show that there will be a 'personnel' section giving cv's and contact details for all staff; it may be left to low-level design to decide how this splits up into smaller units - by staff member, by job function, etc.

Dynamic system architecture (for time-based applications, or time-based components of applications) can be represented by overview storyboards which are refinements of those drawn to represent content. These should now give a fairly precise idea of the scene structure of the content, detailing major features of each scene - sufficient for low-level design to flesh these out into frame-by-frame storyboards.

With your target technology(ies) in mind, break your content and outline storyboards down into relatively independent functional units - these may be web pages, animation scenes, etc. In a complex application this will be done hierarchically - major units will break down into sub-units, etc. For our small example we probably don't need such a hierarchy. At this stage you will probably have a set of boxes with items of content laid out in the approximate appearance you want.

4. Navigation Model.

What a modular architecture takes apart, a navigation model puts back together. A user wishes to experience a multimedia product as an understandable and coherent whole, around which they can move with ease. A good navigation model should embody a strong organising idea (often a metaphor, but other rhetorical tropes may also play a part - e.g. metonym and synecdoche) and effective means to move through content. Clearly a good navigation model and a content-driven modular architecture are closely related and should be developed together. As an example, consider the way in which the National Gallery's 'Micro Gallery' uses the common art-historical labels of 'period' (time-line), 'significant artist' and 'cultural centre' (map) to give alternative access routes to a common database of art works ... the navigation is intuitive for anyone conversant with art history, and the underlying structure is technically robust.

At the stage of high-level design a navigation model need only be established as an organising idea, a set of design guidelines (colour codings, common menus, etc.) and a set of links between the structural components of the product - precise screen layouts, placement of buttons, text, etc. can wait until low-level design to be finalised.

Develop a navigation model: decide how your major units are linked together and invent a mechanism which takes you from one to the other, allocate some area of layout to your navigation, but don't be too rigid or precise yet. We're still working at a high level and things might change as we progress.

5. Design Style.

During high-level design broad parameters can be set down which determine an overall style for a product. These can range from indicating the kind of graphic design influences which will determine the 'look and feel' of the product, to determining overall colour schemes. A design style can be specified by citing design 'schools' whose approach will be copied (see, e.g. Hollis, R., 1994, Graphic Design: A Concise History, Thames and Hudson), or by showing particular posters, adverts or web pages to be emulated. This will probably help determine fonts and palettes, screen layout and 'balance' (image, text and space ratios) and the way in which images are to be treated. These stylistic decisions might be summed up as a set of design guidelines (expressed as do's and dont's), or as a set of prototype screen designs which won't necessarily be final screens which make their way into the product, but which serve as examples to be adapted later in the design process. The design of utilitarian multimedia (e.g. intranet pages to help internal company communication) can be constrained by simple guidelines; more creative applications require more subtle guidance.

This aspect of design is difficult to formalise, but don't leave design ideas in your head. Try and get something down on paper or screen which sums up your graphic design approach, animation or video shooting style, etc.

6. Technology.

During high-level design it is necessary to determine:

• The major implementation technologies which will be used. The tools chosen will shape the final product and hence constrain the production process, since low-level design will have to take into consideration what can and cannot be done with the project tools. Auxiliary technologies, i.e. those which will be used to prepare minor components, needn't necessarily be specified (e.g. does it matter which paint/photo tool is used to prepare an image? - probably not).
• The formats in which content will be packaged. Multimedia products are usually hybrids of different formats - e.g. a web site may contain simple HTML pages with text and images, embedded QT movies, embedded Shockwave and Flash, database access via ASP, etc. Strategic decisions have to be taken about which areas of content will be packaged in which formats, and how all of these are to be orchestrated.
• The impact which the delivery mechanism has on design. Distributing multimedia on a cd rom, a local area network and a wide area network give rise to very different design problems, since the time/quality trade-offs are very different in each of these situations. A careful analysis of the delivery mechanism will place constraints on low-level design, and the setting of project rules for file sizes for different formats and the amount of work which must go into compression and optimisation.

On a large project, such considerations usually give rise to well-documented project standards on coding and content preparation to which all team members must adhere. An experienced team will usually have 'off the shelf' standards for different types of project.

The content detailed in the prototype asset list will have to be mapped onto the tools and formats which will be used to prepare it. This gives rise to a more detailed asset list, showing content, type of representation, preparation tool and format.

Try and make a precise statement of your development and delivery technologies. Bear in mind that you will have to learn any tool you aren't already familiar with - so try and keep to a basic tool set.