These humbling experiences helped me learn to trust the process, even in the face of frustration or panic. It’s these experiences that give me the courage to follow the design process, even when it isn’t clear how to resolve the tension between conflicting design constraints.

In the face of an unknown, individuals and especially teams tend to turn to knowns. If needed, they’ll manufacture the known data, by deferring the choice to users. Here’s part of what Larry Constantin wrote about courage in software design, in a paper that advocates for user involvement at the right time:

Most damning and least recognized among the limitations of user-centered design is the way it subtly discourages courage. Courage is one of the central tenets of extreme programming and agile development methods. […] User-centered design makes it too easy for designers to abdicate responsibility in deference to user preference, user opinion, and user bias. In truth, it is hard to stick with something you know works when users are screwing up their faces at it. What if you are wrong? What if you are not as good a designer as you thought you were? It takes real courage and conviction to stand up for an innovative design in the face of users who complain that it is not what they expected or who want it to work just like some other software or who object to certain sorts of features as a matter of course. It takes responsible judgment to know when to listen to users and when to ignore them.

In the many design sessions I have facilitated, three times I’ve seen that lack of courage expressed by a participant. Each time, it sounded like a mix of panic and frustration:

The solution has been on the wall since the first round!

The design sessions I facilitate ask participants to saturate the design space with lots of ideas. They each bring five sketches—five substantially different ideas—and then, after sharing their ideas with the other participants, they rapidly iterate the first 15 or 20 sketches to develop even more. All this takes place before any analysis.

When the goal is to saturate the design space—to identify as many solutions as possible in a short time—there’s more to influence the design once the analysis begins. Inevitably, the design that the team decides on was not already on the wall. Motivated design participants quickly learn this, and—in most cases—become advocates of the process.

For most development teams, the Five Sketches™ process I introduce is a departure from the status quo, so it takes courage for their team members to take a stand, to say “I will use this process” for design problems that need it.

If you tell someone about a great idea, and they say “That’s a great idea,” it’s not a pattern.

If you tell someone a great idea, and they say “Yes, we do something like that too,” that’s a pattern.

 Exactly! That’s why I speak about Five Sketches™ at conferences and professional development sessions. And that’s why I post and write about everything I come across that’s similar to Five Sketches™.

Design Studio was the first undeniable indication that we’ve solved a problem that others in software development and web development are experiencing. That’s because the Design Studio method is very similar to Five Sketches™. Two completely separate teams, in different countries, came up with nearly the same solution to their respective design-process challenges. Design Studio was developed at Jewelry TV by Jeff White and Jim Ungar.

Here are some more methods and techniques that are similar to parts of Five Sketches­™.

• Low-fidelity generative design. There’s a huge benefit to exploring and evaluating a range of interaction concepts while involving both business and technology partners. This is, in effect, the divergence stage of generative design advocated by Bill Buxton, and done with low-fidelity. Adaptive Path does this with sketchboarding. Five Sketches™ does this by using mixed teams to separately sketch five ideas per participant, and then iterating from there.
• Parallel design. This is supported research and advocated in the book of guidelines from Usability.gov. To ensure parallel design, Desiree Sy at Autodesk uses interns to prototype 10 or more design solutions to a design problem.
• There’s much more that’s already been posted on this site. Use the Search box on this site to look for posts about generative design, design studio, creative hacks, Leah Buley, Bill Buxton, Scott Berkun, Jeff White, and Jim Ungar.

• Design awareness.
• Design literacy.
• Design thinking.

Buxton also mentions a fourth layer, design practice. He explains that design practice represents a fulltime job for highly trained professionals, and that it’s rare to find a developer who straddles both. (In my experience, small- and mid-sized companies may get by without a design practitioner, if their designs are constrained by the rules and standards of the operating system and hardware, and if their competitors do no better.)

Buxton thinks non-designers can easily learn about and appreciate the first three layers of design. On the third layer, design thinking, Buxton writes:

Cognitive science makes it clear that the strategies designers use in approaching problems or questions are different (not “better”) than those employed by those trained in engineering disciplines. Both strategies are complementary. Given the complexity of the problems that confront us, it seems to me that expanding our collective arsenal of techniques is something we could all benefit from.

This difference in problem-solving strategies is the ideation-judgement axis that I wrote about in Please exit your comfort zone. Learning to use these different strategies—at the right time in the design and development process—is what Five Sketches™ teaches to developers and other non-designers.

