From napkin to Five Sketches™

In 2007, a flash of insight hit me, which led to the development of the Five Sketches™ method for small groups who need to design usable software. Looking back, it was an interesting journey.

The setting. I was working on a two-person usability team faced with six major software- and web products to support. We were empowered to do usability, but not design. At the time, the team was in the early stages of Nielsen’s Corporate Usability Maturity model. Design, it was declared, would be the responsibility of the developers, not the usability team. I was faced with this challenge:

How to get usable products
from software- and web developers
by using a method that is
both reliable and repeatable.

The first attempt. I introduced each development team to the usability basics: user personas, requirements, paper prototyping, heuristics, and standards. Some developers went for usability training. In hindsight, it’s easy to see that none of this could work without a formal design process in place.

The second attempt. I continued to read, to listen, and to ask others for ideas. The answer came as separate pieces, from different sources. For several months, I was fumbling in the metaphorical dark, having no idea that the answer was within reach. Then, after a Microsoft product launch on Thursday, 18 October, 2007, the light went on. While sitting on a bar stool, the event’s guest speaker, GK Vanpatter, mapped out an idea for me on a cocktail napkin:

  1. Design requires three steps.
  2. Not everyone is comfortable with each of those steps.
  3. You have to help them.

The quadrants are the conative preferences or preferred problem-solving styles.

I recognised that I already had an answer to step 3, because I’d heard Bill Buxton speak at the 2007 UPA conference, four months earlier. I could help developers be comfortable designing by asking them to sketch.

It was more easily said than done. Everyone on that first team showed dedication and courage. We had help from a Vancouver-based process expert who skilfully debriefed each of us and then served us a summary of remaining problems to iron out. And, when we were done, we had the beginnings of an ideation-and-design method.

Since then, it’s been refined with additional teams of design participants, and it will be refined further—perhaps changed significantly to suit changing circumstances. But that’s the story of the first year.

A sketch must be disposible

The strength of sketching is that it’s a fast way to capture ideas.

Since a low-fidelity sketch is fast—pen on paper, as shown—it’s also low cost. And low cost means it’s relatively disposable if it turns out you can’t use that idea.

If you don’t like my first 5 ideas, that’s OK. I can have more ideas, easily and at low cost. And so can you.

A variation on this theme: iteration is also painless. With relatively little invested in a sketch, modifying an idea costs marginally more.

The payoff is that you can quickly saturate the problem space with ideas, before you analyse them. This is a key part of why Five Sketches™ works so well for development teams who are in a hurry to start programming.

It’s important to keep sketches cheap. Here’s a video of a cool sketching tool that, if used as a design aid, would greatly increase the project risk. That’s because this cool tool is expensive to install, expensive to learn (it requires training) and expensive to use (it allows only 1 user at a time). All this will reduce the number of sketches in the problem space—and it’s risky to design without considering all options.

Thanks to Karen for finding and sharing this cool video.