Set the problem statement just right

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.


It’s difficult to come up with five distinct ideas. The right problem statement makes this easier. You want to make it clear, but not limiting.

More limiting: Fly from A to B as fast as possible.

A limiting problem statement
Fly from A to B by cannon, carrier pigeon, hot-air balloon, airplane, or arrow.

Less limiting: Get from A to B as fast as possible.

A less-limiting problem statement
Get from A to B: if we’re not limited to air, then by tunnel or train. If we’re not limited to moving an object, then … by telephone, telegraph, fax, internet, or satellite.

The right scope

Let’s examine a series of problem statements that are from projects that used Five Sketches™, one at a time.

  • Add a custom legend to the bottom of a mine plan, before it gets printed, so a mine planner can include custom details 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 the subject-matter expert spoke to the team about this for ten minutes during Step 1 of the Five Sketches™ design process.
  • 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.

Once the problem is understood, 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.