Reading: Design a Prototype Multimedia Product

Reading: Design a prototype multimedia product

Design a prototype multimedia product

Inside this reading

Prototype design

Aesthetics—find the right measure

Costing

Design models

Stages of design

Methodologies in general

Ensure feedback and collaboration in development

Prototyping methods—ongoing creation of working models

Multimedia design issues

Project size

Delivery options and end-user machines

Intrinsic and extrinsic motivation

Nature of content and information design

Nature of elements

Prototyping—scheduling and sequence

Scheduling

Sequence of events

Summary

Progress

Prototype design

When the client and developer agree to a multimedia project (to create a product that will solve a problem or enhance a process), the next step is to author a small working prototype.

This is when the developer moves to their computer and starts building demonstration screens with working menus, buttons, video clips, sound files and functional navigation. The prototype can now also help highlight any problems with functions or features that may not have been foreseen.

Often the developer selects one module of the project and completes the key screens to show the client how it will work. The client can then test the system in ‘real terms’ not just on paper. Remember also that some clients will have limited experience with multimedia—it is difficult for them to sign off on design and development aspects they don’t fully understand. The prototype can clearly demonstrate the model and design of the final product.

Aesthetics—find the right measure

The prototype doesn’t necessarily have to look ‘pretty’—the most important thing is functionality. Unfortunately with many projects, too much time is spent on aesthetics.

Aesthetics do have a place. The developer may be trying, while building a skeletal working model, to convince the client to sign-off at that stage or to elicit positive comments from the client. The sad reality is that is a program looks unprofessional, some of the user focus group may consider the whole project in that light. Some balance is necessary, while not overdoing efforts on design aesthetics to the detriment of function. If a small amount of graphic work and a few fancy animation elements are needed, so be it!

Costing

Until the prototype is built, working, evaluated and the scope document is signed, the developer generally has been guessing at the size and complexity of the project. Many developers actually charge clients on a component basis. For example, they seek separate and individual payments for initial analysis, prototype design, assembling media, development, implementation and then final handover.

Charging on a component basis may be wise, for instance, if the prototype reveals major technical or user expectation hurdles, and increased funding is then needed. The opposite would apply if the development process were minimised or became easier.

Repackaging considerations

Some clients will be aware of what developers are sometimes able to do in regard to building a product for one client, then basically changing the name and on-selling it to others. Dissembling as to the originality of the product is to no-one’s advantage and could guarantee a short career.

More meaningfully, careful negotiations must always be considered in regards the true production price of multimedia development, as it often decreases with every title.

Design models

There is no one method or guaranteed way to produce the perfect product in all circumstances. Even in the world of large-scale software production, as with smaller scale developments, there are many engineering models. In the end, however, most of them come down to common sense.

There are many different software development methodologies including:

Waterfall model
Spiral model
V-model
Joint application design
Extreme programming
Rational unified process
Feature driven development
Dynamic systems development method.

Some paths are less treacherous. Keep in mind that the full rigour of some models, with their intricate flow charts and formatted documentation, is clearly inappropriate for small-scale software production. Any attempt to slavishly follow such models would lose the small-scale developer the main advantage of being small, namely flexibility in being able to adapt and improvise. Certain ‘templates’ for doing things will derive from experience.

Stages of design

Commonly the five stages of multimedia development (also known by most IT professionals as the software lifecycle) are:

1Analysis / 3Development / 5Evaluation
2Design / 4Implementation

Some developers use other models (some more detailed, some less)—the main idea is that the concepts should help to clarify the big picture by breaking it up into chunks. The lifecycle model should also encourage developers to be systematic.

Methodologies in general

Whatever software is being developed, there are some important processes or aspects of methodology that should be kept in mind at all times.

Step by step development—common pitfalls

This is when a developer starts from the original conception of the software, adding increasing detail to the project until the level of detail necessary for implementation has been achieved. This methodology has obvious flaws.

In reality, when planning a project you must first look at the big picture and then add detail step by step.

While this may seem obvious, it is all too common for developers to start at the level of detail and work up. They may have a loose idea of the final product and some of the functions it should have. To then proceed to author or code functions without fitting them into an overall project is foolish.

