A common sense approach to web & mobile application design
by Robert Hoekman Jr
2011 New Riders
I was able to read Designing the Obvious on a short flight from Chicago to Denver. It is a pretty quick read, but a little more wordy than the Steve Krug line of books. However, there are some very practical messages, tips and examples that can be very effective and useful to your own work. Because the book is newer it provides many up to date examples that we as designers have all used and know. I have used this post to highlight some quotes and statements from Hoekman that may be interesting to you. I would like to thank my buddy
James for lending it to me. He has probably the most impressive personal design library I have ever seen.
When an application is designed badly, it tells you at every opportunity how bad it is. But when it's good you usually can't explain why its good. You can't put your finger on it but you know it when you see it.
Lead with Why, Follow with What
When you start with What, your present a thing. When you start with Why, you present a belief.
This was the second chapter in this book and perhaps the most important chapter. How many times have we worked on a project or product that was conceived by the engineering department or product management? We start working on these projects where the only specification and requirements provided are technical. When designers start asking questions and visiting customers we find it is not what is required. This chapter explains why its is important to know Why we are building something. Hoekman often asks his customers "why did you start this business?". It is a question that can get to the core values that all product decisions can be made upon. It is all about having a strategy.
Ignore the User, Know the Situation
Your product isn't better from the competition's just because you have crammed more features into it. Your long list of features makes good marketing material, but it also adds up to complicated software that confuses and frustrates users.
The above quote is a reoccurring message from this book, and one of my favourites. I can't even begin to count how many times I have been an accomplice to putting a band aid on new features that are being added in too late. These types of features end up costing the company way too much money, through bugs and user frustration.
Another brutal fact, Hoekman highlights is that the software should not block the user but keep them moving through the experience. Developers often throw dialog messages and widgets that reveal all the fanciness going behind the scenes. These types of messages get between the user and their goals. The users goals are personal and live outside the application.
The founders of 37 Signals didn't Design Basecamp to support who they are, They designed it to support what they were doing.
Hoekman touches on "Self Design" and it is something we all do. He provided examples from 37 Signals and how many of their successes is based on this practices. 37 Signals had internal problems and build many of their products as a solution to their problems. 37 Signals looked at the situation they had with project management. By immersing themselves in their own situation they were able to design a product that solved many of the issues they faced day to day.
Brutal Fact: People Lie... Questionnaires will produce quantifiable data, however it may be false. Hoekman provided an example of a Healthy sandwich being marketed by a fast food chain. When asking customers for market research would they be interested and eat this new sandwich, the overwhelming response was yes. However, the sandwich flopped. No one when asked would you eat this nice new healthy sandwich say "Hell, no - I want the regular greasy sandwich" People often don't do what they think they will do. If you asked, would you eat a over b, they will always choose the healthy choice in a questionnaire, they don't want to feel like an idiot. But that is not what they will do in reality.
Use Cases
Hoekman likes to add UI information into his use cases. He has some valid points, but it goes against all use case knowledge I have ever practiced. He even admits its not normal, however, it helps him visualize the experience better for himself and is an added aid for designers and developers. Sometimes I wear all three hats, so the concept was a little foreign to me. But I could see it having some value and he provides a good example of how he uses this.
Build Only What is Absolutely Necessary
In this chapter, Hoekman diggs back into the concept of What follows Why.
trying to match competing products feature-for-feature is like running through a battleground under cover fire. You can run all you want, but you have to keep shooting to get anywhere. Dishing out cover fire keeps you alive for a few minutes at a time. Long enough to hide. Companies that fight all the time to stay ahead fall into the endless cycle of trying to outdo the enemy.
AMEN.
The message of this chapter I found to be the most crucial for the success of a "good" user experience.
Stick to what is truly essential. It goes back to your strategy. If something on the UI isn't relevant to the user completing a task, get rid of it. Only provide information and tools that are essential for the user to complete a task that supports your overall strategy. I look at this as "Cutting the fat". Another important note Hoekman re-enforces is that "nice-to-have" and cool features should be shelved and only focus on the truly essential features.
Support The Users Mental Model
This chapter looks a little deeper into users as "people". To many engineers, this is a foreign concept but if you have ever done a contextual inquiry, you live by it. My favourite section from this chapter was "Are You Sure". Working in software, I have seen and even recommended these erroneous little dialogs. Hoekman provides great insight that these messages make the user feel dumb and do not help them move forward. The proper action should be to complete the task and provide an undo step to go back if it was a mistake.
Turn Beginners into Intermediates, Immediately
This chapter touches on patterns and learning curves. One of the more interesting sections to me was on help. Hoekman illustrates examples and research where Help is really only used by experts. It makes sense when you think about it, Help really only works when you know what you are looking for. I have worked with my own Documentation Department. we have tried to make it more tutorial based, but you still need to know what you are looking for.
Conclusion
Overall I found the first quarter of the book pretty tough to get through. However, I was really engaged during the last 3/4. The remaining of the book provides great examples and good chapters and thinking that can be put to practice. This is a book that belongs in your library. I would recommend picking this one up.
Buy this Book from
Amazon.ca