Many design participants believe they cannot draw. To be honest, I believe that about myself. People who feel they cannot draw tend to extend that belief to encompass design sketching, as well. However, I have learned to distinguish between drawing (below, left) and sketching a software design (below, right).

Software design does not require drawing, only sketching. From experience, I can tell you that sketching is easy once you realise that the goal is to produce only rough and low-fidelity ideas, not decorative and high-fidelity pictures.

Occasionally, I encounter a design participant who has trouble with sketching. I once had a participant who was so self-conscious of her sketching ability that she was paralyzed during the rapid iteration phase, when the design participants are quickly mashing up the sketches with borrowed and new ideas to produce additional sketches. I noticed that this participant was always busy—talking or wiping the board or replacing the snacks—but never sketching. This avoidance, and the underlying mental block, was an impediment to the whole team. Like all generative design processes, Five Sketches™ relies on its participants to saturate the design space with ideas. If a participant isn’t participating, it increases the project risk.

To pre-empt this mental block and to reduce the project risk, during Five Sketches™ training, I now introduce a quick speed-sketching exercise. Speed sketching is a race against the clock. With pen and paper ready, before each round, I give the participants five seconds to think, and then:

• 10 seconds to sketch a cell phone.
• 8 seconds to sketch a sandwich.
• 6 seconds to sketch an airplane.
• 4 seconds to sketch a ship.
• 2 seconds to sketch a house.

After each sketch, the participants look at the other sketches. I ask them to identify the details that make the sketched object recognisable. There isn’t time to draw a high-fidelity rendering, so the sketches are rough and have few details.

Interestingly, with few details the sketched objects are still clearly recognisable. Participants learn that detail and fidelity aren’t needed. By the last round of sketches—the “2 seconds to sketch a house” round—participants have seen that everyone’s ability to produce sketches is about equal, and they usually conclude: ”I sketch well enough for others to grasp my ideas.” Generative design requires lots of ideas—disposable ideas—not fancy drawings.

Jason Santa Maria says a similar thing in his Pretty Sketchy blog post, in which he declares that sketching is not about being a good artist; sketching is about being a good thinker.

The first part of my answer is: “Make sure you sketch, first.”

At the design stage, sketching, wire-framing, and prototyping are not equal. Sketching is useful at the divergent phase of design because it lets the design participants express and capture lots of different ideas quickly and anywhere that pen and paper will work. Nothing is as fast as running a pen across a sheet of paper to capture an idea—and then another, and another. And since sketching is intentionally rough, everyone can do it.

Responding to Œ the problem statement, first  saturate the design space with lots of ideas, and then Ž analyse and rapidly iterate them to  a design solution.

I also believe sketching is great for the convergent phase of design, but there are potential hurdles that design participants may encounter. It can be challenging to convey complex interaction, 3D manipulation, transitions, and multi-state or highly interactive GUI in sketches without learning a few additional techniques. This is unfortunate, because having to learn additional techniques reduce the near-universal accessibility of sketching.

The second part of my answer, therefore, is that “if you need to learn additional techniques to make sketching work, feel free to choose wireframes or prototyping as alternatives when there are compelling reasons to do so.”

I should point out that the three techniques—sketching, wireframing, and prototyping—are not mutually exclusive. Wireframes and paper prototypes can both be sketched—especially for simple or relatively static GUI designs.

There are no validity concerns with the use of low-fidelity sketches, as these readings show:

• Low-fidelity enables rapid and extensive exploration.
• There’s no difference between high- and low-fidelity models in usability testing.
• Designers can choose whichever medium and level of fidelity suits their practical needs and design goals.

After Œ informing and defining the problem  without judgement  and  generating and sketching lots of ideas  without judgment , it’s often a relief for the team to start Ž  analysing and judging  the potential solutions by taking into account the project’s business goals, development goals, and usability goals).

But what are the usability goals? How can a team quickly assess whether potential designs meet those usability goals? One easy answer is to provide the team with an project-appropriate checklist.

Make your own checklist. You can make your own or find one on the Internet. To make your own, start with a textbook that you’ve found helpful and inspiring. For me, that’s About Face by Alan Cooper. To this, I add things that my experience tells me will help the team—my “favourites” or my pet peeves. In this last category I might consult the Ribbon section of the Vista UX Guide, the User Interface section of the  iPhone human-interface guidelines, and so on.

[local /wp-content/uploads/2009/04/make-usability-checklists.wmv]

Buxton’s probably heard this objection a few times, because he addressed it at Mix09, last month in Nevada. He said:

