User interface design
High-level goal: Usability
A good user interface (UI) enables users to get their job done efficiently, easily, and enjoyably. User interface design focuses on users and their experience of using the system.
Some of the principles that normally apply to software enginering tasks are less central to user interface design. In particular, we have been focusing on the needs of programmers, but for UI design, we worry about users and how they interact with the system. Our focus is therefore not on making the programmer's job easy, although we of course still care about how to deliver a good user interface in a cost-effective way.
We might think that a good user interface is one that provides the largest feature set possible. Sometimes a large feature set is needed, but often it is not what the user needs.
We now take a look at the problem of UI design and try to elucidate some principles that can guide us when designing and implementing user interfaces.
Know your users. Design to them.
“If there is any one secret of success, it lies in the ability to get the other person’s point of view and see things from that person’s angle as well as from your own” — Henry Ford (actually)
The most critical aspect of designing any interface is to understand how it will be used. That is, you need to understand your users.
Different applications have different kinds of users. Your users may be expected to use the software frequently and therefore to be familiar with it, or they may only use the software occasionally. They may be novices to the application domain, or they may be knowledgeable about it. Users may be expected to have some training in the use of the system, or may be expected to learn how to use it without training. Different kinds of users need different kinds of UI designs.
We might think that the way to design a good user interface is to give users what they say they want. But users are not typically good user interface designers, so treating their ideas as prescriptions tends to bad designs. As the (unfortunately apocryphal) quote often attributed to Henry Ford says, “If I had asked people what they wanted, they would have said faster horses.”
Although we don't want users to dictate the design, at the same time, it is crucial to understand your users and the tasks they want to accomplish. Interviewing potential users is an important early step in design. The focus should be, again, not on asking users what specific features they are looking for, but on understanding the tasks they want to carry out. Then you can design while being conscious of how the user experience you are creating meshes with the intended uses.
A common error when designing user interfaces is to think that the user thinks like you do. But most users are not like you. To combat this form of bias, it is critical to interviews users, and to test designs on users.
Infrequent/new users
For users who use the software too infrequently to remember it, or who are encountering it for the first time, the design emphasis should be on providing a gentle learning curve and strong visual, auditory, or even haptic cues.
- Discoverability: can learn features, interaction
- Protection from dangerous actions, no loaded guns. (Andy Aaron's classic Saturday Night Live skit, “Blowing up a Building”, is a great illustration of this principle.)
- Principle of Least Surprise
- Clarity: Simple, clear displays
- Consistency with other applications
- Use metaphors to communicate (e.g., icons)
Intermittent but knowledgeable users
Here the focus is on making features discoverable, and reducing the memory burden for users. The user has an idea what features are available but may not remember how to access them.
- Internally consistent appearance and actions
- Clear visual structure
- Protection from dangerous action for safe exploration
Frequent/power users
For users expected to have a lot of experience with the application, and perhaps also training, the design emphasis should be on efficient interactions.
- Usable ≠ "User friendly"
- Powerful actions, short interaction sequences
- Rapid response times
- Rich controls, shortcuts for common actions
- Exploit muscle memory
- Information-rich displays
- Customization and macros
UI as dialogue
- Ratify actions quickly
- Be responsive (e.g., highlighting)
- Show progress on longer actions
- Use a set of use cases to figure out what users will have to do.
- Eliminate unnecessary user actions.
- Aim for short interactions with clear progress: intermediate goal satisfaction (cf. DisneyWorld ride lines)
- Use testing to find your blind spots (as developer).
- May need to write testing scripts for human testers. Key (as usual): coverage.
- Goal: app feels like extension of user, promotes flow
- Example: driving a car vs. programming/remote-controlling a car, or Word vs. TeX.
- UI abstracts underlying application state (the model)
- Abstraction does not need to match the implementation
- Good implementation strategy: Model != View != Controller
- Good abstraction: Model = View = Controller
- Less direct styles:
- Menu selection/hierarchical navigation
- Form fill-in + submit
- Command languages
- Channels `utterances´ (user actions) into meaningful directions
- Reduces memorization
- Modes: states of UI that restrict interactions.
- Modes help with restricted context-sensitive vocabulary
- Avoid overusing modes and trapping users in modes.
- <1/60s: biologically imperceptible: faster than neurons
- <1/30: fast enough for continuous-feedback tasks (e.g., mouse tracking)
- <1/10s: imperceptible delay for discrete actions, e.g. button clicks.
- <1/2s: fast but noticeable (ok for command-response interaction)
- 1/2s-5s: increasingly annoying but user stays focused
- 5s-10s: User starts to lose attention.
- 10s-1 min$: User becomes distracted and productivity declines. App needs to support parallel activities.
- >1 min: Significant loss of productivity. User leaves for coffee.
Learning and memory
- Obvious controls
- Easy to find and identify
- Don't set up user for a fall: disable invalid/dangerous actions
- Avoid overload
- Human can only hold 7 things in their head at once
- Avoid long menus, lots of buttons
- Design visuals carefully for rapid comprehension
- Task-focused rather than feature-focused (unlike most modern apps!)
- Tap into humans ability remember to things spatially: e.g., the memory palace.
- Each window or dialogue is a place you can go—make it a place user wants to be in.
- Avoid unnecessary places to learn about and navigate between.
- Make navigation simple, clear, easy.
- Big-picture overviews help users stay oriented
- bird's eye views
- menus with highlights
- Frequent users remember UI in their muscles.
- Make actions to get an effect consistent so motor memory can carry users through without thinking.
Visual design
- Avoid visual clutter
- Use space shading, color rather than lines to organize information.
- Use low-contrast separators
- Maximize “information/ink ratio” (Tufte)
- Aim for visual consistency
- Large apps need a written style guide to keep look and feel consistent as app evolves.
- E.g., buttons that change state vs. buttons that navigate vs. buttons that expose hidden information: user should be able to distinguish.
- Employ visual features as an additional communication channel.
- Shape (up to 15)
- Color (up to 24)
- Size, length, thickness: up to 6.
- Orientation: up to 24
- Texture
- Differing perceptual capabilities of some users (esp. for color) ⇒ cannot rely solely on visual features to communicate, but they can complement the information that is there in another form.
Useful reading
- Envisioning Information. Edward Tufte.
- Principles of Computer Graphics. Foley and Van Dam. Ch 8.2-8.3, 9
- About Face 2.0, Cooper and Reimann.
- Human–Computer Interaction. Dix, Finlay, Abowd, Beale.
- The UX Book. Hartson and Pyla.