A handle on good design

I recently reposted a photo on Twitter that I thought neatly encapsulated poor design.

This documentation would benefit from end-user testing. pic.twitter.com/7MsWvu9lDp Via @authorterryo

— Peter Anghelides (@anghelides) February 21, 2014

Within a few days, this was retweeted hundreds of times. With the various modified and quoted versions of it, Terry Odell’s original photo has now been retweeted over a thousand times. It seems to have caught the imagination of many, and not just technical authors.

Credit: Reuters

Subsequently, Alexis Hale politely pointed out that the sign was “literally a joke from the Wayside School series.” Nevertheless, I still claim it as an example (deliberate or otherwise) of when documentation makes things worse — and when better design could avoid the need for documentation in the first place. Because obviously technical writers are like those staff in Tesco wearing a badge saying…

“Here to help”

I was walking through the airport, and noticed a man carrying two heavy suitcases through the arrivals terminal after passport control. I could tell they were heavy from the way he was struggling, and they’d got those orange warning labels on them (an example of simple, effective design).

Credit: Philipp Bock (youMayCallMeSheep)

As I watched him grip the handles to drag his baggage towards the taxi rank, I saw he had this fabulous-looking watch on his wrist. “Oh yeah,” he said, “it’s very clever. It tells the time in all the countries that I do business. It gives me access to my e-mail, shows me my calendar, warns me about forthcoming meetings. It’s got a built-in stills camera and a phone with a little video screen. It’s got functions for recharging via kinetic energy and solar power. It checks my pulse and skin temperature and warns me when I might be ill. It plays music from all the albums I’ve stored on my home server. So it’s OK, I suppose.”

“OK?” I told him. “It sounds fantastic! But if you don’t mind me saying, you don’t seem very happy with it.”

“Well,” he said, hefting the two heavy suitcases, “look at all this documentation you need to carry round for it.”

When I first told that gag, the iPhone and Galaxy Gear were still Star Trek technology of the future. But those of us who remember early digital watches can still recall thinking, “There are only a couple of buttons, so how difficult can it be?” And then struggling to set the alarm. And subsequently struggling to deactivate the alarm when it went off.

Minimal interface isn’t a guarantee of simplicity. But designing a product to be easy to use, rather than creating a lot of documentation, is what will succeed in the marketplace. Good design makes use obvious, and behaves the way you expect, and so you avoid providing documentation that’s not absolutely necessary.

The smarter you are about avoiding the need for documentation, the smarter the documentation is that you end up producing.

And yet, when my mum got a new watch from a famous, very reputable brand not so long ago, the instructions for setting the date told her this:

Do not set day/date between 8:30pm and 5:00 am as day/date change cycle is in progress.

It’s an admission of design failure if one of the functions of your product can’t be used properly for 8½ hours of the day.

Walk up and confuse

All too often, an interface you expect to be “walk up and use” ends up just confusing. When I talk to technical authors, it may seem heretical to assert that no-one really wants to read product documentation. Not even technical authors.  Who honestly wakes up and says, “You know what, today I really fancy reading an instruction manual. I’d like nothing better than to study how to install and configure some database software.” 

You pick up an instruction manual because you’ve got stuck attempting to do something, or don’t know where to start when trying to achieve some task. You want to find that out as quickly as possible, and go back to what you were doing. It’s all about the task and not the product, and it definitely isn’t about the manual. I don’t think “I’d like to use the iPhone interface this afternoon,” I think “I want to listen to that track by The Doors, and maybe buy it.” (Yes, I am that old.)

My first iPhone

The iPhone is an aspiration for all consumer products: it’s almost literally walk-up-and-use. Like Doctor Who’s sonic screwdriver – a multitude of uses, but the Doctor never has to fumble around for the instruction manual. On my iPhone, I can rapidly work out how scroll, open, close, cut, copy, paste etc. all work. And it’s only got a few buttons, and they do pretty basic things that can be simply explained.

Even more interesting, my experience is that most of the documentation for the “difficult” stuff is searchable online and not written by Apple.

 

Doors to manual

Doors don’t do documentation (credit: wikimedia)

The simplest things can be overcomplicated by documentation. You wouldn’t expect to get all this specification information about how to use a door. As Don Norman pointed out in his excellent book The Design of Everyday Things, a  well-designed door is literally walk-up-and-use:

• It will have appropriate affordances – plates that invite you to push, and handles that look like they need you to pull, which tell you all you need to know.
• Just one word of documentation is too much, especially when those two words are look as similar as PUSH and PULL.
• If you disagree with that, then ask yourself how much you want to read and work out if you’re trying to operate a fire door in an emergency.

And yet we still encounter poorly designed doors. What hope do we have for easy-to-use software if we can’t do doors?

Hursley doors

IBM has a renewed focus on Design Thinking that is transforming the way software and solutions are created. And although office doors aren’t something IBM designs and builds, I like to use the example of doors at IBM Hursley (installed in the 1980s) as how not to design simple things things simply.

These doors are one of the first things our visiting clients encounter when they arrive, and one of the last things they use before they leave. In comparison with them, the self-flushing cisterns and soap dispensers in our on-site toilets are a miracle of modern technology.

All IBM buildings are badge-controlled for security. There are two ways to enter IBM Hursley from our Main Reception. The first question is: which set of doors to choose?

There is a pair of doors to either side of the welcome desk. The receptionist or your IBM host can tell you which pair to choose, I suppose – though some visitors are from other IBM sites, and they do not need to “sign in” or speak to the receptionists. (You should do, even if just to say hello – they’re lovely. Not everyone does, but people are strange.)

Perhaps you decide to try and to work it out for yourself.

   

When you approach your chosen set of doors, you’ll find there is some documentation:

• Policy rules about having to wear a badge, and having to use your ID card in the door’s badge reader.
• An image on the badge reader showing you how to orient your magstripe.
• A red PUSH printed into the upper part of a long metal handle that looks like it’s designed to pull.
• But there are also two metal plates (which stop the door swinging beyond the frame) that look like push plates.
• And finally, because the latch tends to stick and you therefore need to “rattle” the door a bit to disengage it, there’s a further sign in a different font that tells you to “PULL and then PUSH door” with a sad little coda that says “thank you.”

Now you’ve decided which order to read these signs in, and chosen which of the two doors to use. You may have a confusing moment if someone comes through one of the doors, because they’re designed as unique “in” and “out” doors, like those for a restaurant kitchen. And depending whether you choose the left pair or the right pair, the “in” door is different. 

Once you get through the door, you’ll find yourself in a through corridor – and realise that it didn’t matter which pair of doors you chose, because both sets lead in here.

On your way out, you will probably remember that it doesn’t matter which doors you choose for leaving the building. Unless you forget, or you came into the building via a different route. There’s no clear indication that these doors lead to Reception and the exit. Perhaps you’ll recognise the distinctive furniture through the non-opaque parts of the door.

But even if you do remember, the way you get out through the same pair of doors is different from the way you get in. That’s because you don’t need badge access to get into Reception, and so the sequence is:

• Press a button, and wait for the light to go green
• Choose the correct door, rattle the handle, and then push.

It will reassure you to know that this design was not the handiwork of the IBM documentation teams responsible for products, nor were the doors designed by IBM. Now that they are installed, it’s admittedly a bit harder to redesign and replace the doors. And perhaps those of us who have worked at IBM Hursley for a while have simply got used to them.

But then perhaps we’d assume that people would get used to knowing how to use stairs. Which is where this blog post started. And that’s even before we take into account that not everyone finds it easy to use stairs. 

Source: Global Street Art Blog