Chapter 13 User Interface Design
The golden rule of UI design
A user interface is well-designed when the programme behaves exactly how the user thought it would
- User familiarity: Copy well-known features from other programmes.
- Consistency: Do similar operations in the same way.
- Choose default values carefully: Minimise the number of choices novice users have to make.
- Use metaphors: To establish the user model.
- Recoverability: Ensure UNDO works in ever situation.
- Provide help: But make it sparing and highly context specific.
Users rarely read the manual and only read two or three words at a time. Users also do not like making choices. It is good practice to have default or common options already selected (for example, in a setup screen).
The UI design process
- Define a set of representative user types.
Set of actors. This is important. Rather than think of a user, think of their role (Admin, player, guest, etc)
- Identify the most important activities
ie, use cases
- Assume some user model based on how you think each user will expect to accomplish each activity
- Design the UI based on the current user model
- Use metaphors to illuminate the user model
Eg, The shapes for play, pause, fast forward etc. are well known and should be used in the case of a media player
- Borrow familiar behaviours from other programmes, especially controls
Menus, for example. Material design principals, another example.
- Keep it very simple, users will always assume the simplest model
- Use metaphors to illuminate the user model
- Implement a prototype
- Test each use case with each user type and iterate
Preferably with someone from outside the team
- Note areas where people have trouble. These are probably areas where the programme model does not match the user model.
- Refine the user model and iterate from 4.
User types are often applucation specific but common categories are:
- 'techies' - enjoy figuring out how things work
- 'teenagers' - like technies, but know no danger
- 'experienced users' - think they aready know how everything works
- 'naive users' - often too timid to explore the interface
There is also an increasing dichotomy between digital natives (children raised in the internet age) and digital immigrants - non-natives trying to use computers
A use case describes a typical user activity from start to end. A good set of use cases motivates a design, and provides a basis for testing. A use case will consist of:
- Definition of the user's goal
- List of pre-conditions
- Criteria for successful completion
- List of main steps in the activity flow
- Any extensions/alternatives to this use case
Wizards guide a user through pre-stored use cases one step at a time.
A user model is the user's mental model of what is happening. Note that different users will have different mental models. A good UI design encourages every user to adopt the same mental model.
Eliciting user models:
- Usually five to six people is enough to gather a consensus.
- Present each user with a scenario and a task to complete.
- Use simple prototypes, screen mock-ups or just sketches to describe scenario.
- Ask user questions to understand how they would set about the task.
- Hence infer their mental model.
|Interaction style||Main advantages||Main disadvantages||Application examples|
|Direction manipulation||Fast and intuative interactions
Easy to learn
|May be hard to implement, only suitable where there is a visual metaphor for tasks and objects||Video games
|Menu selection||Avoids user error
Reduced typing required
|Slow for experienced users
May become complex is many menus are used
|Most general purpose systems|
|Form fill-in||Simple data entry
Easy to learn
|Takes up a lot of screen space||Stock control
|Command language||Powerful and flexible||Difficult to learn
Poor error management
|Natural language||Accessible to casual users
|Requires more typing
System currently unreliable
All interactive systems need some way of presenting information to the user. It is a good design practice to keep the presentation separate from the information itself. The representation on the screen can be changed without having to change the underlying architecture.
There is a vast choice of display styles. In general, graphical display methods are used to present trends and relative values. A digital display should be used when precision is required, and even then, graphical highlighting could be used to highlight changes.
Colour interface design
- Simply be a tool to provide highlighting.
- May improve the GUI by helping the user understand the data presented and by managing its complexity.
Misuse of colour may:
- Result in a GUI that is visually unattractive.
- May lead to mistakes by the user
The general rule for GUI designrs is to be conservative in the use of colours.
Colour in GUI
The two msot common errors made by designers when using colour are:
- Associating meaning with a particular colour
- Using too many colours
Why not use colour for meaning:
- Around 10% of men are colour blind and as a result they may misinterpret the meaning of the colour.
- Colour perceptions are different.
- Within different professions there are different meanings for different colours.
- For a driver, red means stop for example.
- Confusion is also possible if colours are used inconsistently.
If too many colours are used, or the colours are too bright, the display may disturb the user and cause visual fatigue.
Colour use guidelines
- Limit the number of colours used and be conservative in how they are used and be conservative in how they are used
- Don't use more than four or five separate colours in a window and no more than seven in a system (roughly)
- Colours should be used selectively and consistently
- User colour change to show a change in system status
- If a display changes colour, this should mean that a significant event has occured
- Colour highlighting is particularly important in complex systems where hundreds of distinct entities may be displayed
- Use colour coding to support the task which users are trying to perform
- If they are attempting to identify anomalous instances, highlight these instances
- If similarities are to be discovered then highlight these using a similar colour
- Be careful about colour pairings
- Because of the physiology of the eye, people cannot focus on red and blue together
- Other colour combinations may be visually disturbing or difficult to read
- Take into account issues such as colour blindness
- Use colour coding in a thoughtful and consistent way
- If one part of a system displays error messages in red then all other parts should follow
- In such a case, red should not be used for anything else on the system - only error messages
- Be aware of the users' assumptions about particular colours
Error messages should be:
- Appropriate to user's skill level
Error message design factors
|Context||The user guidance should be aware of what the user is doing and as a result, should adjust the output message to the current context|
|Experience||As users become familiar with a system, they become irritated by long, meaningful messages. But it must be remembered that beginners find it difficult to understand short statements of a problem. So the user guidance system should provide both types of message and allow the user to control message content descriptions|
|Skill level||Messages should be tailored to the user's skills as well as their experience. Messages for different classes of user may be expressed in different ways depending on the terminology which is familiar to the reader|
|Style||Messages should be positive rather than negative. They should use the active rather than the passive mode of address. They should never be insulting or try to be funny|
|Culture||Wherever possible, the designer of the messages should be familiar with the culture of the country where the system is sold. There are distinct cultural differences between Europe, Asia, America, Africa, etc. A suitale message for one culture may be unaccpetable in another.|
Using a metaphor can help a user align their mental model with the way that the programme actually works.
A good metaphor is:
- Extendible - helps user infer how to do new things
- General - applies to the whole programme, not just one bit of it
- Necessary - if the software is obvious to users, do not introduce gratuitous metaphors
Interface evaluation is the process of assessing the usability of an interface and checking that it meets the requirements. These are often linked to the non-functional requirements of a project. A user interface specification may include:
- Speed of operation
All specification points should be measurable.