Simplicity Rules

If you want to make a simple website, or have a simple product, you need to become well-versed in letting the good in and keeping the bad out. You can’t do everything and you can’t have every feature someone could possibly want.

You are a curator, and Jason Fried has a great talk (15 minute video) about what a curator does:

“Think of yourself as a curator. You want to be a curator. You have to decide what comes in and what goes out. Curator’s job is to say no. Curator takes an entire universe of options to decide whether or not something makes it into a museum.”

The hard part, I think, is how to decide what is essential and what is not. When I need help with that, I turn to a couple of the concepts from Designing the Obvious:

• The Unnecessary Test
• 60 Second Deadlines

How do you decide what belongs in your museum?

There’s a hidden radio concept design that’s been making the rounds. My friend Nathan sent it my way and said it reminded him of the unopenable mint container.

The radio’s volume is controlled by pulling up the lid, showing more speaker. It is tuned by twisting the entire lid. Once you know this, it’s wonderfully simple. Do you think it would be obvious to the first time user? Does that matter?

I hate doing the same stuff over and over. Since I’m a technical guy, I often create ways to make myself more efficient. Outside of work, this looks fairly mundane: stuff like buying only one type of sock, so I never have to search for a pair.

Michael Lopp writes about the geek phenomenon of being efficient in Saving Seconds. It begins as a rant against the mouse, but really gets somewhere when he writes about creating a new email message:

“There are two types of people. The ones who waited for me to say Go to compose a new mail and the ones who read ‘compose a new mail message’ and pressed the three keys that are necessary, from anywhere in the OS, to fire up a new compose window.”

I think Web people bring this desire to be efficient into our work, mostly for the better. Finding and eliminating repetition is an excellent way to streamline your product. Why make a user click twice if once will do? (Lopp might also say, why make a user click at all?)

Of course, everything in moderation. One can certainly be overcome when constantly striving to be most efficient:

Paying attention to productivity is a slippery slope. The system efficiency addiction associated with saving time can become so compelling that your process begins to control more of your time than your product.

Sound familiar to anyone?

There were some great comments on the unopenable mint container post. I wanted to share a few of them.

Most people agreed that once someone learns the trick, the container is simple. Brent Logan downplayed the effort needed to learn how to use the mint tin, then came up with some great additional reasons why the time spent learning is worth it:

I’d say opening this mint container IS simple, because once you know how to do it (and it can be documented in just two simple pictures), you can open it:

• one handed
• without looking
• with ease

Justin Thiele liked the mint tin, but wouldn’t call it simple:

What if Microsoft Word decided on a new way to copy text? No more Command C (Ctrl C for you PCs). Instead copy would be F1. F1 is simpler, only requires pressing one button, no keyboard dexterity required, and much easier to say to somebody. But now the process of remembering that Microsoft Word uses F1 and every other program uses Command C, becomes more involved. If other programs begin to take these same liberties then complexity abounds.

It sounds like Justin is worried about consistency, which I think plays a large part in simplicity. Certainly being consistent within a context (such as your own website) is important. But there’s also consistency between contexts, such as your website and my website. If you underline links and I underline everything except links, one of us will probably be confusing people. And if there are enough people making changes like this, we may all begin to confuse people.

A few weeks ago I bought some mints at Powell’s bookstore before a meeting. I didn’t want my breath to stink. As I was walking to the appointment, I struggled to get at the mints. It turned out this container required me to read the directions.

See the unopenable mint container in action in this video:

Since I discovered the secret, I’ve been pretty taken with the mint container’s simplicity. Still, I think back to my struggle in downtown Portland. It was not intuitive to open that container.

The fourth law of simplicity states:

“Knowledge makes everything simpler.”

What do you think? Does needing to read the directions eliminate the chance for it to be simple?

I enjoyed writing the series of posts about Designing the Obvious, the guide to creating sites and applications that keep both developer and user sane.

My favorite part was reading what others thought about it in the comments. Three were randomly chosen to receive autographed copies: Aaron Hockley, Bram Pitoyo, and David Frey. I hope we get to hear more about what they think when they read the entire book.

Thanks also to the author Robert Hoekman, Jr., who supplied the books, and agreed to answer the following questions about his work. If you’re still itching for more Hoekman, he has a new book, Designing the Moment, that is full of examples of his concepts put to use.

How do you determine what is essential and what is nice-to-have?

As I touched on in Chapter 2, I take an activity-centered approach to design, which is to say that instead of focusing on a narrow range of audience types, for most projects I focus on the activity an application is meant to support. In doing this, I study the essential elements of the activity, document them, and then work to justify every item on the list.

So, as I study an activity, I create what I call an “Activity Grid”, which is basically a 3-level outline you can create in any word processing application or outlining tool (such as OmniOutliner). At the top of this document, I write a description of the activity the application will support, then I break the activity down into outline form. The first level is a simple list of tasks, which could be something like “Find photographs” in a photo-sharing application. Tasks then break down into actions, which are itemized accounts of the steps you might take to find photos, such as “Search by member” or “Search by subject”. Finally, these actions break down into operations — the lowest level of detail. Operations can be things like “Enter a search term” followed by “Click the Search button”.

When I start studying an activity, I identify the major tasks — the ones most essential for completing the specified activity. Once I have that list, I detail the actions that comprise each task. From there, I can detail exactly what operations must occur for the actions to be completed. By the time I flesh out the Operations level of the activity grid, I have a fairly detailed set of design instructions. For example, the “Enter a search term” operation tells me I need an input field in the interface, and that there will be a search feature.

Once I finish this list, I start my design work. But instead of setting the activity grid in stone, I review it throughout the project, continually re-justifying everything that made the cut to see if anything is missing, can be stripped out, or needs revision.

