Recently I began an interface review for a well-known medical device manufacturer. These folks are pretty well plugged in to who their customer is and what is important to them; they sell their medical devices directly to users, who wear them constantly and are vocal in their feedback and eager to help improve the products.
I figured that it would seem inappropriate, then, to begin an interface review in a traditional User-Centered manner, questioning the great body of express and implied market research that the company has done. Rather, it would be nice to apply what I already know from User-Centered design to a more task-oriented approach. And while I am aware of many resources specifically dealing with Task-Centered Design, I wanted my analysis to have my “flavor,” to be suggestive of what I find important when doing task analyses and the like. So I began to winnow down my thoughts into loose task-centered design principles, which are still rough.
Expect revisions.
All of these stem from a central idea which I find simple and powerful: Transfer as much workload as possible from the user to the developer . Every moment of navigation, investigation, confusion, even simple use of your device/tool/application/web page that you save an end user, multiplied by the number of users, cannot help but eclipse the work required to get the interface right, unless you actually fail to sell the thing in the first place, which is a different problem.
So! Eight principles, a first crack:
- Anticipate user tasks
- Give priority to the most important and common user tasks. When in doubt, fall back on the questions, “What does the user want to do? Need to do? What do we want the user to do?”
- Expose system state
- Bring relevant indicators of system state out from hiding places. Reduce the amount of trial a user must endure to learn about how the system is configured. Bring a meaningful small datum to the surface.
- Provide clear affordances
- The proper action of the user (and, ideally, the proper action of the system) should each be suggested by the control; each menu item should suggest its consequences.
- Anticipate problems and lead the user to the solution
- Avoid errors by guiding the user, signaling correct input, removing invalid choices, etc. When errors occur, explain the problem and guide the user in dealing with it using positive language. (Error messages should have a positive component as well as the usual negative “a bad thing happened.”)
- Reduce the time/operations to complete tasks (especially gating tasks)
- Make common and/or important tasks quick and easy to perform, especially if the task lies between the user and a task at the heart of their ultimate goal.
- Reduce ambiguity/enforce useful consistency
- Consistency enhances recognition, which is more reliable than recall. Consistency can also help the user feel at ease in unfamiliar sections of the interface. BUT! Consistency is a tactic, not a goal.
- Provide consistent/useful/meaningful defaults
- There are situations in which a control’s default setting should be its most recent setting, and there are situations where it is more useful to steer the user down a particular path.
- Judiciously increase “power”
- Add details to the interface that can speed input and navigation for frequent users without disorienting novice users.
These principles, in the clear light of day, may not all be principles, may contain redundancies, etc. And, naturally, since I copied these directly from my presentation notes, they are slanted quite heavily toward the client in question and their specific needs. I will continue to work on these; more later.
