At the start of the Five Sketches™ design process, each member of the group has to fill the problem space with ideas. Ideas that are similar, different, standard, new, creative, strong, or weak. The goal: generate lots of distinct ideas.
More limiting: Fly from A to B as fast as possible.
Less limiting: Get from A to B as fast as possible.
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 needs 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 as a development task—”Replace the interface” is about the development work, not the user needs. But it was acceptable in this case 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 has saved us months of work.”
- Let citizens apply online for a child benefit online as simply as possible. In The paper form accommodates simple cases—the majority of applicants—as well as the edge cases that the majority don’t need. This initial statement was split into three:
- Decide whether to apply by learning about the program.
- Apply for a child benefit.
- Extend a child benefit for a young-adult child still in school.
Sometimes one technical function—such as a way to deliver information that lets people “learn about the program”—requires separate design solutions. The problem statement for “Decide whether to apply…” was further split, for its different audiences: a section on Eligibility in general, and a section on Tax Implications for high-income earners specifically.
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.
- Use the Five Sketches™ method to get quality designs, or skip to a specific step:
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
- Why five sketches? Why not three? It’s not just about the total number. There are individual benefits to sketching that also benefit the organisation.
- Sketching to communicate effectively. 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.