At the start of the Five Sketches™ design process, each participant in the group has to help fill the problem space with ideas—whether they are similar, different, standard, new, creative, strong, or weak. The goal: generate lots of distinct ideas.
It’s difficult to come up with five distinct ideas. The right problem statement makes this easier. You want to make the problem statement clear, but not limiting.
More limiting: Fly from A to B as fast as possible.
hot-air balloon, drone, airplane, or arrow.
Less limiting: Get from A to B as fast as possible.
tunnel or surface transport. If we’re not limited to
moving a physical object, there’s phone, telegraph,
internet, and satellite.
The right scope
Let’s examine a series of problem statements from real projects that used Five Sketches™.
- Add a custom legend to the bottom of a mine plan, before it gets printed, so a mine planner can identify custom details on the mine plan that help others read the plan correctly. This was a clear, concise problem statement that the participants understood. They knew what the legend’s “custom” information might be, because a subject-matter expert in mine-planning spoke to the team about this for ten minutes during Step 1 of the Five Sketches™ design process. The Product Manager also stopped in for a few minutes to review the business goals and strategy for the product that needed this custom-legend feature.
- Buy or renew a dog license online, so it’s easy for citizens to comply with the bylaw. This first draft was split in two, because a first-time license requires additional information about spaying or neutering. And for license renewals, we wanted to enable a returning citizen to locate their existing dog-license record while keeping their data private from others. The two problem statements do not assume or require two completely separate solutions. In fact, the second design outcome reused large portions of the first.
- Replace the interface of a task-scheduling system so users can see the schedule taking shape. The existing interface was a text-based, command-line interface, and the product manager wanted a graphical, drag-and-drop interface. This broad problem statement became five—one for each main function. It’s generally limiting to tightly couple a problem statement to a development task—”Replace the interface” is about the development work, not the user needs. In this case it was acceptable because the goal was to swap one interface for another without changing the system functions. One nice thing about this project: once the Five Sketches™ design process was complete—before any coding took place—the Development Manager said: “This week has saved us months of work. Months!”
- Let citizens apply online for a child benefit online as simply as possible. The existing paper form accommodated simple cases—the majority of applicants—as well as the edge cases that the majority didn’t need, adding complexity to the paper application form. Therefore, the initial problem statement was into three:
- Extend a child benefit for a young-adult child still in school.
- Decide whether to apply for the child benefit, by learning about the program.
- Apply for a child benefit.
In the fourth example, the problem statement “Decide whether to apply…” was split further, by target audience: a section on Child-Benefit Eligibility in general, and a section on Tax Implications for High-Income Earners specifically. This shows that a technical function—such as delivering information with which people can make a decision—sometimes requires separate problem statements, so they’re “just right” for sketching.
Confirm everyone’s understanding
Once your problem statement is defined, ask one of the participants to restate it in their own words. Make sure everyone’s understanding of the problem statement is the same. If not, refine the problem statement until its meaning is clear to everyone.
Once the problem is understood, and if the participants know how to sketch, you can send them on their way, to separately prepare five sketches, not fewer, for their upcoming Five Sketches™ session.
More…
- Generate quality solutions for software- and content design challenges, or skip to a specific step:
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | - Why 5 sketches? Why not 3? It’s not just about the total number. There are individual benefits to sketching that also benefit the organisation.
- How to sketch to share design ideas. This includes a ten-minute group exercise to learn how to communicate through sketches.
- Competing ideas at the finish line? Here’s how to pick a winner, by helping the team to make a decision that satisfies all participants.
- Five Sketches™ is informed by psychology to make it an effective, efficient, conflict-free method for non-designers who need to generate a good design solution.