Many untrained programmers take this approach, which is akin to designing an aeroplane by starting at the wheels. It results in increasingly patched-up software, as new functions written necessitate tinkering with the code in older functions. The result is an unstable mishmash of ill-fitting functions and ad hoc patches ready to fall over at the slightest provocation.

Ensure feedback and collaboration in development

Multimedia development is not a one-way process with arrows going west through a flowchart from concept to delivery. Multimedia development is reflexive. Information and experiences from later development stages can be fed back into earlier stages.

For example, if during implementation developers find that a desired feature is not technically feasible, they may need to go back to the content provider and renegotiate a software specification. Alternatively, a technical possibility may arise at that time which would enable the developer to propose additional features, again requiring a redefined software specification.

Dialogue between clients and developers and among those contributing to development is critical to a project’s success. It should be ongoing, detailed, and critical. Regular meetings and discussions can ensure that the content providers, for instance, are at all times aware of the progress of the software and are able to participate fully in design.

This may seem onerous to some developers who may not want interference in what they consider to be their domain. Content providers may be satisfied to provide the content and then wait for the end result. Yet communication actually increases the probability that the multimedia product will meet client needs with software that is functional, robust and user-friendly.

How the dialogue and feedback are managed is of course a local issue, and in most cases it is likely to be informal. It is generally a positive idea to have minuted progress meetings in the design phase, which can also safeguard against misunderstandings, and which establish rapport for when the project moves into development.

Prototyping methods—ongoing creation of working models

Most software development tools (such as authoring systems) allow for the rapid creation of working models and mock-ups. With authoring tools, such as Macromedia Authorware, a non-functional screen may be drawn in a matter of minutes by placing buttons, fields, and other objects on a background. This undoubtedly gives developers freedom to experiment. It also allows the developer to prototype at all stages of development, from the moment the first code is written, or object drawn, right up to the last beta version. This is not only a considerable help when it comes to program testing but it can also enhance and facilitate the understanding between client and developer.

At all stages the developer should produce prototypes both for internal testing and to demonstrate to the client. Prototyping is a major part of the developer-client relationship. Prototypes have the following advantages:

The electronic format allows visually clarification of any misunderstandings from the paper format.
Ideas can be demonstrated to the user who will sometimes need to be shown what is possible before they can document requirements.
The user can test modules from their perspective.
The authoring of software features can be visually assessed by work groups.

For example, at the appropriate stage the developer might present the client with a range of user interface designs that have little functionality but aid them in choosing the ‘look and feel’ of the finished product.

Multimedia design issues

Project size

The project size affects the design—the more detailed the amount of data, the more levels may be required, which then often leads to a more complex navigation system.

Remember that navigation must be easy, consistent, visible and accessible at all times. This fact is further reinforced if the end users a large group with varying levels of computer skills.

If screen ‘real estate’ is a problem, then you can use drop down menus, quick keys or pop screens to aid navigation, but you must be mindful of adding complexity. You may then need to provide a tutorial for users at the beginning of the product. Ideally you shouldn’t have to do this.

Delivery options and end-user machines

If the product is to be accessed in a kiosk environment (meaning, a stand-alone display) then the navigation structure should be different from a tool or product that is networked.

If, for instance, the product is to be delivered over the web, rather than via a CD, then the developer needs to give more consideration to the attention span of the user, as web users may be more likely to ‘tune out’ if content is slow downloading or if important instructions are hidden under multiple layers or pages.

The end user’s machine must also be considered. Generally, the larger the audience the less control you have of desktop standards. The design will need to carefully consider items such as:

screen resolution
browser type and compatibility
browser settings (such as text size)
amount of scrolling
plug-ins
non-default fonts
memory and size of background images (especially on the web).

Testing will attempt to pick up these issues, but it is amazing the number of times a developer logs on to another person’s PC to find that the screen design looks different due to some strange setting on the user’s PC or browser.

While this can generally be fixed and preferred settings publicised, the user is always expecting things to work first time, every time!

Intrinsic and extrinsic motivation

The design of a product may differ depending on the motivation to use it. If someone is going to be paid for completing the activities on the multimedia product, or they will be receiving a worthwhile certificate or even a chance of a career promotion—then their motivation should be high and is to some degree from outside (extrinsic). The developer needs to understand the motivation of the users and design accordingly.

