[A picture of private offices at Fog Creek Software]

Joel on Software

Great Design: What is Design? (First Draft)

by Joel Spolsky
Thursday, January 26, 2006

OK, buckle down, we've got a lot of ground to cover.

In our last episode, I introduced the tentative title "Great Design" for this series of articles. I have something very specific in mind when I use the words "great" and "design," and it's worth spending some time defining it.

First, "design."

Brownstones in New York CityYou know those gorgeous old brownstones in New York City? With the elaborate carvings, gargoyles, and beautiful iron fences? Well, if you dig up the old architectural plans, the architect would often just write something like "beautiful fretwork" on the drawing, and leave it up to the artisan, the old craftsman from Italy to come up with something, fully expecting that it will be beautiful.

That's not design. That's decoration. What we, in the software industry, collectively refer to as Lipstick on a Chicken. If you have been thinking that there is anything whatsoever in design that requires artistic skill, well, banish the thought. Immediately, swiftly, and promptly. Art can enhance design but the design itself is strictly an engineering problem. (But don't lose hope -- I'll talk more about beauty in future articles).

Design, for my purposes, is about making tradeoffs.

Let's design a trashcan for a city street corner, shall we?

Let me give you some design constraints.

It has to be pretty light, because the dustboys, er, sanitation engineers come by and they have to pick it up to dump the trash in the garbage truck.

Oh, and it has to be heavy, or it will blow away in the wind or get knocked over. (True story: I once got in an accident because a trash can blew in front of our car. Nobody was hurt, not even the trashcan.)

It has to be really big. People throw away a lot of trash throughout the day and at a busy intersection if you don't make it big enough, it overflows and garbage goes everywhere. When that happens, one of the little six-pack plastic ringy-dingies will get in the ocean, and a cute little birdy will get ensnared in it, and choke to death. YOU DON'T WANT TO KILL BIRDIES, DO YOU?

Oh, also, it needs to be pretty small, because otherwise it's going to take up room on the sidewalk, forcing the pedestrians to squeeze past each other, which, possibly, when the Effete Yuppie Listening to His iPod gets distracted by a really funny joke on the Ricky Gervais podcast and accidentally brushes against the Strangely Haunted Vietnam-Era Veteran, can result in an altercation of historic proportions.

Ok, light, heavy, big, and small. What else. It should be closed on the top, so rubbish doesn't fly away in the wind. It should be open on the top, so it's easy to throw things away.

It should be really, really, really cheap.

Notice a trend? When you're designing something, you often have a lot of conflicting constraints.

In fact, that's a key part of design: resolving all of these conflicting goals.

The only goal that usually doesn't conflict is the requirement that whatever you design be really, really cheap.

Every design decision involves tradeoffs, whether it's finding space for all your icons on the toolbar, picking the optimal balance of font size and information density, or deciding how best to use the limited space for buttons on a cellphone.

Bell System TelephoneEvery new feature is a tradeoff, between the people who could really use such a feature and the people who are just going to get overwhelmed by all the options. The reason 1950s-era telephones were so much easier to use than modern office phones is that they just didn't do much. Without voicemail, conference calling, three-way calling, and Java games, all you need is a way to dial numbers and hang up on the man claiming to be selling police benevolence.

By which I mean to say: even if you think your new feature is all good and can't hurt because "people who don't care can just ignore it," you're forgetting that the people who allegedly don't care are still forced to look at your feature and figure out if they need it.

"How could a mute button on a sound system hurt?" After all, if you don't want to waste time learning about the mute button, you can just ignore it completely, right?

No. Because at some point, someone will hit it by mistake, and no sound will come out of the speakers, and if they don't know about "mute," they'll start trying to turn up the volume knob all the way, so when they do finally unmute the thing, the speakers will blow out with an ear-shattering boom that creates permanent, concave warps in each of the walls of the room where the sound system was installed (and a matching hump in the floor of the apartment upstairs).

And since the mute button takes up space on the control panel, now all the other control panel buttons have to be a bit smaller, making them harder to read, and there are more buttons, so the whole interface looks scarier. I swear, it's gotten to the point where I don't dare try to use the clock radio in a hotel room to wake me up. With all the options they have I can never quite tell if I'm setting the alarm clock to wake me up in time for my Very Important Meeting, or programming the damn thing to download the latest news from Mongolia on the half-hour.

"So," you think, "simplicity, is that it?" No! I wish it was that easy!

Because without conference calling, you're just not going to sell any office telephones.

If the nifty graphics application you developed doesn't give users 16777216 choices for colors, you're not going to sell a copy to Yale, which needs Yale Blue (Pantone 289) for all their documents.

You see? There are two requirements: lots of features and few features. Ah! And that is where the zen-like mystery of design comes in. When you're designing, you're satisfying lots of difficult constraints. One false move, and you fall into the abyss. It's frigging hard to get this right. You think I know how to solve the Motorola RAZR phone power-switch button? Heck no! I'm sure that the design team over there spent weeks working on this. I'm sure that some engineer or team of engineers went to absolutely heroic lengths, staying up late and coming in on weekends, to make the RAZR keyboard light up right away when you press the ON button, even though you don't notice this in daylight, because they know about the problem I whined about in the introduction and just couldn't do anything about it because turning on a modern cellphone requires booting up a computer, and not a very fast computer, for that matter, before you can get things on the main screen to light up.

Design Adds Value Faster Than It Adds Cost

The Motorola RAZR is now selling at a rate of about four million units each month -- 1.5 per second. If Motorola spends another $million or two improving the design, they can make it back in a day.

Design is something you only have to pay for once for your product. It's a part of the fixed costs in the equation, not the variable costs. But it adds value to every unit sold. That's what Thomas C. Gale, the famous Chrysler automobile designer who retired in 2001, meant when he said that "Good design adds value faster than it adds cost."

(Footnote: AUTOS ON FRIDAY/Design; He Put a New Face on Chrysler, The New York Times, Published: February 9, 2001, by By JIM MCCRAW , Late Edition - Final, Section F, Page 1, Column 1)

That's what makes it so important. By the time I've finished this series of articles, I think you'll be utterly convinced that nothing matters more to a product's success -- whether it's a software product, website, cell phone, or garbage can -- than good design. And as for great design? Well, that's coming up in the next installment. Stay tuned.

 


Have you been wondering about Distributed Version Control? It has been a huge productivity boon for us, so I wrote Hg Init, a Mercurial tutorial—check it out!

Next:

What Makes It Great? (First Draft)



Want to know more?

You’re reading Joel on Software, stuffed with years and years of completely raving mad articles about software development, managing software teams, designing user interfaces, running successful software companies, and rubber duckies.



About the author.

I’m Joel Spolsky, co-founder of Fog Creek Software, a New York company that proves that you can treat programmers well and still be highly profitable. Programmers get private offices, free lunch, and work 40 hours a week. Customers only pay for software if they’re delighted. We make Trello, easy web-based collaboration software, FogBugz, an enlightened bug tracking and software development tool, and Kiln, a distributed source control system that will blow your socks off. I’m also the co-founder and CEO of Stack Exchange. More about me.

© 2000-2014 Joel Spolsky