Tag: process

Posted on

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.
Some key design ideas, conveyed to me on a napkin sketch in a Vancouver bar.

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.

Posted on

Failure, then sketching success

Developing Five Sketches™ came with its share of challenges. Fortunately, all obstacles were overcome. Some of those obstacles were even on the official Ways To Fail list in Seth Godin’s book, The Big Moo.

I’m glad I didn’t have to face them all:

  • Keep swimmingKeep secrets.
  • Set aggressive deadlines for others to get buy in—then change them when they aren’t met.
  • Be certain you’re right and ignore those who disagree with you.
  • Resist testing your theories.
  • Focus more on what people think and less on whether your idea is as good as it could be.
  • Assume that a critical mass must embrace your idea for it to work.
  • Choose an idea where the preceding point is a requirement.
  • Assume that people who don’t instantly get your idea are bullheaded, shortsighted, or even stupid.
  • Don’t bother to dramatically increase the quality of your presentation style.
  • Insist that you’ve got to go straight to the president of the organisation to get something done.
  • Always go for the big win.

Of course this is only funny in retrospect, now that I can see my way through any design challenge. Swimmingly.

Posted on

Rigid UCD methodology fails?

I received an e-mail from someone at the 2008 IA Summit about Jared Spool’s declaration that UCD is dead:

——Forwarded message——
From: P
Date: Sun 13/04/2008, 2:54 PM

Hi Jerome,

I’m at the iA Summit in Miami right now, and hearing about all of the things that are going on makes me think of you. One of the interesting sessions was Jared Spool’s keynote speech. He conducted research into what makes certain companies better able to produce effective designs. He used this model to talk about the various approaches departments do to facilitate design:

Things that facilitate design

He said all design involves a process, whether it’s been formalized or not. Interesting, though not surprising: companies that have dogmatic UCD leadership or use a rigid UCD methodology are unlikely to create anything innovative. To innovate, you want to apply techniques in sometimes surprising ways to solve problems that they were not intended for (those are the “tricks”.)

OK, I’m going back out in the warm (hot!) weather.

– P

Of course, the lack of process doesn’t guarantee innovation, either, nor does it guarantee you’ll be able to repeat your (accidental) successes. I believe a successful design process must involve some form of generative design—as Five Sketches™ does—that’s based on knowledge of user condition. I also beleive that, once you’ve internalised those two things, you can use almost any form of facilitation to design good products.

Posted on

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.

The Assist Sketch Understanding System (ASUS) design environment: a computer interprets a sketch and then simulates a cart rolling down a hill.