Palm got it Right Ten Years Ago. So Why are we Still Suffering?

palmpilot.jpgTen years ago this week, Palm Computing debuted the Pilot 1000. 1996 seems like eons ago, but the major PDA market has been around for a very short amount of time, really. The primitiveness of that first machine is striking today; but what is even more striking is how the limitations of its hardware made it easier to use. It is a supreme example of constraints leading to superior creativity and execution.

Today even our cellphones have more computing power and graphics capability than those first Palms. In part, I think the relative lack of constraints on our cellphone designers have led them to become sloppy with their design choices, leading to products that are harder, less efficient, and more confusing to use. The designers are not doing their editorial duties. How many clicks, for example, does it take to edit an address book entry on your cellphone?

In the book Information Appliances and Beyond, author Eric Bergman interviews Rob Haitani. Haitani was the software architect at Palm and designed the Pilot’s OS and applications, and then followed Palm founder Jeff Hawkins to Handspring. This is one of the single best essays on UI and experience design that I’ve ever read - I return to it on a regular basis as a refresher. (There are several other excellent essays in this book, I highly recommend it overall. In particular the article about the development of the Psion PDA OS is also outstanding.) I’m going to quote a few things from the Haitani interview here (and hope that Bergman and Haitani don’t mind!).

We assumed we’d reject every feature unless there was a good reason not to. Saving files. Printing. By being merciless, at the end we were left with a very tight core of an operating system.… It all comes back to less is more. That’s because in handheld devices you have constraints that you don’t face with a desktop PC. (p.98)

Jeff [Hawkins] believed we had to make the product considerably smaller than current PDAs. He carved up a piece of wood in his garage and said this is the size he wanted. He’d walk around with this block in his pocket to feel what it was like. I would print up some screenshots as we were developing UI, and he’d hold it and pretend he was entering things, and people thought he was weird. He’d be in a meeting furiously scribbling on this mockup, and people would say, “Uh, Jeff, that’s a piece of wood.” (p.83)

Not enough designers spend time “eating their own dog food” as the expression goes, which partly explains the many confounding choices that lead to poor user experiences in complex gadgets.

On the Zoomer [the failed precursor to the Pilot], our philosphy was that we should put as many applications as possible in to make as many people happy as possible. After it shipped, though, we did some user research that made us question that decision. We found that there were a few applications that people used extensively, and usage very quickly dropped off after that. So we said why burden the product with all this extra functionality if people aren’t going to use it?…. When you’re in Silicon Valley the tech frenzy starts feeding on itself, and you end up losing context of what real people do with real products. (p.86)

To compensate for the slow processor in the Pilot, Haitani tried to strip all operations down to as few steps as possible to speed things up for the user. This caused a lot of arguments.

[S]omeone would say, “That’s just one more tap,” or “That would only take a second.” I would respond that it is analogous to the way you organize your desk in your office, in that you have some things on top of your desk and you have some things in drawers or file cabinets. Why is that? Well, if you look at the things on top of your desk, those are the things you use very frequently and they need to be easily within your grasp; whereas things in your drawer you don’t use as frequently. So I would say, Imagine taking something you use all the time like your mouse or the phone and put it in a drawer. It’s just one extra step to pull it out. But if you use it that frequently, the cumulative effect of that one extra step is excruciatingly annoying. (p.89)

Customers ask for features like kids ask for candy. In handheld design, you have to make the trade-offs for them. Robust functionality isn’t a benefit; it’s a cop-out. (p.99)

I wish more products today of all kinds followed these guidelines. Our lives would be a lot easier and less complicated as a result. We’ve know these things for a long time now - Palm employed them 10+ years ago, but didn’t invent them all. Why are we still having crappily designed electronic devices foisted on us?