A friend recently forwarded me an interview with Robert Cailliau, co-developer of the world wide web.  At one point Calliau says the inefficiency of the iPhone drives him crazy, asking why he must take eight steps to enter an appointment instead of two on his Treo.

“I like things to be beautiful,” he says. “But first and foremost they have to be productive…. This is totally ridiculous.… Why are we going backwards?”

Apple’s design philosophy emphasizes beauty and simplicity, sacrificing some efficiency. It’s wonderful to have a one-button phone, but that means it has to take more steps to do other things.

The genius behind Apple’s designs lies in a ruthless enforcement of simplicity. If you achieve purity of design, people tolerate significant limitations (like no copy and paste on the first iPhone). But if you bet on purity, you have to be all in. Once you spoil the purity, people stop forgiving the limitations.

In contrast, the original Palm OS philosophy emphasized the simplicity of efficiency, sacrificing beauty.  I sought purity in functional and visual efficiency. Ruthlessly minimize steps for frequent tasks. Press one button to power on and see your entire day’s schedule in a split second. Beauty wasn’t problematic in principle, but it was in practice–back then it would have required making a painfully slow and bulky mobile device.

Unfortunately, an interface optimized for stylus-based input for calendar and contacts (and 1995 hardware) cannot by definition be optimized for a keyboard-based phone with email, browser and camera.  Palm OS took us pretty far, but the purity was lost.  Apple started with a clean slate and succeeded with a new form of purity.

Palm later came back with webOS, bringing back beauty and fresh innovations to the interface. But I’d like to see a comeback for some of the ruthless efficiency of old. Maybe a few extra seconds doesn’t bother many people. But an iPhone processor is 37.5 times faster than a Pilot processor was.  I refuse to believe I’ll never be able to look up a phone number as quickly as I could fifteen years ago.

Products would be easier to use if designers had more empathy for users. We could start by stop calling people “users.” Does the Four Seasons call you an “occupant?” “User” suggests no relationship with the designer. If you poke something with a stick, you’re a “user” of the stick. If you pay me for my product, I call you a “customer.”

And why do we invoke “user error” to dismiss customer problems? If you click “Abort” instead of “Cancel,” we blame you, not our design.

I read a forum where a designer advocated using “Cancel” instead of “Abort.” Others objected, saying this argument was “strange” and would “confuse the user more.” (That word again.) After all, the difference is clear in “everyday language.”

Maybe. Navy Seals understand that “canceled” missions mean staying home, and “aborted” missions involve racing to extraction zones carrying wounded colleagues.

To programmers “cancel” requires restoring the previous state. It’s like the difference between getting out of Dodge (abort), and returning the rustled cattle first (cancel).

But customers using your software have no idea whether it’s an important distinction or not. If it doesn’t matter, why not use the simpler (albeit inaccurate) “Cancel?” If it does matter, could we say something less intimidating (like “stop”?), or better yet eliminate the need for the distinction? Sure, rounding up cattle is a pain (especially the ones stampeded off the cliff). But delighting customers is hard work, and “intimidating” typically isn’t considered delightful.

Labels and icons create design confusion because their context differs for customers and designers. To customers, they are like inkblot tests. A “V” icon could mean anything (View? Verify?). To designers they are labels for a fixed number of well-known features, like hints for multiple-choice tests.  To the ROYGBIV app designer, V obviously means “Violet.” (And given your knowledge of the color spectrum, you’re convinced people would be confused if you combined Violet and Indigo and called it “Purple.”)

Of course some features stubbornly resist clear description (Vitamin D Video definitely has some…!).  But Glenn Beck’s opinions notwithstanding, empathy is the first step towards good design.

"User error" or "we let down a customer?"

Have you ever used a product that is so difficult you asked yourself, “How did they ship this steaming pile?” Doesn’t anyone evaluate usability?

Many companies make mistakes conducting usability testing, but I want to discuss people who do it right–and still get it wrong.  In other words, when can results mislead you?

Usability testing typically involves showing people products and asking them to try several tasks. This gives you a good assessment of how easy your product is to learn, but could miss (or create) problems in other areas of usability.

For example, a designer once told me testing showed people couldn’t find a given feature. So they decided to display a dialog offering the feature every time you used the app. Problem solved. Unfortunately, other  problem created, as in, I can’t believe you show me this stupid screen every time. And follow-up testing testing might not detect such problems since people are more patient in “tests” than in real life (e.g., they may actually read wizard text rather than impatiently clicking “Next”). To cite the Heisenberg principle (albeit inaccurately), the act of measuring usability can affect the results.

Also, usability testing captures the first experience, not learning curves.  As novelty wears off, swearing may ensue.  Or conversely, some features are difficult to discover but delight customers anyway (classic example: ejecting Mac floppy disks by dragging to the trash).   A test subject once explained this paradox to me by saying, “it’s intuitive once you figure it out.” (Tip: when testing, repeat troublesome tasks to test retention.)

Most important, over time the value of intuitiveness declines, but the value of efficiency increases. You stop learning new features, but extra steps for the ones you use often become annoying. (For the theoretical extreme of “the most intuitive product ever,” see the Onion spoof of a Mac with no keyboard but a giant iPod wheel.  “Everything is just a few hundred clicks away.”)

