When Bad Design Happens to Good People – tcworld India 2016
I’m attending tcworld India 2016 in Bangalore. Edwin Skau gave a presentation entitled “When Bad Design Happens to Good People”. These are my notes from the session. All credit goes to Edwin, and any mistakes are my own.
Edwin started by saying that he focuses on how people think about what they do, rather than teaching people how to do something.
He told the story of the Steve Harvey, who mistakenly announced the wrong winner of Miss Universe 2015. Edwin showed us the card that Steve read the winner from, and we discussed how the design of the card led to Steve Harvey’s mistake. The mistake could have been prevented with better design. When bad things happen to good people, good people fail.
We looked at some definitions of design, and settled on this: “Design is a decision or decisions made to achieve a specific purpose.”
The purpose of training is to change behaviour. The purpose of technical communication is to empower users. Bad design leads to failure.
We looked at some hilarious examples of bad designs. An ATM that was high on a wall, and thus out of reach. Funny, frustrating error messages. Edwin had the audience giggling and even roaring with laughter. Then we saw an example of good design: a gadget that helps you put the pleats in a sari.
Jared M Spool talks about 3 approaches to design:
Self design – design something to suit the way you would use it. This often fails, because often you’re designing for people who are not like you.
Unintentional design – the design is forced by a decision made by someone at some time.
Research-based design – this is the best form of design. It’s based on user research: what the user uses the product for, what their win factors are, and so on.
Edwin discussed the features of good design. A well designed product is functional, useful, aesthetically pleasing, intuitive (making a user manual unnecessary), honest, and durable.
What about failures in information design? Edwin gave some examples, from some projects he had seen. These are some of the examples he mentioned:
Tabbed pages. Tabs hide information.
XML tags for every style.
PDF files produced from XML, where all topics of a particular type (concept, task, reference) are sorted together. This results in a guide that fails to help a user with a particular type.
Choose a tool first, then build a strategy around it.
Content sorted in alphabetical order by title.
Document the features, not the usage.
Forcing documentation into sprints. This can lead to over-documenting, and documenting what the developers have done rather than what the users will do.
You need to design the documentation process based on what you want to get out of the: where are we now, where are we going, what’s the most efficient way to get there from here. You must also figure out what you should not do.
A closing thought from Edwin: Quick wins are often the enemy of long-term gains.
I loved Edwin’s style of telling stories to illustrate his points. Thanks Edwin!
