Chapter Introduction | Web Resources | Assignment Comments | Teaching Materials

The assignment should enable you to begin talking about the usability of interactive products in terms of a variety of parameters. Instead of simply saying 'nice cell phone, lovely to use' or 'awful MP3 player, really bad design' you should now be equipped (having studied chapter 1 and associated reading) with a set of terms and concepts that can help you describe what is good and bad about an interactive product's design in terms of usability.

However, it is still easy to fall into the trap of talking about usability at a fairly shallow level. For example, when asked to do this exercise, some students might just say 'product X is easy to use, remember and to learn'. This may be the case, but you need to explain why. You need to explore in more depth why you think something is usable or not, in terms of X,Y or Z. In so doing, you may find that while the basic functions are easy to learn, many of the more advanced functions are fiddly or inefficient to learn how to use and remember. Hence, a product's usability will vary depending on the nature of the task, the context in which it is being used, and who is using it. Setting specific questions for each of the usability and user experience goals and the design concepts and usability principles can help you to start articulating in more detail what is and isn't usable about a product (and why this is the case). In addition, asking someone else to try doing a range of tasks and observing them can be very revealing, showing you aspects that you would overlook yourself or take for granted.

You should also try to avoid seeing usability in terms of 'black and white', i.e. a product is either easy to use or it is not, it is efficient or it is inefficient to use. What is often much more interesting are the grey areas, where it may not be obvious at first that there is a problem but only after careful examination are you able to identify a specific usability problem (or set of problems).

Try also to avoid the checklist approach, where you simply run through the set of usability goals and design principles and compare them with the product in front of you. Use the goals and principles more as heuristics, by which to uncover problems (or not) with a product. Always explain why you think something is easy to use or difficult to remember, illustrating your answers with actual examples of tasks when using the product.

When thinking about making changes to a product, based on your usability evaluation, it is important not to think about them as isolated improvements but in relation to each other. For example, consider the design recommendation for a hypothetical cell phone: 'remove the help icon at the top of the display screen'. The reason for the suggestion is it has been noted that when doing a usability evaluation it takes up too much real screen estate. Instead, the suggestion is to make it a hard-wired function, using one of the physical keys on the phone. The rationale is that it will still maintain visibility of the help function at all times, but will also free up some display space.

Now think about what the consequences and trade-offs might be for the rest of the tasks the user has to do at the interface. In this case, dedicating a hard button to be the help button means one less key available for doing other tasks. Does this now mean that some tasks will need to be done by switching between modes, which wasn't the case before? Is this preferable? What is gained and lost in proposing this design change? Also think about why a particular way of doing something was designed like that in the first place (e.g. why was the help button put on the display?). What do you think the designer was up to and why did they make that decision? Did the designer have a choice, was it an arbitrary decision or was it a compromise?