Who is this collection aimed at?

We consider that there are four kinds of actors, or user avatars, who will be interested in this document.

1. The multimedia team or company manager.

The primary goal of the manager is to show a cost benefit for his or her organisation. This cost benefit can be created for the accountants by reducing the lifecycle time, by improving productivity, and by minimising or at least predicting over-run. But the true manager knows that this is not enough. In order to stay viable, he or she has to show better quality than their competitors, and in order to do this, he or she has to become more responsive to the needs of their clients and end users.

2. The multimedia developer.

A developer knows there is always never enough time to get the product finished. The two things which make life extremely intolerable for a developer are:

	a steady stream of random-seeming requirements changes
	having to go back to work already delivered in order to fix something

By adopting a user-centred approach, developers can incorporate and therefore bring under control input from the end users. This works to their advantage because a product that is designed with user needs in mind is a robust product that can handle 'hard knocks.' But it does mean that extra time has to be taken at the start of the process in order to speed things up at the end. Because we realise that many developers fear 'big new solutions', because they rightly know that every big new solution has sharp edges which can cut, this collection presents a set of guerilla tactics for usability. This means, small scale, uncomplicated ways in which to do things better.

If a development team is in contact with their users, and is able to handle user input, they don't get those nasty shocks at the end; or worse still, three months after delivery when they are in the middle of the next project.

3. The client. There are three categories of clients:

	naive
	wary
	street-wise

Each of these categories presents its own problems to the multimedia developer. Let's take a closer look at them.

The naive client: This client knows little about information technology or multimedia. They have seen their competitors 'getting on' in the multimedia world, and feel that it's time for them to go in as well. They know very little about what is involved, and most probably have completely unrealistic visions of what they will expect to get. They are often disappointed and dissatisfied with their first multimedia experience.
The wary client.: Even worse than the naive client, this type of client has heard the horror stories, knows that business is a tough place, and that newbies get skinned. He is usually extremely wary and not ready to participate fully in the process in case he shows the true extent of his ignorance. Where he fails is by setting his sights too low, and not taking full advantage of the possibiities open to him, or by pretending to be the expert, and trying to second-guess the developer.
The street-wise client: This kind of client has been around, knows the game, reads the magazines. She has an instinct for good business and will drive a hard bargain. She will choose a good multimedia company almost by instinct, and she will know that the key to her success is to develop a good working relationship with the multimedia company or group manager.

It is most probably depressingly true that at present, the bulk of the market is represented by naive or wary clients. These types of clients will find a lot of the mystery of this new world can start to disappear when they look through the contents of this package. The ISO 13 407 model gives them a street map of what the territory should look like. The street-wise client will know that this collection is a good assembly of tools with which to enhance the client-developer relationship.

If you are a client or a prospective client, this collection will show you what you can reasonably expect. Here's the interesting part: good developer organisations will know what you're talking about. Poor ones, who won't respond to your business needs, will simply give you more techno-babble. In our experience, if communication is not established between the client and the developer right at the start, the initial brief will be flawed. From then on, there is only one direction: downhill.

4. The human factors person within the developer organisation.

This person frequently finds themselves on their own in an organisation full of techies. They may be fresh out of college, or just after a career change. They have been hired because they are bright and have new ideas. But today comes the hard part: to show what you can do for your new organisation.

In our experience, we suggest you become a human factors guerilla. Study the techniques in this collection. They have been extremely carefully selected by numerous human factors experts in the US and Europe to represent the best and the most successful approaches to making the difference in your company. Take a good look at the case studies. They represent the work of some of the world's most expert consultants in human factors. See how you can apply these lessons to your organisation.

Copyright EMMUS 1999. Last updated: September 29, 1999.

Copyright EMMUS 1999.
Last updated: September 29, 1999.