Designing from Both Sides of the Screen

by Kevin Godby

This week in Scientific Methods of Human–Computer Interaction (HCI 522), I presented a number of design guidelines from Ellen Isaacs’ and Alan Walendowski’s book Designing from Both Sides of the Screen: How designers and engineers can collaborate to build cooperative technology.

The Guidelines

The guidelines in the book fall under four basic tenets:

  • On being a butler
  • Don’t impose: respect physical effort
  • Don’t impose: respect mental effort
  • Be helpful
On being a butler

Software should act like a butler. It should always be available. When asked to do something, it should be prepared to do it with few questions and no complaints. If there is a problem, it should find a way to fix it or work around it without bothering the user. (Also, it should have an English accent.)

Software shouldn’t disturb the user by interrupting and suggesting ways it can be helpful. Instead, it should pay attention to what the user has done in the past and so that it can better anticipate what the user will want in the future. However, software shouldn’t go overboard in anticipating the user’s needs because it is more costly to do something the user doesn’t want than to not take the initiative. Software should be courteous and respectful—even when the user asks the software to do something it can not do.

Don’t impose: Respect physical effort

Treat clicks as sacred. Clicks include mouse clicks, keyboard presses, taps on a touchscreen, button presses on a physical device, and voice commands. Require as few clicks as possible.

Remember where users put things.
Remember everything users do to adjust the application. The next time they come back, everything should be just as they left it.

Remember what they told you. This one’s easy: don’t ask people for the same information more than once. If they update their information, remember the updated information.

Don’t impose: Respect physical effort

Make common tasks visible and hide infrequent tasks. Determine the most common user tasks and make sure they are visible and easily accessible. Hide less common tasks so they don’t clutter the screen and make it more difficult to find the common tasks.

Give feedback and show signs of progress. Acknowledge the user’s request and, if you can’t comply immediately, let them know what you’re up to and how long it will take. If a command can’t be carried out quickly, let users interrupt.

Keep preferences to a minimum—provide smart defaults. Most users never modify the default preferences, so the application’s default behavior is effectively the only behavior.

Be helpful

Offer sufficient information early, in context. Prevent errors. Indicate which information is required, what format is expected, etc. Try to prevent errors whenever possible.

Solve problems—don’t complain or pass the buck. Don’t bother the user with problems you can solve yourself. If you can tell the user how to fix the problem, try fixing it yourself.

Be predictable. Develop a set of conventions to use throughout your application. Users should be able to predict what a feature does based on their knowledge of what the other features do.

Request and offer only relevant information. Don’t mislead. Don’t offer options that are not available. Ask for information only if and when you will use it (and then remember it). Never collect and then ignore sensitive information.

Explain in plain language. Avoid jargon. Don’t blame the user. Indicate the consequences of options.

Discussion and Afterthoughts

Derrick Parkhurst pointed out that many of these guidelines keep popping up in many different books on usability. The guidelines I presented are just a sample of those in the book.

References and Resources

Related Posts

Zemanta