June 2010 Edition
Computer Science Department, University of Cape Town
| MIT Notes Home | Edition Home |
| MSc-IT Study Material June 2010 Edition Computer Science Department, University of Cape Town | MIT Notes Home | Edition Home | |
There is a mismatch between designing systems and testing them with users. In the waterfall model a tangible system only appears towards the very end of the process. For most of the process the system exists only as requirements documents, design specifications and ideas in the designers’ heads. The absolute test of a system for usability is to give it to collections of users and see what they do with it. Unfortunately an actual system only exists at the very end of the design process, therefore user testing can only take place at the end of the process and, as discussed earlier, if a big mistake is identified at the end of the process then it is extremely expensive to fix.
Rapid prototyping is a process whereby mock-ups or prototypes of the system are produced all the way through the design process. These prototypes can be then given to users in order to judge their usability. User responses to the prototypes can be judged and feedback passed into the design process to guide the design of the actual system.
Prototypes can be constructed in several ways ranging through levels of interactivity that they offer to the user.
Storyboards are the simplest form of prototype. They are simply rough sketches of the system and its user interface. User are guided through the system by analysts who show the users how they are expected to use the system, and show them what the system is expected to do. The analysts record user responses to the system and feed these back to the designers.
Storyboards may be very simple drawings of the system done on paper, or there are more sophisticated tools available which allow the analysts to create storyboards on a computer using graphic packages and apply some limited animation to the graphics. These allows a little more reality in the storyboards, but in effect the analyst is still in control and steps the users through the system.
In order to give the users more the idea of interaction then limited functionality simulations may be created. These are effectively mock ups of the system, made to look like possible designs of the finished system but with a much restricted set of system functionality behind them.. There are several packages which allow the rapid development of prototypes. They allow the positioning of various interaction objects (buttons, menus, slider bars, etc) on the screen and the attaching of simple behaviours to those objects. Such prototypes give the user the impression of interacting with the full system. The simplicity of the prototypes mean that they can be rapidly reassembled in differing layouts according to user feedback.
Simulations also allow for hardware designs to be cheaply evaluated. Something like a video recorder has built in hardware buttons and controls. Mocking up a physical version may be quite expensive, but a ‘soft’ mock up may be created on a computer, where a picture of the proposed control panel is generated and the user can interact with it using the mouse to ‘push’ the buttons.
Another technique for prototyping is the ‘Wizard of Oz’ technique where the user is given a mock up of the system, which actually contains little or no functionality, but is remotely linked to an analyst who pretends to be the system and makes it respond to the user input appropriately. Such a technique is cheap to set up and very cheap to change, because the analyst just pretends that the system behaves in a different manner. There are ethical issues with misleading subjects in experiments in this way though.
There are also a collection of ‘executable specification’ languages which allow designers to describe software specifications formally in a specification language. These specifications can then be rapidly and automatically converted into working programs, to which interface elements can be attached and a working prototype can be presented to the user. The automatic translation from specification to working program means that the working program will be very rough and inefficient; it requires human software developers to produce really good code, but computers can generate code from a specification that does what it required of it, but in a very inefficient way. The problem with executable specification languages is that they tend to require that the specifications are written in a certain way so that they can be made executable. Non-executable specification languages do not impose such restrictions on developers and are therefore more flexible and powerful tools.
The idea of rapid prototyping is that a mock up of the system is produced, tested, the results of the test are fed back to the developers and the mock up is thrown away. Iterative design pushes the philosophy a little further by relying on mock ups and prototypes, but using those as actual artefacts in the design process instead of throwing them away. An iterative design process collects requirements and then endeavours to produce a tangible, but very crude approximation of the system as quickly as possible. This approximation can then be user tested and then redesigned accordingly. More detail and refinements can be added to this system and tested as they are added.
Gradually a fully featured, working, and hopefully usable system emerges.
The main problem with prototyping is that no matter how cheaply designers try to make their prototypes and how committed they are to throwing them away, they still have to make design decisions about how to present their prototypes. These decisions can then become ingrained into the final product. There is a factor to consider called ‘design inertia’ which describes how designers, once having made a design decision, are rather reluctant to relinquish that decision, admit it is wrong and change it. This is another reason why good designers put off big decisions as much as possible, knowing that if they make a small mistake early on it is easier and cheaper to rectify than a big early mistake.
Rapid prototyping is about exposing bad design decisions as soon as possible after they have been made. Guidelines and usability engineering are more about trying to get the designer not to make mistakes in the first place. Design inertia is therefore much more prevalent in rapid prototyping development than it is in other user centred design processes. Because prototypes do not get thrown away in iterative design processes then design inertia is even more prevalent.
Furthermore in spotting usability problems by user testing, the designer knows that there is a problem, but not necessarily what causes that problem, or how to fix it. Rapid prototyping identifies symptoms, not illnesses and not cures.
Rapid prototyping differs in one crucial respect to design by guidelines and usability engineering. What is it? (Hint: refer back to your answer to review question 1.)
Answer to this question can be found at the end of the chapter.
Now lets consider the way that the functionality of the web browser is put on the screen, particularly the buttons along the top of the browser. Look at the space they take up and compare that to how much they actually get used. then think about what is really important about the web. Go back to step one and look at what you wrote about the web: what is important about the web? I wrote that what was really important was the information in the web: it is the web pages themselves that are important not the navigation tools offered by the browser.
So now look again at the space used up by the buttons and how much space that leaves for showing the web pages themselves. Now think about the television analogy: how much space is taken up by the televisions navigation tools (i.e. the channel changing buttons) and how much space is taken up by the screen itself. Look at a typical web browser display. Typically, the navigation buttons occupy about a fifth of the screen, and our analysis shows that only one of those buttons gets any significant use!
Now lets stop being destructive of the web browsers design and start thinking of constructive design ideas. We should have a picture of what functionality the user actually uses and in what situations from activity 3. So using a pen and paper sketch out an interface design which gives prominence and ease of access to the commonly used functions, makes the viewable window with the current web page in it as large as possible and buries unused functions away in menus.
A discussion on this activity can be found at the end of the chapter.