Trying something new and will ‘review’ a book for this post. I recently read ‘The Design of Everyday Things‘ by Don Norman and really enjoyed it. My intent in reading was to level up my design skills and gain empathy for how designers think about problems and solutions. In reading the book I realized it contains many lessons for Product Managers and I’ll detail the ones I found most valuable here.
The Psychopathology of Everyday Things
‘Great designers produce pleasurable experiences’ is how Norman opens this chapter. Here he sets the tone that design isn’t just how something looks, but how people remember their interaction. If it’s positive, there’s a good chance they’ll come back to use your product. And here we’re introduced to the fundamental principles of design that will enable these pleasurable experiences (some examples from the book, some my own).
- Discoverability -figuring out what actions are possible
- Results from the next five principles
- Affordances – a relationship between properties of an object and the capabilities of the actor that determine how the object can be used
- Example: A chair ‘affords’ (‘is for’) support and affords sitting
- Signifiers -ensuring discoverability of how to use/what to do
- Example: think of a carousel of photos in an iOS app with the small indicator dots (page controls)
- Constraints – guide actions and ease interpretation; can be physical, logical, semantic, cultural
- Example: The door to your home has the physical constraint of only allowing keys to be entered in a certain orientation
- Mappings -relationship between controls and their actions
- Example: an automobile seat control that is the same shape as the seat – push up to move the seat up, push back to move the seat back, etc.
- Feedback – continuous information about the results of actions performed
- Example: a loading indicator on a web page/app after you click a buy button and then a confirmation dialog
- Conceptual Model – providing the information needed to project understanding and a feeling of control; can often be inferred from the device itself
- Example: a pair of scissors; the holes are there to put something into- their size indicate it can only be fingers; the blades are sharp and clearly not for holding
Keep these in mind next time you sit down for a design review with the team. Instead of asking to make the button bigger, consider how these principles are used or not used. And maybe suggest improvements to make them stronger.
The Psychology of Everyday Actions
This chapter is concerned with how People are able to figure out what to do with technology and what happens when things go wrong. Norman provides the Seven Stages of Action as a framework for what’s going through a user’s head as they interact with a product. He also groups these actions by whether they help answer questions of execution (feedforward, #1-4) or whether they hep answer questions of what has happened (feedback, #5-7) They are:
- What do I want to accomplish?
- What are the alternative action sequences?
- What action can I do now?
- How do I do it?
- What happened?
- What does it mean?
- Is this okay? Have I accomplished my goal?
He places the burden on the designer to make sure the product provides the information necessary to answer each question. This ties back nicely with the fundamental principles as each of them can be used to answer a user’s question as they progress through the Seven Stages of Action.
We’ve all been in work situations where we attribute poor reviews to ‘user-error’ or say designs are good enough because ‘people will just figure it out.’ We do this to absolve ourselves of the responsibility and this drives Norman nuts. He says these ‘errors’ are more often than not a result of poor design and should really be called ‘system error.’ Human errors will occur and designers should anticipate them; using the fundamental principles is key in minimizing these errors. And when errors do occur, because they will, the errors should be as cost-free as possible.
Human Error? No, Bad Design
Norman furthers the error minimization argument by discussing the relationship between Humans and Technology. Humans are versatile and creative while Technology is rigid and precise; their collaboration can be a beautiful thing. He illustrates this with a Human + Calculator collaboration – humans figure out what’s worth solving and the calculator can precisely produce the solution. This reminds be a bit of the ‘Steve Jobs bicycle quote,’ where he calls the computer a bicycle for our mind. It heightens human performance to levels never known (Norman actually worked for Apple).
Difficulty occurs, however, when we don’t think of humans and technology as collaborators. Norman says this that this ends up requiring humans to behave in machine-like fashion by doing things like monitoring machines or repeatedly performing actions that require great precision. And when humans fail at these tasks, they are blamed for them. Errors will occur, but design should anticipate these and make them as inconsequential as possible. His principles for dealing with errors are:
- The knowledge required to operate technology should be knowledge in the world – this is NOT the knowledge acquired by extensive teaching or practice; think of the iPhone touch-screen keyboard. When introduced, people were already accustomed to the location of letters on a physical keyboard so this didn’t require specialized knowledge
- Use the power of natural and artificial constraints to ‘force’ humans into performing the correct action
- Make things visible for both execution and evaluation – make it apparent what actions can be performed (feedforward) and clearly communicate results of what happened (feedback)
Design Thinking
I read the Revised and Expanded Edition so I don’t think this chapter was covered in the original, but I’m glad Norman added it. He discusses best-practices such as defining problems before designing solutions, double-diamond model of design and human-centered design process. But he then quickly turns around and says that real world contexts don’t allow for any of this! Norman gives an anecdote of how a designer told him there are only two scenarios in which new products are actually introduced at their company: 1) adding features to match competition and 2) adding features driven by some new technology
I think many of us working on Product Teams can relate. Norman says that market-driven pressures and an engineering-driven company drive us toward more features, complexity and confusion. And even companies that do try to solve for customer needs run into problems like insufficient time or insufficient money that thwart their efforts.
So what can one do when faced with this reality? Norman writes that the only way to avoid the crunch that prevents the ability to do good up-front design research is to separate that process from the product team (I assume he means separate from development cycles). He argues to always have researchers out in the field studying potential customers and products and then when an initiative is green-lit, designers already have recommendations. I interpret this idea from Norman as Product Discovery, which has been written about in great detail by Marty Cagan and Teresa Torres. It’s a continuous, non-linear process that requires you to engage with your customers and understand their problems and present solutions in a quick and cheap manner. Product Discovery can be an antidote to the market pressures and feature factories because you’re constantly validating with customers and know what will stick and what won’t. You then use the results of this discovery to prioritize the biggest opportunities and push back on requests that might just be noise (always easier said than done).
Design In the World of Business
Norman starts this chapter by talking about something I’ve constantly grappled with in my Product career – ‘featuritis.’ Featuritis is the continual addition of features, even if the product is already successful and useful to customers. Norman writes ‘..it is rare the organization that is content to let a good product stay untouched.’ There is always the urge to keep building in any type of business environment, even if there’s no clear customer value in doing so. I think a lot of this comes from an engineering mindset where people just want to keep building and use the salaries paid to developers to justify this.
What can one do? A couple things I’ve tried to do to mitigate this are 1) remove features that aren’t performing if you are going to add more and 2) use learnings in Product Discovery to at least focus on the right problems to address if adding new features. Norman offers some help by citing Harvard Professor Yougme Moon’s book, Different, where she argues to double-down on strengths instead of matching feature by feature or ‘competition-driven design.’ If you are to build, build on what you are good at and ignore the irrelevant weaknesses. Norman writes that this requires support and understanding from your Leadership, but in my experience you cannot just wait for that to happen. I believe Product Teams need to ‘manage up’ and educate Leadership on these issues. Knowing your customers and your product metrics will help in telling your story.
The Moral Obligations of Design
Morality of design is a hot issue as 2018 draws to a close. Norman laments the use of design to promote superfluous consumption of objects, he writes ‘we are surrounded by objects of desire, not objects of use.’ I wonder what he’d say about products that ask for our constant attention and use our personal data in return for providing a feeling of connectedness among other things? He offers no easy solutions and I don’t expect any. He’s simply laying out the reality that readers of his book will face as they try to put his lessons into practice.
Thinking About Design
Norman concludes that the complexity and difficulty of Product Development are what makes it so rewarding. Yes, designers need to make things that satisfy people’s needs, but design in only successful if the final product is successful. This means having to work within engineering constraints so the design can be created on time; this means working with marketing to make sure you also design something that people actually want to buy; this means providing assistance to customers when they become confused about the product. Product Development is complex and it requires technical, business and personal skills to be able to work with so many parties and satisfy their requirements. Norman says there will be peaks and valleys throughout the process, but great products overcome the low and end up high.
And Norman reminds us to fight for and appreciate great design! Designers should fight for better usability and consumers should tell manufacturers about products with poor usability. Think about battles fought to make sure your favorite products shipped with good design; think kindly of the people that made sure it happened.