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.

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

The simplest tools are the ones that don’t make you worry about breaking it. I once owned a shovel that routinely came out of its handle. Even on its good days it was hard to use because I was always worrying that I was going to lose the scoop.

The same is true on the Web. Designing the Obvious says to create forgiving software:

“Applications should allow users to play around and see what they can do without serious consequences.”

In desktop programs, we have Ctrl-Z (or Cmd-Z) to undo. I love undo. Everybody loves undo.

The Web doesn’t have much undo. Even worse, we’re often warned that what we’re about to do will be lost forever! How scary. The book gives the example of how GMail showed that we could make an undo.

“What Google did was brilliant, but not because implementing an undo feature was an original idea. It was brilliant because no one else was doing it on the Web and it’s the right thing to do… Any application that allows users to perform what are normally irreversible actions should include an undo feature.”

Boy, if undo was widespread, that would take care of lots of errors on the Web. There’s a whole chapter on handling errors and, even better, preventing errors.

Another method of forgiving software is creating good defaults and remembering what I chose last time. One of my pet peeves is having to go through the same series of steps over and over. It seems like that’s what makes computers great! Do the boring tasks for me.

What stuff do you see all the time on the Web that you wish would go away? Tell me below and maybe I can give you an autographed copy of Designing the Obvious. I’ll randomly select three commenters when I finish the 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.

I often find myself overwhelmed by the daunting task of completing a project, or fixing errors with an existing project. There’s so much to do that it feels useless to do anything.

Toyota has the answer.

Kaizen is a Japanese term meaning continuous improvement. It is not about big changes, giants leaps forward. Kaizen is small changes, which over time compound.

Toyota uses the idea of kaizen to design and produce quality automobiles. Though the roots of kaizen are in manufacturing, it’s well-suited for work on the web, where many small changes can be made quickly.

“For every interaction I spell out with a use case, I go back over it several times, each time trying to find a way to make it smoother, faster, easier–more obvious. It doesn’t matter whether the use case ends up changing at all. What matters is that time is spent trying to improve it.”

Many of the ideas in Designing the Obvious are about identifying simple, easy tweaks to improve your project. From trimming features to giving users the right information when they need it, a little kaizen makes a big difference, eventually.

What’s that saying about journeys and first steps? Overcoming hurdles that seem insurmountable can be done by finding one tiny way to improve, doing that, then finding another. I’ve found even the smallest changes have had tremendous impact, especially with how I feel about what is achievable.

Are you practicing kaizen, with or without the term? Or, do you think changes are best made in broader strokes? I’d like to hear about it. If you leave a note below in the comments, you might even get an autographed copy of Designing the Obvious. At the end of this series, I’ll randomly select three commenters and ship each a book.

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

Users like features, or at least that’s what they tell us. Users can also be confused or turned off by options. It’s the paradox of choice.

Designing the Obvious says to build only what is absolutely necessary and lose the nice-to-have features. They’re extra cruft and not essential.

“Simplicity makes the point clear. It lets messages stand out. It offers communication that cuts through the noise.”

It’s easy to identify nice-to-have features by the way they’re introduced:
“You know what would be cool,” “here’s something we could do,” and “it wouldn’t be too hard to do this.”

How many of us have heard these in project meetings? Sure, innovation can also come from these statements, but leave it for the brainstorming sessions. Far too often these are used after the project is midway. Since the ideas often are cool, it’s easy to latch onto those features.

The book gives some guidance on how to find and fix an application filled with nice-to-haves.

Unnecessary Test

“The focus should not be on features, the focus should be on focus… Every feature should support the single activity the application is designed to support.”

Limiting feature creep means for each new feature we question whether the feature is necessary. We’re often biased and can’t be objective. The book recommends answering these questions (or, if you’re brave, have someone else answer them):

1. What is the activity my application is meant to support?
2. What would an application that performs this core activity look like?
3. How long would it take to rebuild my application to do that?

The author is half joking with the last item, though I think it’s a worthwhile thing to consider. Try to forget the baggage of previous versions (or how someone else’s application does something similar) and invision the basic functionality of what you’re building.

But beware actually tearing down walls:

“I’m not suggesting you start ripping functionality out of an existing application. Doing this could have the rather negative side effect of making some of your users extremely upset.. I’m only suggesting you learn from hat you’ve already done so you can create more focused applications in the future.”

Three Rs

Designing the Obvious provides three focal points to help you avoid nice-to-have features.

• Requirements – Always be aware of what is necessary for your project
• Reduction – Like the Laws of Simplicity state, remove those unnecessary features.
• Regularity – Make sure everything seems like it belongs. Strive for consistency.

These are a few ways of avoiding those nice-to-have features, which may be cool, but are also unnecessary. What phrases like “that would be nice to have” get your blood boiling? How do you handle what Designing the Obvious also calls “featuritis?”

Answer below in the comments. At the end of this series, I’ll randomly select three commenters and send each an autographed copy of Designing the Obvious.

If I were to write a book, I’d want it to be exactly like Designing the Obvious. Robert Hoekman, Jr., has written an excellent guide to creating sites and applications that keep both developer and user sane.

This book is so good, I’d like to give you an autographed copy. Since I only have three to give, I’ll draw random names from those who comment on this post and the upcoming posts about Designing the Obvious.

Over the next several days, I’ll be writing a series about some of my favorite simplicity lessons from the book:

• Nice-to-have Features Not So Kind
• Kaizen
• Create Forgiveness
• Get Mental (Models)
• Band-Aids Only Hide Boo-boos
• 60 second Deadlines

If you are impatient, or want to experience the full punch packed into Designing the Obvious, you can buy the book at Amazon.