A More Mauvy Shade of Pinky Russet

Here’s a quick UX analogy that resurfaced at work today (I think I first used it a year or two ago). “Don’t use the fishing net with small holes first, you might catch the dolphins by mistake.”

Lets say you have two sets of users – the “experts” who don’t want help and just want the data, and the “beginners” who need help, but might not realize it. You want to satisfy them both on the same page with (a) the data and (b) some help – which of the two – (a) or (b) do you put in the most prominent position on the page?

Of course there are no absolutes in UX design, but if the beginners are the dolphins and the data is the small net, putting the data in the most prominent position will satisfy your experts but will also catch your beginners who think they want it. However, if you put your big net (the help) first, it’ll catch the dolphins (beginners) and let the experts who know they don’t want it through to get to the data.

Design is iterative, right? While creating part two of the two-part “characteristics” diagram (part one: The Essential Characteristics of User Experience), I realized that it was actually a three-part diagram and that what I had created first, was actually last! So now it reads:

1. An introduction of “characteristics” and “principles”. (pdf | jpg)
2. The characteristics. (pdf | jpg)
3. The principles – formerly part one, “essential characteristics”. (pdf | jpg)

My thanks to Rob Weening, one of my colleagues at work, for helping me see this “re-frame”.  His flash of inspiration was that the characteristics are the building blocks of an experience (the “what”) and principles are how an experience is put together (the “how”).  The dodgy DNA analogy in the diagrams, however, is all my fault.

P.S.  Dave reminded me with his comment that the ten characteristics are almost certainly not an exhaustive list, they’re just a start.

There has been some discussion in the past few months about establishing a “language of critique” for user experience design. Jesse James Garrett may have started it with his closing plenary at the 2009 IA Summit in Memphis, it filled the IAI and IxDA mailing lists for a while and Erin Malone and James Melzer, among others, have blogged about it.

Here is my contribution (see the pdf), yes its a diagram. Its the first half of a two part diagram called “The Characteristics of User Experience”, this first part being the essential characteristics – the second part, coming soon, will be the secondary (or auxiliary, or periphery, I haven’t decided yet) characteristics.

Useful, Usable and Desirable have been touted for a long time as the hallmarks of a “good” user experience but they’re too generic and abstract. I think the five characteristics in this diagram are essential to any user experience being “good”. I’d love comments to stress test this!

A colleague (Mike Betz, Content Manager) recently sent this email:

“You’re on “Let’s Make a Deal.” The host, Monty Hall, shows you 3 doors and tells you that there’s a car behind 1 door, goats behind the other 2. If you choose the door with the car behind it, you get to keep it. The car, not the door.Wikipedia explains the problem in depth.”

You choose door #2. Monty reveals that door #3 has a goat behind it. Then he asks, “Do you want to stay with door # 2, or switch to door #1?” What should you do?

You probably thought, “I had a 1 in 3 chance of choosing the car originally. I still have a 1 in 3 chance. There’s no benefit to switching.”

And you’d be wrong.

Counter-intuitively, you’d double your chances of winning by switching to door #1. The Monty Hall problem baffled statisticians for much of the ’90s, but the salient fact is this: Monty knows where the car is. So no matter which door you choose originally, Monty will always open a door with a goat behind it. Monty’s knowledge, and your awareness of Monty’s knowledge, affect both your odds of winning (i.e., statistics) and your ability to determine where the car really is (your perception of reality).

It struck me as interesting, partly because I too found it difficult to believe until I sat down with paper and pencil and worked it out, but mostly because it later occured to me that we sometimes run into this situation in UX design. We use a “commonly held belief” to convince ourselves that a feature or design element is desired by users – only to (hopefully) realize that – after thinking through the specific scenarios – they don’t want or need it after all.