With all this in mind, there are many ways to determine what’s essential and what needs to hit the cutting room floor. For example, Joshua Porter’s book on social web design offers a very different approach where you identify the objects needed to complete an activity and then devise your feature list out of that list. I think it’s a smart approach and am planning to try it out soon.

You rely on use cases in your work. How to you maintain a balance so your process can simplify things instead of make things more complicated?

The use cases I write are a little different than the typical “user story” you might see in a lot of development processes. First, they’re very detailed. Instead of a single line that describes only the action the user will take, I describe each step of each action. Second, these use cases are very much an extension of the activity grid. So, I design all the screens and screen states I need to fulfill the activity grid, and then I stick them all into this Powerpoint/Keynote template I created and write the use cases in a sidebar, right alongside each wireframe. I call this a Design Description Document (DDD) — in fact, you can grab the template from my site.

This can definitely sound like a complicated process, but depending on the activity, an activity grid can be created in a matter of hours in a lot of cases, and the DDD can be done just as quickly. Instead of a long, dry technical specification, I use this DDD, which can be created and updated in extremely little time, and does a more effective job of communicating to stakeholders and developers exactly how everything should work so they can build it all out.

I’ve been using this set of solutions for a while now, and it’s proven to be very efficient for me, but I’m always looking for ways to simplify the process and get the right messages across to clients, so I could just as easily change it all tomorrow.

The real key is to be flexible. Don’t lock yourself into anything, because there’s always an improvement to be made and you don’t want to miss it by getting too focused on one way of doing things.

Do you find making your personal workflow simpler makes your products simpler?

Oh, definitely. The more I simplify my own process, the more I’m able to quickly identify areas of a design that need to be created or improved, and the more readily I can do that, the simpler the outcome. For example, by using an activity grid and a DDD, I can determine what needs to be designed and document every detail of it very quickly, which enables me to spot trouble areas or gaps in my thinking so I can revise the designs.

How do you avoid the curse of knowledge and think like a user?

Great question — and the answer is actually a little ironic.

When it comes to designing usable and enjoyable software experiences, the principles of design are simply restatements of human behavioral patterns and psychology. For example, we know from observing people use software that they tend to blame themselves for mistakes when error messages come popping up time after time, and they can end up feeling dumb, as though they’re simply incapable of understanding how to do something correctly. We certainly don’t want our users feeling dumb as a result of using our products, so all you do is restate the problem as a principle. Once you know that users blame themselves for mistakes, even when it’s not really their fault, the design principle becomes, “Prevent errors, and handle those that cannot be prevented as gracefully as possible.”

Because the role of design is to support human behavior and because the principles behind good design do exactly that, there is no “curse of knowledge”. The more you know about human behavior, the better you can design to support it — to work within those constraints.

Why did you write Designing the Moment?

I wanted to pick up where Designing the Obvious left off. The first book was about core tenets — the high-level things that are simply essential to good web application design. But beyond those principles, there are a whole lot of very specific problems that come up when you’re shoulder-deep in the details of a design, and I wanted to talk about the principles and practices that address those problems. The best way to do this was to talk about them in context — to describe specific instances where I was faced with a common (or uncommon) problem and then walk through the principles and such that I applied to solve them. So, Designing the Moment is a collection of stories from real projects where I talk about the design problem, the steps I took to start and improve the design, and the concepts I used to make each decision.

The really fun part was that I got to tell all these stories about projects I’ve actually worked on and how I got through them. Of course, that’s also the really scary part. Designing the Moment is an educational tool, sure, but on a personal level, it’s also sort of a journal of these little bits of designs I’ve done over the past year and a half or so. It never really occurred to me while writing it, but once it was released, I had this realization that I’d just put all this work into print. It’s out there to be judged by anyone who picks it up. That’s a scary idea! I’m glad I didn’t have this realization while I was writing it, else I might have panicked and scrapped the whole book.

Too late now!

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.

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

If the term “mental model” is off-putting to you, I understand. It sounds starchy and academic. It also is a great name for what it is. Just like a model train can help you understand what the real trains look like, mental models provide a way to understand how users think. Mental models help to avoid thinking like a technician.

The book describes it this way:

“A mental model is what we believe to be true… It has to help us understand how to use a computer and understand what it is, but not necessarily what it really does.”

There is an example from the book that is so good, you may be buying the mental model yourself.

The trash can or recycle bin is where we put files we don’t want anymore. When we’re absolutely sure we won’t need the files, we empty the trash. In neither case is the computer actually destroying the file.

There’s an even better mental model hidden in the above example. Can you find it? Files! This model is so strong that most programmers don’t even have to acknowledge that files are just a way to disguise the details of storing data.

When a programmer doesn’t share the user’s mental model, it’s called an implementation model:

“An implementation model is something that has been designed, usually by not being ‘designed’ at all, to reflect the underlying details of the system.”

Designing the Obvious says to look for implementation models in our applications and find ways to replace them with mental models–the stuff that makes sense to users.

As a technician, I’m often thinking in the wrong direction, as Peter Merholz described in The Experience is the Product:

If you can pretend to be a user, you’ll have a leg up on creating something really easy to use. If you are a user, even better. Otherwise, you need to grab a user or two and talk to them.

Find the places where you’re “removing sectors from the hard drive index” and change it to “dragging icons into trash cans.”

Got any horror stories of implementation models beating out mental models? Dare you share any of your own mistakes? I’d love to hear about it below. As a special treat for sharing, you could get an autographed copy of Designing the Obvious. I’ll randomly select three commenters when I finish the series.