Framing is part of the design

I recently gave a presentation to my design team about something I’ve come to believe is as important as the design work itself: how we frame it.

The premise was simple: how do we help an audience understand the problem, see the gap, and make the decision?

I’ve spent most of my career thinking about how to make good things. The craft of an interface, the quality of an experience, the details that make something feel considered instead of merely assembled. But the longer I’ve been a designer, and especially the longer I’ve led design teams, the more I’ve realized how much that work depends on our ability to explain it.

You can spend weeks understanding a problem, talking to customers, working through edge cases, collaborating with engineering, and arriving at something thoughtful. Then you walk into a room, open Figma, and start explaining the interface as if everyone else has been on the same journey. But you’re three weeks deep in the problem. They’re three minutes into it.

I think this is where a lot of good design work gets lost. Someone might disagree with the solution, but they might also be missing the context that would allow them to assess it. They don’t understand the problem the way you do. They might never have used the current experience. They don’t know which constraints shaped the solution, which parts are decisions, and which parts are still questions. And yet we sometimes expect the artifact to explain all of that for us.

An interface can show someone what we’re proposing. It rarely explains everything they need to understand about why.

Start where they are

One of the things I’ve been trying to teach my team is to diagnose the audience before opening Figma. Who are they? What do they own? How well do they understand the problem? How familiar are they with the experience today? And what do we actually need them to do next?

We sometimes treat context as a fixed thing. We make the deck, prepare the prototype, tell the story, and then bring roughly the same version into every room. But framing is relative. An engineer who has been working beside you for three weeks probably doesn’t need ten minutes explaining the problem. An executive might understand why the problem matters but have never used the experience you’re redesigning. Someone completely new to the work might need both.

This sounds obvious when you write it down, but I don’t think we practice it enough. We tend to start from where we are. We’ve spent so much time inside the problem that we forget what it feels like to encounter it for the first time.

I’ve found it useful to think about an audience across two dimensions: how well they understand the problem, and how well they know the experience as it exists today.

Those two dimensions create four different conversations. Someone who understands both probably needs very little setup; you can spend the time on the decision, tradeoffs, and open questions. Someone who understands the problem but hasn’t experienced the product may need to see how it works today before the proposed change makes sense. Someone who knows the product intimately but doesn’t understand why it needs to change needs the evidence. And someone who is new to both needs the whole story.

A person’s title won’t reliably tell you which conversation you’re having. A senior leader might know the experience in extraordinary detail. Someone who uses a tool every day might understand its problems better than you do. The point is to find out where their understanding actually is.

I like this matrix because it gives me a more useful question to ask before sharing work: where is this person starting, and what do they need to understand so we can make a decision together? It also forces me to recognize that more context isn’t necessarily better. At a certain point, additional information makes the important part harder to find.

Give them the story they need

Another framework I’ve found useful comes from Barbara Minto’s The Pyramid Principle: Situation, Complication, Question, Answer, or SCQA.

The Situation establishes shared context. The Complication introduces a change or tension that raises a Question. The Answer responds to that question. The pyramid organizes the supporting ideas beneath the main point. Minto allows different introductory orders, including leading with the answer; the question can be implicit.

For a medication request experience, the argument might be: people request medication renewals through a portal, but the flow asks them to distinguish between a refill and a renewal, terms they may not understand. How do we help them make the right request without asking them to learn our internal vocabulary? We could give them one entry point and route the request based on what they need.

When sharing that design, I generally want to state the recommendation before opening the file: “I recommend giving members one entry point for medication requests, so they don’t have to distinguish between a refill and a renewal.” Now people know what I’m proposing and what to look for when I show the experience. If they’re unfamiliar with how things work today, I can briefly establish that context before walking through the proposed change.

Of course, sometimes the work is still exploratory. I might be comparing approaches or testing an assumption without having a recommendation yet. In those conversations, I lead with the question we’re exploring, what the prototype is meant to help us learn, and what kind of input would be useful. I still want to give the conversation direction while being honest about how much is resolved.

This is where I connect SCQA to the audience map. The mapping is my application of Minto’s ideas to design reviews: it helps me decide where the explanation needs more attention.

Someone who understands both the problem and the experience probably needs only a brief reminder before we discuss the recommendation, reasoning, and tradeoffs. Someone who understands the problem but hasn’t used the product may need to see today’s experience. Someone who knows the product but hasn’t seen the reason for changing it needs the evidence and a clear explanation of what we’re trying to solve. And someone new to both needs enough context to connect the current experience, the problem, and the proposed response.

These are guides to emphasis. I’m deciding where their understanding needs more support, rather than assigning each audience a different fragment of the argument. The recommendation still needs to make sense as a whole.

There’s a temptation when we present design work to recreate our own journey of discovery. We started here, learned this, explored seventeen things, went down one path, discovered it didn’t work, talked to engineering, changed directions, and eventually arrived here. That journey mattered because it’s how we developed conviction. But everyone else doesn’t necessarily need to experience it in the same order.

Sometimes an abandoned direction is essential to understanding the recommendation. Sometimes it’s just something we spent a lot of time on and feel compelled to show. Being able to tell the difference is part of the work.

The habit I want my team to practice is answer first, scale the setup, group the support. That’s our default for sharing a recommendation, with room for judgment about what the audience needs. I want someone to leave understanding the argument well enough to question it, improve it, or explain it to someone else.

Know, Bet, Need

There’s another habit I’ve started using with my team: Know, Bet, Need. Before walking into a room, I want us to be able to articulate what we know, what we’re betting on, and what we need from the people in it.