I can hear your clients and your managers saying: “Well, Mr Buxton may have told you that you have to be able to do five different versions for every single question you’re asked—each one equally valid—but we can’t afford it because we’re already behind schedule. We don’t even have time to do one solution, and you’re telling me we have to do five?”

What are you going to say to them?

It’s a good question. Buxton also had an answer. “Doing multiples is critically important” because it’s how you saturate the design space with enough ideas to rapidly iterate to the best design solution. The challenge, says Buxton, is to balance ”doing multiples” with the budget, with dollars, time, and personnel.

It comes down to technique.

Sketching is a fast, inexpensive, and therefore disposable way to capture ideas. And five really is key. In my experience, when I asked design participants for two or three sketches, they each brought “two”—actually versions of the same sketch where one had an extra squiggle or mark on the page. This is not how you saturate a design space. It has to be at least five—hence the name, Five Sketches™. The sketches have to be fast. They have to be low fidelity. The sketches have to be disposable.

Sketching is the right tool. You also need the right team, working at the right time. The right team has an understanding of generative design and knows that there’s a time to sketch, a time to iterate and analyse design ideas, and a time to code or program. (A team of three or four design participants can learn and practice everything but the programming in a half day.) In my experience, design participants—developers, QA staff, marketing staff, support staff—can sketch and produce great software and web designs as effectively as a graphic designer or industrial designer can.

Again: it comes down to technique. And since sketching is cheap, you can’t afford not to design.

Divergence is the stage when the designer or design participants come up with ideas. Lots of ideas. Not just comfortable ones, but ideas that push at the edge of the envelope. Ideas without judgement.

Convergence is the stage when ideas are judged, rapidly iterated, assessed, and checked against the requirements.

In my experience, divergence is best done by sketching, with a pen on paper:

Sketching on paper with a wide-nib pen is best because this “technology” is familiar—it’s easy—and inexpensive. Everyone can have a pen and paper, so there’s no need to wait your turn. Sketching is fast, so designers have little invested in any one sketch. Modifying or iterating any one of the ideas is easier to accept. Most importantly, for inexpert sketchers, the sketching process intrinsically discourages high-fidelity work and the wide-nib pen discourages sketching the fine detail that detracts design participants from getting the ideas out, fast.

Software that’s intended to help people “sketch” detracts from a good result. The software often lets users build prototypes with a great level of interaction detail. The problem with this: attention to detail is a distraction at the divergence stage. When filling the design space with ideas, it’s sufficient merely to evoke the idea and share it. Ambiguity actually helps the team see more than one idea in the same sketch; each interpretation of the idea can be iterated. Software that’s not intended to help people to “sketch” slows them down at the divergence stage—just when we need ideas to flow quickly. Divergence is about filling the design space with lots disposable ideas.

Read my blog post about why ideas are disposable.

Here’s why ideas are disposable:

1. Sketching lets you capture lots of ideas, quickly and inexpensively.
2. The more ideas you try for, the sooner you learn that it’s easy to come up with five or more ideas.
3. The easier it gets to have lots of ideas, the sooner you realise the value of any one idea is minimal.

Minimal value = disposable.

This is one of the keys to the success of Five Sketches™. Once you learn how easy ideas are to have, you can saturate the design space, iterate the design, and produce excellent design outcomes at will.

As Bowman left Google, he pointed out the pro-engineering bias in its approach to problem solving—including problems of design. Two of several examples he gives:

[…] a team at Google couldn’t decide between two blues, so they’re testing 41 shades between each blue to see which one performs better. I had a recent debate over whether a border should be 3, 4 or 5 pixels wide, and was asked to prove my case. […]

Bowman would like to see more weight put on design principles. His blog includes a link to Wikipedia’s article on design elements and principles, which lists:

I don’t think design principles are beyond an engineer. I do think engineers need to be taught how—and when—to think about these details.

As we discovered during the development of Five Sketches™, this kind of detail is often outside the comfort zone of an engineer. However, I can affirm that even engineers who initially produce work with little design insight or creativity have managed to astonish me with amazing design results within a year. And that’s after only occasional participation in Five Sketches™ design sessions.

So, yes, engineers can learn to participate in design, with success and predictability, though I would caution that Five Sketches™ works for engineers because it was developed for and with them, to meet their needs.

At Google, to bring about such a cultural change, Bowman would have needed the unwavering support of at least one senior executive. Even then, as Bowman himself acknowledged in his goodbye message, a company as large as Google does not change direction easily.

If you liked this post, read about how a company’s use of social media influences its corporate culture.