I wrote up a few thoughts on Robert Hoekman’s Designing the Obvious (New Riders, 2007) and have some suggestions gleaned from that that I’m considering implementing in my applications. I think that following these thoughts will move the business forward in terms of Ease of Use and Design.
What is Obvious about Designing?
Robert Hoekman’s book Designing the Obvious focuses on giving the user what he needs, as opposed to only he wants. Hoekman asks us as the designer to first understand how users do things, and then build our applications to reinforce those mental models. Hoekman believes that we should build minimal applications and that we should support the features that we observe people using, not just build a laundry list of the things they say they want.
How users do things
Hoekman’s mantra is to model your application around the way that users do things. We can do this by assuming nothing about the user, writing use cases to describe the ways that users actually use the application, and then observe the users to validate these cases.
Assuming nothing about the user means that we expect the average user to know nothing about the application when she starts. Labels on the screen must be descriptive, and step-actions that we expect this user to follow must match the labels on the screen. Hoekman’s “assume nothing” idea is similar to the “so easy, a caveman could use it” design philosophy we’re already using.
Once we get an idea of what the instructions will be like, Hoekman suggests that we write use cases for our users. These cases don’t have to be complicated, but should be descriptive. Hoekman writes:
Submit a Recommendation
Step 1. User clicks the Write a Recommendation link, and a short form displays immediately underneath the button. Tech note: This form resides in a hidden DIV and loads with the rest of the page. The button toggles to read Close instead of Write a Recommendation.Step 2. User completes the form.
Step 3. User clicks OK to submit the recommendation, and a success message displays above the form.
Step 4. User clicks the close button to close the form.
(Hoekman, p.46)
In a few steps, we get the idea of how most users are going to use this form. Use cases don’t have to be exhaustive, but should match the typical use of the functionality in the application and handle exceptions.
Finally, we shouldn’t assume that the use cases we write are correct. Hoekman thinks that we should ask users to try them and improve them, and also observe these users in the process of trying the use cases. You don’t need a fancy usability lab to test use cases, just a few minutes spent with four or five people who don’t know anything about the application.
Build applications to reinforce mental models
Once we have a better idea of how users like to do things, Hoekman thinks that we need to construct our applications to reinforce these mental models. Reinforcing metaphors requires three tasks: using metaphors that work, building a consistent user interface, and creating wireframes that show what the user will do to accomplish tasks.
Using metaphors that “work” means matching the type of task to the type of task we want the user to accomplish. If the process has multiple steps, rendering it in a single form field may not work very well. Hoekman thinks we should be using multi-step forms to reinforce multi-step processes and using visual cues to inform the user along the way (e.g. “You are on Step 3 of 6 steps to Add a New Account”).
Simply using a metaphor that works will not be sufficient without a consistent user interface to reinforce the metaphor. If you are going to delete a file, using a relevant icon such as a trash can will reinforce the mental model better than another, unfamiliar icon. Using the same visual treatment consistently through the site (color, font, design) will also help the user to remember that previously-learned steps can be applied in multiple places.
The final step to testing these mental models is to create wireframe examples that show the user what he will be doing. Creating these examples raises our ability to test the application while limiting the time spent in development and design.
Build minimal applications, but design them well
It’s better for your application to do a few things well than to take the “kitchen sink” approach requiring your application to have wider coverage. Hoekman writes that we can do this by offering in-context help, accelerating the development of the user’s skill, and by making the application pretty and clean (but not baroque).
Offering in-context help means two things to Hoekman: 1) offering help in a consistent place on the page and making it relevant to the content on the page and/or 2) offering help in-line with the tasks the user is trying to accomplish. An example might be using greyed out text as the default inside a form field to show the user what text is desired in that field.
This style of helping is reinforced by your ability to help the user get going. Hoekman believes that we should offer, instead of a blank page, a sample page with dummied up content showing the user where information already belongs and highlighting the ways that information can be changed easily. Combine this style of help with the in-context information the user needs to customize the page and you’re on your way to propelling that user from a hobby user to a powerful consumer.
Make that application pretty by keeping it clean will also help the user avoid being overwhelmed. Minimizing the number of clicks between tasks, making the design uncluttered, and toning down the color variation are all tricks we can use to make our applications “so easy, even cavemen can use them.”
Recommendations and next steps
So, where do we go from here?
Hoekman’s ideas are great, but how do we apply them to create better applications without adding loads of budget and time to our applications?
A few things come to mind:
• Write use cases
• Observe Users
• Build consistent UI
• Build fewer templates and offer help in-line
• And finally, “Make it so easy to use, even a caveman can do it”
