JM Family Design System
Stage 2 · Understand

Define

Name the problem clearly enough that the best options are easier to see.

A well-defined problem is half-solved. A poorly defined one makes every solution work harder than it should. Define is the work of naming the problem so clearly that the team can defend it in one sentence, and still disagree usefully about how to solve it.

It is also where you decide, before any design begins, what success looks like. Make that decision now and the team has a shared target when pressure rises later.

What you do

  • Reframe, do not summarize

    A good problem statement is a small invention. It names who the user is, what they need, and why current solutions miss. It is not a recap of everything you learned.

  • Write a point of view

    Use the form: "[User] needs to [verb] because [insight]." Read it aloud. If the sentence feels vague, keep refining it.

  • Agree on success up front

    What will be true if this works? Pick metrics that move when the user wins, not when the team ships.

  • Bound the scope honestly

    Decide what is in, what is out, and what can wait. Future iterations exist. You do not need to fit everything into v1.

What you produce

  • A defensible problem statement

    One sentence the team can refer to without re-reading the research deck.

  • Success metrics tied to outcomes

    Numbers that move when the user wins, not when the team ships.

  • A list of hypotheses worth testing

    Two to four bets you are making, each phrased so it could turn out to be wrong.

AI pressure-tests your framing.

The most useful thing AI can do at this stage is challenge your framing. Hand it your problem statement and ask: how would you reframe this from the user's perspective? What is the strongest case that the real problem is different? What would prove this wrong?

Avoid asking AI to write the brief for you. Use it as a second voice in the room so your framing gets sharper before the team builds around it.

Watch for

Patterns that can make the work look farther along than it is.

  • Solution disguised as a problem

    "Users need a dashboard" is a solution. "Users cannot answer how did we do last month without three tools" is a problem.

  • Multiple problems hiding in one sentence

    If the statement uses "and," you have at least two problems. Pick one to lead with; track the rest.

  • Success that is just a deliverable

    "Ship the new flow" is not success. "Reduce time-to-quote by 40%" might be.

  • Defining for the team, not the user

    A problem statement that explains how the team feels is a retro topic, not a brief.

What you carry into the next stage

A problem the team can defend in one sentence, a definition of success they can agree on now, and a short list of hypotheses sharp enough to be tested.

Related in the system