Friday, October 22, 2010


(cross posted to )

Engineers are not great product designers. There - I said it.

Programmers are conditioned that way, but most people tend to over-do designs. We grow up with choice and believe more choices make our lives better. That's not usually the case. Things that are simple to use are easier for people to understand and use, easier to explain, easier to sell. This doesn't mean they're simple - think of the iPhone's one button. There are a couple of others hidden away, but there's just one button you use to get its attention, go back to start, navigate.

Programmers are conditioned to over-complicate things because that's what they see when they start writing code. Programmers use components called API to write their applications. API make up the basic capabilities of the system they write the application for. Think for example of the ability to put a pixel on the screen, to draw a line, to make a sound. They all make themselves available through API (application programming interfaceS). The thing with API is that they are usually built to support a lot of things the programmer might want to do. For example do you want the line to be smooth, or jagged. Should it have round edges, or pointy ones, or maybe arrow-heads? Is it a dashed-line? what dash pattern would you like?

So much choice!

To show you how the thinking goes, let's "design" a website to tell people about the weather. What would we need?

We want the user to tell us where they are. They can use a zip code, or an address, or point on the map, right? Whatever is more convenient for them.

Then we want to show them the weather today. That means the temperature and the chance of rain or snow.

Now uncle Bob has rheumatism and he feels it in his bones when the humidity is high. Let's add humidity so the rest of the family can check up on him.

Our temperature is in farenheit, but we've got some foreign friends that came to the US and still think in Celsius, so let's give them the option to see the temperature on that weird scale.

And auntie Jane wants to know the hour-by-hour forecast so that she can know what clothes to pack for her trip to the store.

And cousin Jim wants to know what tomorrow's going to be like, so let's give him the option to see the forecast tomorrow and for the rest of the week.

Tada! We've described the swiss army knife of weather applications, something that's all things to everyone. Difficult to use, difficult to explain, and just how would you tell users why you're different than

Now let's look at a minimalistic design for a weather app. Let's say we don't want to serve the entire world, but rather find a core set of users that will really really like our service, and will be able to explain it easily to their friends.

The folks at Thoughtbot have done just that - . The service was put together by Thoughtbot, a ruby-on-rails shop, to showcase simplicity. The service does one thing and one thing only - it sends you an email in the morning if (and only if) you need to take an umbrella with you today. It's extremely focused - it serves those people (like me) who need to know if it's going to rain on them or not, so that they can grab the umbrella on their way out the door. It won't serve aunt Jane or cousin Jim, but it will cause fans like me to use it and tell people about it.

So what do you need to do to use it? enter your email, your zip code, and the time of day you want to get the email. That's it. No options, no selections, no different views. It either works for you or it doesn't - it's that simple. And most developers will not be able to design something like this.

Would you?