If the user feels they don’t need to complete the activities on the multimedia product, then they are more likely to browse. The introduction must help motivate and engage them. One of the key issues in successful multimedia products is that the user is getting something internally worthwhile to them (intrinsic) out of participating in the activities. Attempt to address this fact as best you can—its importance can’t be stressed enough!

Nature of content and information design

The nature of the topic and the title may also influence design.

For example a learning tutorial on ‘Discover the free world of butterflies’ would indicate to many that the navigation is not linear and that the user would be able to explore what they want, when they want. On the other hand, a business information package on new banking procedures may not have the same latitude. The developer is ultimately always responsible for selecting the best navigation and information design.

Nature of elements

The way that the multimedia elements should work also influences design. If the product uses audio and video, does the control belong to the user or the program?

For example, would there be:

automatic voice play?
a need for stop, start or repeat buttons?
a volume control slide, or would the ‘windows’ one suffice?
buttons that disappear when not in use or are tagged as inactive?
video screens that only appear when active, or would it take up space throughout the whole program?

These factors always need to be determined before the product moves into the development stage.

For more information on design try an online tutorial at:

Prototyping—scheduling and sequence

Scheduling

Multimedia software development projects are notorious for going over schedule and over budget. There are a variety of reasons for this, but at the top of the list are unforeseen technical difficulties. Even though the software development project should have a definite timescale with explicit target dates for deliverables, it has to be faced that project slippage is possible, and this should be taken into account when compiling the schedule.

In particular, it is a good idea to specify a minimal application that can comfortably be achieved within the timescale, even with an allowance for technical problems. If things go to plan during implementation, then other modules and features can be added to the product, and if not, then at least the team will have something to show for their efforts at the end of the project. The developer, in particular, must temper optimism with realism.

Reflect: On the obstacles to design

What do you think is the ‘biggest hurdle’ to get over when designing a multimedia prototype?

Sequence of events

Depending on your product, a typical sequence of events for producing a prototype could be as that which follows in Table 1. Note that the earlier stages of analysis have been included in this table to ensure the process follows a logical linear path.

Table 1: Sample sequence of events

Analysis
Stage 1 / Assess internal expertise, content matter experts / Create or collect storyboards, navigation maps, flowcharts / Create, import and organise graphics and text etc
Identify problem or need / Analyse potential design/development approach / Determine and assemble teams, specialists, graphic artists etc / Prototype design Stage 3
Identify and discuss business need/environment
Analyse project scope / Clarifying and allocating roles and responsibilities / Collect all software and check licences
Identify if multimedia is possible
Identify delivery platform / Determine and organise hardware and software / Load software
Identify that client has potential budget, infrastructure and resources
Identify potential rights, security issues / Set up development and test environments / Begin prototype authoring
Identify project, key stakeholders and business drivers / Design prototype framework
Clarify the nature, size and scope of content and elements / Determine authoring systems
Design prototype interface
Agree on business benefits and goals / Specify standards / Clarify and document file formats, storage structures, naming conventions etc / Add multimedia elements—video, audio etc
Document project and submit funding request / Analyse previous or related multimedia resources
Prototype design Stage 2 / Test prototype in different environments
Sign off / Analyse business culture/change management issues
Analysis
Stage 2 / Package prototype
Complete and submit full analysis document / Decide on prototype sample to be produced / Prototype design Stage 4
Run concept brainstorming sessions
Complete key staff and user analysis / Sign -off / Document prototype scope / Market to user groups
Design starts here 
Complete IT analysis (hardware, software, infrastructure etc) / Research/gather sample content / Publicise
Prototype design Stage 1
Start alpha testing
Assess available resources, elements, materials / Run design brainstorming sessions / Produce digitise and compress sample audio, video etc / Collect and evaluate feedback
Document design process and request sign-off.
Assess available resources, elements, materials / Collect and collate feedback
Create sample animations

Summary

Designing a prototype is an essential step in the design and development process. It is particularly vital in being one of the cornerstones of a user-centred design methodology

There are many issues, steps and tasks to consider and no project is exactly the same. The developer therefore has the job of balancing all the interests (technical, clients, users, etc) to drive the product to completion and they are relying on the design to be five things:

1Comprehensive

2Current

3Clear

4Correct

5Creative

1699_reading.doc