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!

About Sarah Maddox

Technical writer, author and blogger in Sydney

Posted on 26 February 2016, in technical writing, Tekom tcworld and tagged . Bookmark the permalink. 4 Comments.

  1. Thank you for sharing, I especially like the 3 approaches to design. I see a lot of unintentional design (unfortunately), and now I have a name for it!

    I was surprised by this point in the sources of doc design failures: “Forcing documentation into sprints.” As long as you have the risks in mind (over-documenting and documenting how a feature has been built rather than how to accomplish things with it), I see benefits in forcing documentation to follow the development cycle. In particular, a writer’s questions can help find design flaws, and help developers understand what they are doing and why, thus sometimes helping them find better implementations for current and future development.

  2. Thanks for summarising my presentation so well, Sarah. I’m thrilled that you liked it.

  3. Hi Fanny,

    I thought Jared’s classification was really helpful, and useful enough to share.

    Somehow, I ran short of time and had to skip over some of the last few slides. I wanted to present design thinking as an approach to more than just the information design part of what we do. This includes (but is not limited to) designing out teams, our function, our entire package (skills, competencies) and process to achieve a specific goal, or fulfill a specific purpose.

    The Agile software development approach is designed specifically for software development. The documentation it speaks of is development documentation that must be updated at the end of each sprint in order to ensure that the design and architectural information is up-to-date. Leaving those changes undocumented is fraught with the worst kind of peril. I have seen teams spend close to a year fixing bugs that arose from two months of development activity, purely because they were flying without a map.

    The user documentation process must, however, follow a process optimised to achieve its own goals. If this involves documenting every sprint, then that’s how it should work. It shouldn’t be mandated, however, as in many situations this could lead to burnout, wasted effort, and rework. The Agile process also recommends documenting mature functionality, instead of nascent ideas.

    Thanks for raising this point. I see the need to write about this in greater detail.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: