Framework for Obvious Design:
- Know what to build — the conceptual element
- Know what makes it great — the application element
- Know the best ways to implement it — the interaction element
Write textual use cases.
For example “User clicks Recommend link. A form appears. User fills out form and clicks OK. Message appears with a Close button. User clicks Close button.” Make it detailed enough to see flaws and wrinkles, and include alternative paths. Go over the use cases several times to ensure they include alternative paths (what if the user clicks Cancel?) and strive to make the flow as smooth as possible.
Build only what is absolutely necessary.
The focus should not be on features, the focus should be on focus. Strip out nice-to-have features, and don’t even consider implementing them until after your app has launched and you have real feedback from actual users. Support users’ mental models. Eliminate implementation models by creating and refining wireframes.
Create wireframes.
Use the 3 Rs:
- Requirements — only include things that are absolutely necessary.
- Reduction — remove as many screen elements, interactions and words as you can.
- Regularity — be consistent in formatting, layout and wording.
Reduce waste.
Throw away the specification document. (I have long advocated simple documentation.)
Have an application designer work with the business analyst on research and specification. This would fit in well with an agile development approach.
Just-in-Time design and review.
Something — even a quick, informal something — is better than nothing and will suffice in many cases. JIT design is basically a small meeting where participants try to talk themselves out of adding new features. The JIT review is a quick informal test with informal feedback. This sort of thing often happens anyway, but giving it a name helps to ensure that it isn’t forgotten.
Remove the “sexy” and “cool” features.
What’s left is the useful features. Everything else just gets in the way of this.
Be polite.
Don’t interrupt users. Make things easy. Let users concentrate exclusively on the task at hand.
Be bold when decisions must be made.
The most accurate answer to a design question is usually “It depends.” But the only way forward is to say, “We’ll do it this way.” You must decide, otherwise your software will be designed by accident instead of by you. Make the decision.
This book is full of useful guidelines like these, but a couple of sections don’t work quite so well. The little section on Squidoo is a bit odd. As he presents it, Squidoo does use many of his recommendations, but overall it does seem pretty bloated, with a heap of non-essential features. What happened to “Build only what is absolutely necessary”? It looks as if he features this site mostly because he likes it, even though it doesn’t illustrate his points very well.
There’s also a contradictory treatment of Amazon’s 1-Click purchase system. An early section called Understand How Users Think They Do Things says, “Every time I’m about to make a one-click purchase on Amazon, I make about 20 other superfluous clicks first so I can double-check the address and credit card details amazon has on file. … I don’t trust the one-click settings (which means the design is a little too obvious).”
But later in the book there is a section called “Use one-click interfaces”, which praises Amazon’s 1-click system, saying it “really helps users get things done quickly” and calling it the “mystical, magical one-click button”. (It also overstates the amount of work the feature saves.)
It’s almost as if these two sections were written by two different people. Of course, it’s natural for people (even authors) to have ambivalent feelings like this, but then the editor should have picked it up.
Designing the Obvious also describes a couple of Japanese management strategies that fit in nicely with the theme. The first is Kaizen (continuous improvement), which is a central theme of the book. When faced with a problem, try to solve it with small steps rather than trying to come up with a radical new approach, which will inevitably introduce complexity and unintended consequences.
The second Japanese management strategy is 5S, a set of five Japanese words that begin with S (in transliteration). These five words can be rather fancifully translated into English words also beginning with S: Sorting, Straighten, Shining, Standardizing and Sustaining. These map fairly well onto the book’s strategies.
This is a valuable book. As I re-read it I keep seeing ideas that I need to apply to my current project. If you build web application, you should read it too.