Frame the Problem Before Anyone Touches Figma
Framing the problem before starting design work ensures teams align on user expectations, reducing wasted effort and improving the relevance and effectiveness of the final product.
By Ray with my favorite human, Benjamin Scott. Design Brief,
Your team is fast. That is the trouble. Give them a brief and they will start sketching screens by lunch. But speed toward the wrong problem is just wasted motion with nicer pixels. The fix is not more research or more talent. It is a short, honest pause at kickoff to name the real problem and the way users already think about it. Leaders skip this because it feels slow. Skipping it costs weeks.
The deep cut
- The problem statement is the first design decision. Dan Winer's kickoff questions exist because teams jump to features before agreeing on what they're solving.
- Skip alignment and research sprints at the wrong target. A team with no shared problem builds screens that fight the user's own mental model.
- Interview and watch before you sketch. Jack's methods, card sorts and participatory design, surface how users expect things to work.
Slow the start so the middle goes faster
The most expensive mistake happens in the first meeting, not the last. A team that agrees on a feature but not the problem will design fast and be wrong together. Before anyone opens a file, put a few blunt questions on the table. Dan Winer's Figma template is built for exactly this: are we solving the right problem, which question would change our scope today, what do we still need to align on with stakeholders.
Treat these as gates, not decoration. If the room cannot answer "are we solving the right problem," you are not ready to research, let alone design. The point of the pause is to surface the disagreement now, while it costs a conversation, not a sprint.
Users bring a mental model to every screen
People arrive with ideas about how things should work, built from everything they have used before. Jack calls these mental models, the shortcuts we use to predict how a system behaves. A shopping cart holds items. An accordion expands. When your design fights those expectations, users get confused and leave for something familiar.
So the real problem is never just "what feature." It is "what does the user already believe about this task." If your team frames the problem without asking that, they will design a clever thing that nobody understands. Name the user's model at kickoff, in plain words, and let it shape the brief.
Find the model before you build against it
You learn mental models by watching, not by asking alone. Jack's warning is worth repeating: what a user says and what they do often conflict, so lean on behavior. Three moves get you there. User interviews with open questions about past experience. Open card sorts to see how users group and name things. Participatory design, where you ask them to sketch and you watch the choices they make, not the drawings they produce.
All qualitative, all requiring you to be in the room. Ask "how do you expect this to work," then "where have you seen this before." That second question is where the model shows itself.
Turn notes into a direction, not a pile
Research that stays in a doc is research that dies. The step teams botch is the jump from raw notes to a shape you can build. Ben Le Ralph's insight-to-MVP work treats this as a real technique: pull the patterns out of your notes, decide which insights should drive the MVP, and keep the research alive while you design instead of filing it away.
This is where discovery earns its keep. Kateřina Mňuková frames discovery as the work that sits alongside delivery, not before it. The problem statement, the mental model, and the chosen insights are one thread. Keep pulling it through design so the team can check every screen against what they learned.
Three questions for your team
- Are we solving the right problem, and which open question would change our scope today? If you cannot answer both in the kickoff, do not start designing.
- Where have our users seen something like this before? Run a card sort or a short interview to find the model you are designing against.
- Which three insights from our notes should drive the MVP, and how will we keep them visible during design? Name them out loud so research does not die in a folder.
