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 | |
Usability engineers explicitly set down criteria for their designs and then describe measurement schemes by which those criteria can be judged.
An example: Advanced mobile phones pose interesting HCI challenges. Mobile phone manufacturers want to cram as much functionality into their products as possible, but the physical size of the phones and their displays means that normal features for accessing lots of functionality: menus, dialogue boxes, etc., tend to be inappropriate. Assume you have to design a way of accessing phone functionality and you have decided on a restricted menu system. Menus must not be long, perhaps a maximum of six items per menu. To compensate for this you may decide to nest menus, but if you do this then it is easy for the user to forget whereabouts in the menu hierarchy they are, so feedback must given.
As a usability engineer you set yourself the explicit goal of avoiding ‘menu lostness’; the extent to which the user gets irredeemably lost in a menu hierarchy. On each menu there is the ability to ‘bail out’ and return to the highest level menu. If a user bails out like this without invoking some functionality then we assume that they have failed to find what they are looking for and become lost.
The usability specification for this aspect of the menu system may look like the following:
| Attribute | Menu lostness |
| Measuring concept | success in finding and invoking the desired functionality |
| Measuring method | The ratio of successfully found functionality to bail outs |
| Now level | This is a new product: there is no recorded now level |
| Worst case | 50% of menu use results in bail outs |
| Planned level | 10% of menu use results in bail outs |
| Best case | No bail outs |
The attribute ‘menu lostness’ describes what is wanted of the system in usability terms. (Note though that ‘menu lostness’ is a bit of an opaque term. There should be accompanying documentation described exactly what it means.) The measuring concept describes what we are looking for in a system in order to judge whether the attribute is fulfilled or not, and the measuring method describes how we should go about looking for it. The now level describes the current state of the system; how the current system fares against the measurements. The worst case, planned level and best case describe what the designer should aim for in their design.
Note that like good specifications this describes what is wanted from the system, not how it is done. It is up to the designer to build in features that prevent the user from getting lost. Whether they do this by adding explicit feedback on the display which describes exactly whereabouts in the menu hierarchy the user is, or by flattening the menu hierarchy somehow to make it harder to get lost, is not an issue for the specification. The specification describes what is wanted in usability terms and how to tell whether or not it is achieved.
Because this scheme is based on normal engineering practice it should fit well into standard engineering practice like the waterfall model. In such an augmented practice as well having to discharge design obligations about the functionality by showing that a solution is correct for its functional specification, the designer also has to discharge the usability specification by showing that it has been solved.
The problem with this sort of usability specification is that it may miss the point. What really is at issue with the mobile phone example may be not that the user cannot get at all the functionality easily, but whether the functionality that has been crammed it is really useful in the first place. Usability engineering must start from the very beginning of the design process to ensure that account is taken of these issues.
Also, it is not clear that what is specified in the usability specification actually relates to genuine usability. In the example given we decided bailing out was a measure of failure. What if the user is not aware of the possibility that they can bail out? Novice users may struggle on, getting more and more lost and frustrated, unaware that they can just bail out. By the measurement scheme suggested this behaviour would not count as a failure. Furthermore, and rather flippantly, the designer could ensure that no user ever bails out by removing the bail out function altogether. This may sound silly, but designers have been known to do this sort of thing.
Consider the usability specification we have given for the mobile phone menu system. It describes what the problem is, and how we will know that we have solved it, but not the solution. Have a think about the problem and see if you can think up some solutions. We will return to this in a later review question, so make notes and keep hold of them.
A discussion on this activity can be found at the end of the chapter.