Simplicity Rules

It’s been quite the ride for my favorite monkey, but I’m delighted to see that Wired has resuscitated Webmonkey, the how-to site that helped many in the early days learn how to make the web work.

For those who don’t know the backstory, Webmonkey was mothballed almost two years ago. Before that, it was revived from a previous death. This time looks for real because Wired owns the site and did some work to re-architect it.

What makes me happiest about Webmonkey’s return is that it received a lot of attention before launch this time. The site, now mostly a Wiki, looks like it belongs in 2008. Readers can rate articles, comment, and edit them when they get out-dated. Major props to Mike Calore and his team for their effort to bring the ‘monkey back in such a big way.

Since 2000, I’m proud to have been a Webmonkey author. Over the last couple months, I’ve been writing a few more how-tos that will make their way online in the next few weeks. I’m proud to be part of it again. Welcome back, Webmonkey!

John shows the above example of unnecessary complexity that he found in a San Francisco Muni station. To get $1.50 in change, you put one dollar into one machine to get a dollar coin, then another dollar in the other machine to get quarters.

Then, I assume, there is a third machine that takes both types of coins.

Ick.

This post is part of a series about Designing the Obvious, a book about common sense Web application design. Learn more about this series.

As long-time readers know, I love time-boxing tricks: POWER HOUR, 4 day work week, 7 day product. Working within artificial constraints can make things easier on you and simpler for your users/customers.

Designing the Obvious has another trick you can add to your arsenal: the 60-second deadline. Here’s the scenario:

“The project timeline has been cut in half. We have about 60 seconds o decide what to keep and what to throw away before we meet with the client in the conference room.”

The author recommends writing all your features on a piece of paper, then starting the clock. You have 60 seconds to draw a line through the features you don’t absolutely need.

If there’s any doubt, cross it out.

The 60 second deadline is a great method to trim to the barest essentials. The first law of Simplicity is to reduce.

The 80/20 Rule

What happens to all those crossed out features? They go on the “nice to have” list. Maybe you’ll get to them later. For most, you will likely realize they weren’t really that nice-to-have.

“Yes, some of the remaining 80% of your features may be useful somehow, to someone, some of the time, but they are most likely useless to 80% of your users, 80% of the time. And you probably spent 80% of your development time building things that aren’t that essential to your application.”

What the book is describing is the 80/20 rule, or Pareto Principle. It says the first 80% of functionality can be built with 20% of the time it would take to finish the entire application. That leaves 80% of your time to finish those few pesky 20% of features… the ones that will be used least by the fewest people and may only add more complexity to your core feature set. That isn’t worth it.

How do you determine what is or isn’t important? What do you think about asking users to do the crossing out? Share your thoughts below and I may be able to share an autographed copy of Designing the Obvious with you. I’ll be randomly picking three people from everyone who commented during my series.

This post is part of a series about Designing the Obvious, a book about common sense Web application design. Learn more about this series.

When you cut your finger, you put a band-aid on. It doesn’t fix the cut, but it hides your wound from the world. In the face of an interface problem, the natural reaction is to place the equivalent of a band-aid over it. Too often, this doesn’t do much to change the underlying problem.

For example, here is my least favorite thing about MySpace:

Whenever a user clicks something that requires a login, MySpace redirects to the home page for authentication. This probably confused some users, naturally, because nothing was guiding them along. So, MySpace’s solution is to include a big red box with an exclamatory message that feels like a hand slap.

The red box is a band-aid for a broken login process. The login itself may be another band-aid for a broken privacy plan. Who knows the series of decisions that ended up at this point, but something is damaged, and the band-aids aren’t helping.

Designing the Obvious says:

“I don’t like band-aids. Instead of putting band-aids on problems, I perform surgery on them. Interface surgery.”

The book has several examples of interface surgery, where the author solves a problem by improving it a bit at a time. You may not agree with all the steps, but it is a joy to watch something become less broken.

But I have a problem, one I hope you can help me solve. Band-aids are often the simplest solution to a problem. As someone who loves simplicity, how can I advocate the additional time to get a better solution? Is it that extra work on my part makes it simpler for everyone else?

Let me know what you think below. There may be one of three autographed copies of Designing the Obvious in it for you. I’ll randomly select from the commenters on all of my Designing the Obvious posts once the series is complete.