Category: design

On Simplicity

This originally appeared on the Joel on Software discussion group. This issue was the value of simplicity in product design, and whether it requires removing features.

There is a difference between features of the product and features exposed in the user interface.  Take automobile traction control as an example.  If you don’t know, it uses sensors in each wheel to detect a slipping wheel and either apply the brakes or limit power to that wheel until it stops slipping.  Many cars have this feature now, but most don’t have any user interface to it.

Some cars, though, have a button you can press when you’re driving in icy conditions.  This changes the response of the system to be more aggressive about stopping wheelspin.

Then there’s the Corvette.  The first version to have traction control had the option to completely disable it.  Under racetrack conditions, sometimes the fastest line requires intentionally sliding the rear end to set up for the next turn.  Traction control can’t anticipate that.

In the real world, how many people are actually good enough drivers that they can take advantage of that exceptional condition?  How often are they really able to take advantage of it?  How many ever have?

Now how many people want to believe that someday they’ll drive like that?  The feature makes the car better.  Needlessly exposing the feature in the user interface makes the car more marketable.  People like to believe they’re not average, but instead the elite for whom “good enough” just isn’t.

A related phenomenon leads to Jeep commercials touting the off-road prowess of vehicles that, for the most part, never leave the suburbs.  People want to believe that they someday will do something exceptional, and want their product to support that belief.

Nissan, back when they were called Datsun, once had a commercial that came right out and said it: “You won’t go 0-50 in 6 seconds flat but you know you could.  You won’t use it’s drag speed of over 100 mp/h but you know you could.  And when the light turns green you won’t flaunt your turbo power but knowing you could is awesome!”

https://www.youtube.com/watch?v=CgAxVtZbPZo

Now apply this to the washing machine that senses what kind of load it has.  Personally, I can’t think of many things I care less about than my skill in classifying loads of laundry.  But I would still have trouble accepting a salesman’s pitch that really, the machine is smarter than me about this.  If Consumer Reports backed it up, though, I’d take a one-button washer and a one-button dryer.

===

Now consider the first iPod. It didn’t play several poplar audio file formats. Lack of this capability is not “simplicity”.  If the codecs were added, the user interface wouldn’t have to change.  More features, same simplicity.

===

Then there are cars with remote keyless entry that doesn’t depend on pressing a button. Simply approach the car with the fob in your pocket and the doors unlock. Very simple. But there are times you need to decide whether the car is locked or not

  • If you have your spare keys in your gym bag in the trunk when you walk away, the car doesn’t lock. Oops.
  • You can’t leave the car unlocked while you and the kids make several trips to unload groceries.  You’d have to hand off the remote every time one of you goes down.

I think the process probably could be simplified, but I would want extensive usability testing and design work before I would take a car that decided for me when to be locked and when to be unlocked.

===

Finally, consider two different cars.

Vehicle #1:

  • Three-speed stick shift
  • Two-wheel drive
  • Solid rear axle

Vehicle #2:

  • Seven-speed automatic
  • Adaptive all-wheel drive
  • Positraction
  • Traction control

Which one is simpler?  Hmm, that depends.  Do you mean simpler in design, or simpler for the user?

Let’s make it closer, and say Vehicle #1 is now an automatic.  Now they’re equally simple for the user.  But Vehicle #2 does more, making the decisions for the user.

In “Choices = Headaches” Joel said the user interface should be simple.  Not that the features shouldn’t be there, just that the user shouldn’t have to chose when to use which.

Who Wants a Netbook?


Photo by: zieak

I know what I want a netbook for. First I’m a guy, and it’s a gadget, and it’s just cool as hell. So yeah, I want an expensive toy. But beyond that, it’s something that’s small enough I can take it with me almost anywhere and get some work done. It’s more capable than a smartphone at all of the non-phone things. (And by the way, I still want a plain old phone that just makes calls and stores phone numbers. Can I buy that, please?)

But I don’t understand who the target market is

What Do They Do?

The iPhone does things no other cellphone did, in a form factor that lets you bring it places you wouldn’t bring a laptop. So no matter which you compare it to, there’s something the iPhone does that was unique.

