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 | |
Design rationale is about explaining why a product has been designed the way it has. Throughout this section we have been describing ways of supporting a designer in making design decisions, i.e. selecting one design out of the design space. For each decision made there must a set of reasons why that particular decision was made. Design rationale is about recording those decisions and the reasons why they were made.
A design rationale is a useful design tool because it explicitly lays out the reasoning behind a design process and it forces designers to be explicit about what they are doing and why they are doing it. In particular a design rationale can be used after a product has been completed in order to analyse why a product was a success or failure. If a similar product is being designed subsequently then its designers can refer to a design rationale to discover why earlier products were designed the way they were, and with the benefit of hindsight judge whether the earlier design decisions were successful and warrant repeating.
Design rationales are particularly helpful in interactive system design because, as we have been discussing, there is rarely one objectively correct solution to any problem, and some solutions may contradict one another, or require trade-offs. Design rationales require the designer to be explicit about how contradictions were resolved and trade-offs were made.
Furthermore the design space may be very large and therefore it is not obvious that a designer will even consider the best solution, never mind choose it. A design rationale makes it clear which options from the design space were considered and why. If an apparently better solution were later discovered then it is obvious whether that solution had been considered and discarded for some reason, or not considered at all.
Usability is very context dependent; what is good for one user may be dreadful for another. If subsequent designs are made where the context of use does not change then a design rationale can be reused without modification. If however the context does change then new design decisions can be made for this new context, but in the light of the decisions made for the older context.
The QOC (Questions, Options, Criteria) analysis technique is a design rationale. It is a graphical notation that allows designers to visibly lay out the reasoning behind design decisions.
Questions are effectively problems in the terminology we have been using. Options are possible solutions to those problems, and criteria are arguments as to why or why not a given option is appropriate.
Returning to the mobile phone menu problem we discussed in the usability engineering section, a question may be ‘How to prevent users becoming lost in menus?’
Options for this question could be:
to flatten menu hierarchies to a maximum depth of three,
to give textual feedback as to the current menu display (e.g. display the text ‘Address book : Edit : Add number’ to show that the user has selected the ‘Address book’ option from the main menu, the ‘Edit’ option from the Address book menu, and ‘Add number’ option from the edit menu.
to give graphical feedback as to how deep the user is in the menu hierarchy by shifting each new menu selected a little down and to the left, giving the impression of stacking up menus.
For each of these options there are several criteria effecting whether or not it is a good design decision:
Screen real estate
Limited functionality
Accurate user knowledge as to where they are in the hierarchy
Now we can go through discussing each of these criteria for each of the options.
If menu depth is kept to a maximum of three then:
this has no real effect on screen real estate,
it limits the functions that can be placed in the phone. Say a maximum of six items per menu can be displayed, then there is a maximum of 258 functions that the phone can perform,
keeping the menu hierarchy flat, improves the chances of the user remembering where they are.
If textual feedback is given then:
If textual feedback is given then:
there is no limit to the number of functions,
user knowledge of where they are will be very accurate.
If graphical feed back is given then:
screen real estate can be efficiently used,
there is no limit to the number of functions,
the user will have a prompt as to where they are in the hierarchy, but not a very accurate one.
So for the question we have identified three options and three criteria which effect those options.
Now it is up the designers to argue which is the best design option.
Imagine you are the designer faced with implementing one of the options. Which would you decide to implement and why? Is this a good analysis of the menu design space? Explain your answer.
Answer to this question can be found at the end of the chapter.