Know is the evidence. What have we learned from research, data, customer conversations, or observing how the product works? There’s a difference between something we know and something we believe, and I want us to be able to say plainly where our confidence comes from.

Bet is what we believe but haven’t proven yet. I think naming this makes a designer more credible. There’s a tendency when presenting work to make everything sound resolved, as if uncertainty weakens the argument. But almost every meaningful product decision contains uncertainty. We might know that people struggle with a particular step without knowing whether our proposed change will solve it. Those are two different claims, and we should be able to separate them.

I’d rather say: this is what we observed, this is what we think will help, and this is how we intend to find out. That gives everyone something more useful to work with than confidence alone.

Need is what we need from the room. What decision needs to happen? What input would help? Who needs to own something? Are we asking people to evaluate a direction, resolve a constraint, or commit to building it? A conversation without a clear need can easily become a conversation about anything. And design feedback without a clear need has a tendency to become feedback on everything.

These three things give the conversation a useful foundation. People can examine the evidence, challenge the bet, and respond to the ask. They can participate in the thinking instead of trying to guess what kind of reaction we were hoping for.

The pixels don’t speak for themselves

There’s a related idea in Tom Greever’s Articulating Design Decisions that I wish I’d internalized earlier in my career: explaining the work is part of the craft.

I understand the appeal of believing that great design should speak for itself. There’s something satisfying about making an experience so clear that it needs very little explanation. But evaluating a proposed design inside an organization is different from using the finished thing. People are also evaluating the cost, the feasibility, the operational consequences, and whether it’s the right problem to work on at all.

Those are reasonable things to care about. An engineer asking about scope or an operations leader asking about staff time may be seeing something the design hasn’t accounted for yet. If I treat every question as a failure to appreciate the work, I lose the opportunity to make it better.

That means listening for the concern underneath the feedback before responding. It means understanding what the other person is responsible for, connecting decisions to shared goals, and being willing to reconsider a choice when their perspective changes what we know.

One way I put this into practice is to structure a response around a goal, a choice, and a question.

For example: We want fewer people to start the wrong request. One entry point lets us route the request for them. Does this address the confusion you’re hearing?

The goal establishes what we’re trying to achieve. The choice explains how the design is intended to help. And the question gives the other person a way to respond with what they know. Maybe the confusion happens somewhere else. Maybe the proposed routing creates another problem. Maybe they agree, and we now have a shared reason to move forward.

The question has to leave room for an actual answer. Otherwise we’re just asking someone to endorse a decision we’ve already made.

Design inside an organization depends on other people. They have to build it, fund it, operate it, support it, and sometimes explain it when we aren’t in the room. Writing down what was decided, why it was decided, and what remains uncertain helps that understanding survive beyond the conversation.

How these fit together

I use these tools at different moments in the same piece of work. Before sharing anything, the audience map helps me decide what context people need. Know, Bet, Need helps me separate the evidence from the assumptions and identify what I’m asking for. When I have a recommendation, SCQA helps me organize the argument behind it. And during the discussion, Goal, Choice, Question helps me explain a particular decision and invite someone else’s perspective.

For the medication request example, I might be presenting to someone who knows members are confused but hasn’t used the portal. That tells me to show the current experience briefly. If the evidence shows people struggle with the refill and renewal distinction, my bet might be that one entry point will help. What I need is input on how we could route those requests. I can then frame the recommendation and walk through the prototype. If someone questions why I removed the two options, I can connect that choice to the goal and ask what information their team would still need.

There’s a distinction between the questions here, too. In SCQA, the Question is the problem the recommendation answers: how can people make the right request without understanding our terminology? In Goal, Choice, Question, it’s something I ask the other person so they can contribute to the discussion. And the Need is what I’m asking the room to help resolve or move forward.

I don’t expect every review to include four frameworks, named out loud and presented in order. A quick conversation with an engineer might only require stating the bet and asking about a constraint. A review with people unfamiliar with the work might need the full setup. An early exploration might have a clear question without an answer yet. The tools help me prepare, but the conversation still requires judgment.

Designing the understanding

The more I think about all of this, the more familiar it feels. Designers spend an enormous amount of time considering how people encounter products. What do they understand first? What context do they need? Where might they become confused? What information should be revealed now, and what can wait?

Those same questions apply when we share our work. The person sitting across from us brings an existing understanding of the problem. We’re trying to help them see something they may not see yet, while remaining open to what they can help us see. The conversation has to support both.

I think that’s why framing belongs inside the craft of design. We’re already responsible for considering how something will be encountered and understood. That responsibility extends to the people whose participation makes the work possible.

This also becomes more apparent as you become more senior. Earlier in your career, someone else may do much of the framing for you. They explain the strategy, bring the right people together, and help resolve the questions around your work. As your responsibility grows, more of that becomes yours. People expect you to make sense of the ambiguity and help them move through it.

You still need taste. You still need to care about the details and understand the experience you’re making. But you also need to explain why a decision exists, distinguish what you know from what you believe, and understand what someone else needs before deciding what to tell them. All without burying them underneath the weeks or months of thinking it took you to get there.

It can be frustrating to feel like you’ve done the work and now have to explain it again. I understand that feeling. But the explanation is often where the work encounters something it hasn’t accounted for: another person’s knowledge, another constraint, another interpretation of what matters. That encounter can strengthen the idea, if we make room for it.

A thoughtful strategy that nobody can repeat has a hard time surviving after the meeting ends. A design decision whose reasoning nobody understands is easy to undo. Helping people understand the work gives them a way to carry it forward, and a basis for knowing when it needs to change.

So making something good includes helping other people understand it well enough to participate. To question it, improve it, and eventually help make it real.

Framing is part of the design.