The Grandmother Test

View blog reactions Written on April 3, 2007 by Chris Heald

In the past few months, I’ve been heavily studying web development “best practices”. Semantically-valid content, separation of content from presentation, RESTful design, and graceful degradation on in the absence of certain technologies - all of that, and more.

My buddy Jon and I have been working on a project on the side, and I’ve learned a lot about “doing things the right way” in the process (unfortunately, this also usually means spending a lot of time fixing things that are done the wrong way). Jon works in marketing, and has a great eye for design, but doesn’t really have any grasp about how things work “behind the scenes”. I work in development, and have a great grasp of how to make the magic happen, but I think like a programmer. Jon’s inexperience with the specifics of application design, and my experience with those specifics are both strengths and weaknesses, but they compliment each other wonderfully.

One thing I’ve learned over the years is that programmers think differently from other people. There’s something about learning to program that changes your thought processes, assumptions, and expectations. Unfortunately, this tends to create a divide between the programmer and the end user. Programmers, left to design without outside input, tend to create applications that make logical sense, but which are not intuitive or self-explanatory to people without a programming background. This isn’t a problem when you’re writing tools for programmers, but if you’re trying to develop an application for the average internet user, it isn’t going to cut it.

An example: how many of you have put together a submission form and left the submission button reading “Submit”? That makes perfect sense to me. I know what “Submit” means. I know that when I click that button, the web browser will construct a POST request and post it to the web server, which will hand the request off to an application handler that will break down the incoming data and do validation and a database insert with it, then construct a response that will be returned to the user. Joe User, though, doesn’t think about that. He’s thinking “I want to add Jane to my address book.” Shouldn’t, then, the button read “Add to address book” or “Save changes” or similar?

I’ve seen this outlined very sharply as I work with a very smart non-programmer to design an application - he just thinks differently than I do. When we design a page, I’m immediately thinking about “ok, once I have this data, how am I going to make it do the right things?” Jon is immediately thinking about “ok, when I pull this page up in the browser, how am I going to use it?” We know this difference exists, and so, we have developed a very simple check that dictates the ultimate flow of our design: Could my grandmother use this?

Every time we are struggling with a design element, we ask that question. Every time we ask the user for input or interaction, we ask that question. Every menu, every form, every page. Could my grandmother use this?

Programmers deal with design questions all the time. Is this self-explanatory with no further documentation? Is it too complex? Is it too vague? The problem is, we often deal with them in the context of our own knowledge and experiences. The vim text editor is a classic example of this. It has a reputation for being hard to use, unfriendly to learn, and arcane in its design. It is an editor written by programmers for programmers. If you think like a programmer and you learn the basics, vim becomes a phenomenally powerful tool. It allows the programmer to edit documents, navigate a file tree, replace things, and perform various other tasks with blinding speed. This is a very good thing! However, vim isn’t for everyone. You wouldn’t recommend that your grandmother use it to compose an email to her friends to schedule their next bridge game, are you?

To a programmer, “is it too complex?” is rarely answered with a “yes”. “Is it too vague?” is often answered with “of course not, the source code is right there!” We can’t see the forest for the trees, and our users often pay the price. We need to expand our question: no longer should we ask “is it too complex?”; the question we need to be asking is “is this too complex for my grandmother? If I sat her down in front of my product and walked off, could she use it?”

If you’re writing an application that is designed for consumption by the general public, this question absolutely must be adopted as a central design philosophy. When you do it right, the result is a product that is not only easy to use, but beautiful in its simplicity (no matter how complex it truly is) and attractive to everyone that uses it. There is something compelling about a tool that “just works”. YouTube. Blogger. Google. Flickr. They all do it right - they make the exceedingly complex exceedingly simple to use. It makes you want to push buttons. It makes you want to do things. It makes you want to use that tool, just because the tool itself is fun to use.

So, the next time you’re designing a process or interface, ask yourself: “Could my grandmother use this?”

You might be surprised at what you find.

Posted in Software Development, Javascript/AJAX, Design, CSS