What does a netbook do that’s unique? It’s smaller than a laptop, but not so much so that you’ll throw it in your pocket and have it always with you. You can, but you won’t, it’s just a bit too big for that.

It’s more usable than a phone, with a more human-scale user interface, but not as usable as a sub-notebook.

That leaves … playing DVDs? And games? When I said I wanted a toy I didn’t mean that’s all I thought it was good for. But now I’m not so sure. Where would I realistically want to have a computer, that I could have a netbook, that I wouldn’t want to have a laptop?

I’m coming up blank here.

Design = function + aesthetics

Ask your local programmer if he knows how to design user interfaces and invariably he’ll say he does. Go ahead, ask. I’ll wait.

…

You’re back? Good. Now go look at the new iPhone. Has your guy ever made anything remotely that cool? Unless you’re reading this from Cupertino, odds are he hasn’t. The UI is more beautiful and, as near as I can tell from the demo movies, more usable than any other phone or music player I’ve seen. But I wonder, how much of the perceived usability is a response to the beauty?

It’s becoming conventional wisdom that you don’t want to make the demo look done. Excessive visual polish early in the process not only limits the feedback you get to comments about the superficial details, it also suggests equally finished interaction with the system. It literally makes it look like it’s doing more than it really is doing.

I’ve avoided this problem in my career by not being very good at graphics, and avoided realizing that by not working with any real visual artists to compare my work to. Yes, I used to think I was good at it, just like every programmer. Eventually I realized that consistency and predictability were a poor subset of what an artist can add.

Now, whenever I make up a project plan, there is a task at the end for “Add Pretty”. And my name isn’t on that task.

When design is not design

“How is software production like the car industry?”

Oh no, not again. Yeah, well, most people are getting it wrong. So here’s another shot at it.

There are aspects of car design that strictly deal with measurable quality: performance of the electrical system, horsepower, fuel economy, reliability. But the shape and style of the car are much more loosely coupled to hard-and-fast measurements. That facet of the design — the way it looks, the demographic it will appeal to — is not amenable to Six Sigma processes.

Granted, there are some cars that are strictly (or nearly so) utilitarian. Some people only care about efficiency and reliability. They buy Corollas by the boatload. But the FJ Cruiser is not the result of a logical, statistical analysis, with high conformance to the mean and low variation of anything.

I think what I’m trying to say is that marketing design is building the right thing, while production design is building the thing right. The auto industry is mature enough that you need both. Success in the software industry still relies more on building the right thing.

Blinded by experience

Don Norman knows more about design than I ever will. He even “knows” a few things that aren’t even true. That’s some powerful knowing! Specifically:

You cannot successfully introduce a non-qwerty keyboard today, or reverse the window scroll bar convention, or suddenly require double-clicking on web links.

I think Don has spent too much time lately with experienced web users, and not watching people like Lou, my father-in-law. Lou is a retired printing production manager, who trained as a graphic artist and worked for several ad agencies. He got one of the first Macs so he could use PageMaker, and used Photoshop when it was still owned by Aldus.

Lou “knows” that you have to double-click things with the mouse. He has known that for over 20 years. I’ve tried to point out that you don’t have to do that on the web. He does it anyway. His current computer runs Windows 95, so if I wanted to I could set the option to use single-click select globally. I would never set that preference on his system, though. It would drive him insane.

But Microsoft did introduce the new behavior. There is a generation that has grown up using it. Could someone do the same thing with web links? They’d have to have market penetration comparable to what Microsoft had with Windows 95, but yes, they could do it.

Here’s where it gets interesting. You could reasonably support either side of this decision: There are people who “know” that you double-click everything, and people who “know” that you single-click everything. Either one will be frustrated by a system that does the opposite. But knowing that both kinds of people exist, what should we do? In the Hippocratic tradition, first do no harm.

I can’t count the number of sites I’ve seen that instruct users to “Only click the Submit button once.” Or “Please wait for the page to load.” As soon as we start warning users what they should or shouldn’t do, two things should be apparent:

  1. Users, for some reason, think that they should do the very thing we’re telling them not to do.
  2. Some of them are going to do it despite our warnings.

If we can’t prevent users from doing the “wrong” thing with our applications, we owe it to them to at least make sure that they don’t break anything when they do.