90 percent of everything : Usability Blog

Written by Harry Brignull

A few days ago, a friend of mine told me a story about their first visit to IDEO. At one point in their tour they saw a dozen Design Researchers standing in a makeshift kitchen, each holding a different brand of frying pan, flipping pancakes over and over again. There was one person watching and taking notes on a clipboard.

Sounds bizarre, doesn’t it? Almost like a scene from Kitchen Stories. In actual fact, there was nothing weird going on – they’d simply been hired to do some design consultancy for a frying pan manufacturer, and they were doing a competitor evaluation. Some pan shapes, weights, sizes and materials are simply better suited to the ergonomics of pancake-making than others. By looking at the competitors, they neatly kick-started their knowledge of frying pan design.

Competitor evaluations are hugely beneficial at the beginning of a project, but for some reason they’ve got a bad reputation among many designers who see them as uninspiring and uncreative. Personally, I think this is nonsense. Knowing how a competitor solved a problem shouldn’t determine your solution, and without knowing the landscape of competitor designs you can easy stumble and waste time. Here’s an example: the Mail Online iPad app first-run user journey.

Step 1: when we start the app for the first time, we’re taken straight into a tutorial. What are we learning here? Not much, but there’s something about syncing mentioned there at the end.

Step 2: a detailed explanation on how to sync. They’re clearly concerned about users syncing over 3G and then getting hit with a huge bill – a valid concern, but is it worth this much emphasis?

Step 3: another entire screen dedicated to syncing. That’s some heavy instructions right there.

Step 4: can you believe it? Yet more information on syncing. What’s crazy is that there’s 15 more pages in the this tutorial. Lucky they put in that “skip tutorial” button!

Here’s my point: had the designers of the Mail Online app taken the time to do a quick competitor evaluation, they’ve have have realised that ZERO competitor apps make such a big deal out of syncing, and none of them are getting negative App Store reviews as a result – in fact, quite the opposite is true. Meanwhile, the Mail Online app has ended up with a tedious first-run experience. It pays to know which design patterns work well in your problem space and which ones don’t. Of course you’re never going to get a groundbreaking UX off the back of a competitor evaluation alone, but it’s a good place to start.

In other words – don’t forget to flip those pancakes.

If this is true, it has to be the most famous, most catastrophic UI design blunder ever:

“The error on the ship’s maiden voyage between Southampton and New York in 1912 happened because at the time seagoing was undergoing enormous upheaval because of the conversion from sail to steam ships. The change meant there was two different steering systems and different commands attached to them. Some of the crew on the Titanic were used to the archaic Tiller Orders associated with sailing ships and some to the more modern Rudder Orders. Crucially, the two steering systems were the complete opposite of one another. So a command to turn “hard a starboard” meant turn the wheel right under the Tiller system and left under the Rudder. When First Officer William Murdoch spotted the iceberg two miles away, his “hard a-starboard” order was misinterpreted by the Quartermaster Robert Hitchins. He turned the ship right instead of left and, even though he was almost immediately told to correct it, it was too late and the side of the starboard bow was ripped out by the iceberg. “The steersman panicked and the real reason why Titanic hit the iceberg, which has never come to light before, is because he turned the wheel the wrong way,” said Lady Patten…”
- from Titanic sunk by steering blunder, new book claims By Richard Alleyne (21-Sept-2010)

It makes you wonder wonder what the hell was running through the engineers’ minds when they decided to have two steering systems with inverted controls, so on one system left meant left, and on the other left meant right. Maybe they shaved a few thousand dollars off the total build cost. Crazy.

Update 1: I stand corrected (Thanks Tony!) – what this amounts to is a catastrophic migration issue – the Quartermaster was used to sail ships where their orders and mechanics of steering worked one way. On the Titanic, the orders and mechanics were allegedly different, hence the confusion. You can read more about this in “That Damned Ship’s Wheel!” by Dave Gittins, quoted below:

“Until relatively recent times, naval seaman in particular had to steer vessels by at least five steering systems, not counting the obsolete whipstaff. Large ships had wheels. Small power and sailing boats had tillers and some boats, such as whale boats and some lifeboats, had steering oars. Rowing boats were often steered by a steering yoke controlled by short lengths of rope. In an emergency, large ships were sometimes steered by tackles attached to the tiller below decks. At a pinch, Titanic could be steered by connecting her warping capstans to the tiller. It simplified things if the officer in charge gave all orders with reference to a real or hypothetical tiller. It was part of a seaman’s skills to react correctly to the order.”

Update 2: OK, I’ve now had feedback from a few people saying that this story is not about the steering controls but about the orders from the officers in charge. Prior to the 1930s, officers used tiller orders (if you want to go one way, you push the tiller the other way) After the 1930s, they switched to rudder orders (you steer in the direction you want to go). The theory is that there was some confusion due to the switch over from one style of controls to another. However, since the Titanic sank in 1912, they are highly unlikely to have been in the middle of a rudder/tiller order switch over.