In other words, myopic reliance on process can create a false sense of success.  Understand the limitations of usability testing, and augment it with real-world evaluation over time.

What causes feature creep? Conventional wisdom blames companies that don’t listen to customers, and/or customers who choose products with more features. I think it’s more complicated.

Regarding customers, if two products are otherwise identical, it’s rational to prefer the product with more features.  You need high-level innovation to keep customers out of the weeds.  (The iPhone shipped without copy and paste, for crying out loud.)

As for companies, some do listen to customers.  They ask how to improve the product, which leads to feature requests.  Unfortunately, this often means asking customers to predict the value of features they’ve never used.  You can generate valid data asking Hawaiians about snow shovels, but I wouldn’t design products around it.

Moreover, describing future features introduces positive bias. It’s easier to communicate feature benefits quickly than to articulate potential downsides (except maybe price).  Somehow surveys never ask, “what if it was slow and unreliable?” In focus groups it’s best if you can show a working prototype, but there’s also “novelty” bias. Like a first date, first impressions may not predict long-term happiness.

What’s worse, some people think focus groups are a failure if people don’t like their product.  This dangerous mistake can cost millions of dollars.  Your goal is to get the facts.  Clear consensus means a “successful” result, even if they hate your product.  Accurate news is better than good news.

So here’s a nutty suggestion:  do what doctors do. They don’t ask what treatment you’d prefer. They ask what hurts. Similarly, you can probe for pain points that your features could address, rather than ask customers to figure out the answers.  That’s your job. Henry Ford allegedly said, “If I had asked people what they wanted, they would have said faster horses.”   Today, customers requesting features may even have a different problem in mind than you do. (Like the PDA customer who asked for a spreadsheet–to keep his phone numbers.)  Find what customers need rather than ask what they want.

In other words, I’m not dismissing market research; I’m just saying don’t follow it blindly.  There is no substitute for thinking.

Products become smaller, faster, cheaper every year. My sports watch probably has more computing power than my first computer. But it’s harder to use than my last sports watch. Why doesn’t usability advance continuously? Why does it often regress?

Well with hardware, many advances involve greater density. Pack more transistors on a chip and it gets faster and smaller. But interface design faces a bottleneck: the brain. A psychology paper called “The Magical Number Seven, Plus or Minus Two,”  describes how your brain can only process a handful of items at once. Too many features on one screen and you can’t process them (unless you memorize them). Divide the features into too many different places and you can’t remember how to find them. So as features increase, information density creates cognitive gridlock like 880 at rush hour.

If you can’t widen the cognitive pipe, however, you can optimize. Fortunately, most people use only a fraction of product features. One study found people spend 80% of their time on 3.6% of the features (the “80/3.6 rule”?). Consequently, putting frequently used features on screen and hiding the rest in menus can make complexity feel simple (a.k.a., “Zen of Palm”). It’s not gridlock if the cars you care about get through because they’re in front. The intelligent computing equivalent is “relevance.” Instead of hours of video, show only clips of people coming through a door. Or instead of random shopping options, show likely choices based on my preference patterns.

Moreover, if software had any idea what you wanted to do, you wouldn’t have to hunt for features in the first place. UI structures act like filing systems for features. Over time, smart natural language input will provide more direct access to features than menus and cryptic icons. Ultimately, it’s easier to ask a librarian than to wander the shelves figuring out the Dewey Decimal System. (It’s similar to Clay Shirky’s description of how Google’s direct search supplanted Yahoo’s structured lists.) That’s what I mean by the (tongue-in-cheek) statement that intelligent computing will make interface design obsolete.

I said I’d write about user interface, so let’s start by asking why products are hard to use. Well, that’s a long discussion. But after trying to explain the brain in 350 words this can only be easier.

First, software interfaces are not constrained by the annoying laws of physics. It’s nice that you can jump anywhere, or things magically appear.  But the constraints of physics have an upside: predictability. Water wet. Fire bad. When traveling, you might wonder if you can drink the water, but you’re pretty sure you shouldn’t step into the campfire.

I’m reminded of a book called Einstein’s Dreams. Each chapter describes a world with different laws of physics—time flows backwards, or in circles. Trying new software is like entering different worlds where you have to figure out the rules. And some apps are like the world where cause and effect are erratic. If you can’t figure out or remember what action leads to what result (a “mental model”), you’re paralyzed.

Of course software is constrained by logic in the programmatic realm, where developers live. Your interface world is just a shadowy parallel existence. So why don’t we map UI to the programmatic world? We did once—it was called DOS. (Remember “dir/w…?”).

But aren’t there known UI conventions? Wouldn’t software be easy if designers followed consistent design conventions? Well, that’s like saying I’d understand molecular biology if you’d just use correct spelling and grammar. As lawyers say, “necessary but not sufficient.”  You must “edit” an interface, like you would prose, until it’s clear and concise. You also need  skill with metaphor. Suppress your understanding of how the technology works, and instead structure an interface around what your customer wants to do. I don’t want to launch phone.exe, query contacts DB, and call the telephony library. I want to tell my wife I’ll be late.

So that’s a high-level take at why smart people can make bad products. Later, I’ll talk about  why I think design processes are sometimes misguided, and the curse of feature creep.

Come on in, the fire's fine!