Framing: What Are We Solving?

"Simplicity is about subtracting the obvious and adding the meaningful."

John Maeda

As we shift from the creative 'what' of Creative Theory in Design to the strategic 'why', we start where every design project begins: the brief. Sometimes it's a 40-slide deck from a strategy partner. Sometimes it's a one-sentence email from a small business owner. Either way, your job as a creative stays the same. Take the request and turn it into something actionable.

Deciphering the Brief

At its core, a brief should answer three things: what you are creating, who it's for, and when it's due. Many times briefs do not answer even those questions. Those that do can often hide flawed thinking. If you act too quickly, you risk solving the wrong problem.

That's why your first step is not action. It's interrogation. Look for assumptions, contradictions, and missing context. These are blind spots, the weak points in the brief that can mislead the work before it even begins. Your job is to expose them and decide whether they can be eliminated. Clarity only comes after you confront what the brief leaves unsaid.

Blind spots are not failure; they are a natural part of defining human problems. Every brief is incomplete.

Assumptions

Start with assumptions because they are the easiest to catch, and often the most dangerous. An assumption presents itself as a fact without ever earning it. Ask yourself: "Is this supported by data, or is it merely assumed to be true?"

Even when we have data to reference, it should not be considered "safe". You'll need to assess whether it's reliable, but we'll tackle that in the future chapter, "Proof, Not Opinions". For now, don’t trust assumptions implicitly; keep them in view as you move through execution. Assumptions are not always wrong, but if we take the information they give us for granted, they can cause issues during development.

Contradictions

Contradictions are trickier to find and solve. They often stem from misaligned client goals or conflicting audience needs. The common mistake is when we as creatives try to 'solve' contradictions on our own. This ambition usually leads to misalignment down the line. Instead, bring contradictions forward. Discuss them with stakeholders, meaning the individuals or organizations who issued the brief, early. Don't default to solving what you don't yet understand.

Missing Context

Missing context lives in the gap between strategy and data. When communication lapses or something is overlooked. This is normal, but when something feels unclear, don't fill in the blanks yourself. Ask. Point out the gaps to your stakeholders. Often, simply showing where context is missing is enough to realign their expectations or reveal assumptions they didn't know they were making. Other times, missing context is caused by an oversight or a belief that you already knew the context. Confirm this oversight, and align all parties on what is known and what is not prior to moving forward.

The Problem Statement

Not long ago, I was approached by a new client. Their ask was simple: "Can I hire you to design me a logo?" From their perspective that made sense. A logo felt like the natural first step in launching their business. But as we questioned the request together, it became clear that the absence of a logo was not the problem. It was the symptom.

What they needed wasn't a logo. They needed a brand.

Issues like these are where the problem statement comes in. It allows us to evaluate what the request of the brief is, and if the brief captures the right ask to begin with.

The problem statement exists to clarify the ask. It takes the raw material of the brief and reframes it as something you can act on. And like any instruction that guides the work, clarity matters. This brings us to the first rule: a problem statement must be written in plain, direct language.

How to Write a Problem Statement

1. Name the Goal. Clarify what outcome the work is intended to achieve, not just the client's ask. Clients often ask for things like "visibility" or "aesthetics". Dig deeper. Are we trying to convert? Retain? Change behavior? A problem statement without a clear goal can not solve anything.
1. Define the Audience. Who are we solving for? The audience is not just a demographic. Identify emotional states, hesitations, or expectations that shape how your audience engages with the problem.
1. Map the Context. A solution does not exist in isolation. Understand the competitive landscape. Look at cultural, economic, or technological shifts. Context prevents you from reinventing what already exists or solving a problem at the wrong moment.
1. Reframe the Request. Translate asks into real challenges, much like when we named the goal, but this time with additional context. Reframing shifts the project from execution to problem-solving. Most briefs describe symptoms. Your job here is to find the problem.
1. Define Success. How will you know when the work works? Success metrics force specificity. Without them, the work is judged by taste alone.
1. Keep It Sharp. Write the statement as plainly as possible. No metaphors, no marketing jargon. It should be clear enough for anyone on the project to repeat back without confusion. A problem statement is not a pitch. It's a tool.

A strong problem statement is plain, actionable, and specific about what needs to be solved, for whom, and why it matters.

A Reminder on Context

A problem statement without context is just posturing. It might stand up, but it lacks substance. Context gives it that necessary structure. It holds the work upright when someone asks, "Why this direction?"

Step outside the brief and scan the landscape. Observe the shifts in the industry. Who already owns this space? What cultural or technological forces could carry your idea forward or kill it? Study adjacent categories, as well as, direct competitors. Acknowledge when and where you hear people discuss real problems they have. Trace the history of similar ideas and note why they worked. These facts add strength. Context turns opinion into evidence. We'll dig into how to decipher these observations in "Positioning".

Defining the Edges of the Problem

A problem statement is not just about what to solve. It shapes the edges of the solution. Here the constraints introduced in Creative Theory in Design become practical. Boundaries like time, budget, platform restrictions, and legal requirements are not afterthoughts. They're part of the problem we are trying to solve as well. List them early. Be clear about what's immovable, what's flexible, and what might help spark better thinking. A tight timeline might force a sharper focus. Strict accessibility rules may lead to more intelligent layouts. A limited budget might prompt a concept toward elegance rather than excess. Boundaries shouldn't limit creativity. They focus the work.

Equally important is defining what success will look like. Without a success guideline, you are endlessly solving. What does "working" mean? Sometimes, success is measured by clear metrics, conversions, or user insights. At other times, success is less tangible, such as enabling another part of the business to function more effectively. Be specific about what your ideal looks like. And just as importantly, attach a timeline. How will you know if the work is successful, and when will you check?

Including both constraints and measurable success criteria inside the problem statement does two things. It demonstrates to decision-makers that you understand the realities of the work, and it provides your team with a clear framework to work within. Once you know where the edges are, you're free to explore everything inside them.

Only when those edges are defined does the problem statement hold. Only then can you shift perspective and ask the more complex question: Who is this really for?

Who's Our Actual Audience?

Once the problem statement is completed, it guides the work. But don't mistake the end user for the sole audience. The solution also has to satisfy another group: the people who approve it, fund it, build it, or protect the brand's reputation. These stakeholders aren't an afterthought. They're part of the problem itself. Every idea must work for them as well.

Mapping the Terrain

Before you solve the problem, identify who holds influence over the outcome. Stakeholders are the ones who enable your work. You are operating inside a system shaped by their authority, and mapping that system early prevents surprises later. Stakeholder analysis is about surfacing who controls which levers on the project.

Who owns the problem? These are the stakeholders who feel the pressure of the issue day to day. Business leads, managers, or partners who have to answer for it.
Who gains if it is solved? These are the individuals or teams who will directly benefit from it being solved. Finance, operations, marketing; their success is tied to your work delivering.
Who controls the constraints? These are the stakeholders who define the limits. Legal, compliance, brand, or executives who control budget and risk.

Everyone involved should contribute to shaping the work. But don't solve for each stakeholder one at a time. When you start tweaking copy for legal, adjusting visuals for leadership, and layering additions to satisfy each voice for brand, the idea begins to fracture. What you're building is not a compromise. It's a system. Aim for a solution clear enough to make sense to everyone involved, without needing to be translated.

Every project unfolds in two environments. First, within the organization, strategy leads, legal teams, and finance directors decide whether your solution is viable, safe, and fundable. Then, in the real world, users decide whether it's relevant, memorable, or worth their attention. The framing and problem statement should solve for both. If the concept can't survive internal scrutiny and external adoption, it's not ready. Learning to adapt in these moments is something we will continue to discuss throughout this book.

Keep the End User in Focus

Stakeholders shape the work. But the end user decides whether it was worth making. Internal alignment is not the end goal. It's the minimum requirement to create a finished product. The real test happens when the work leaves the building.

When internal conflicts pile up, stop and ask: Who is living with the problem? That is who you're designing for. Let that answer steer the conversation. If the solution does not work for them, no approval process will save it. Get the audience wrong, and no amount of polish can hold the work together.

A Problem Statement in Action

Here is an example of what a brief may say:

"We need a modern, friendly website to help people learn about our new fitness app."

At first, this request sounds reasonable. However, as we begin to consider how to address it, we start to notice its flaws. These are our blind spots showing up firsthand, and it's because our brief skipped some vital framing steps. There's no defined goal beyond general visibility. No clear audience. No understanding of the competition. There are endless ways to solve this, and most of them will fail. The problem statement turns a vague ask into a clear, solvable challenge.

Now compare that to a problem statement written after questioning the ask, and filling in some vital information:

"We're building a website designed to drive free trial sign-ups, not just build awareness. The audience is first-time gym-goers, aged 25 to 40, who often feel intimidated by traditional fitness spaces. Currently, competitors rely on aggressive, performance-driven messaging that often alienates them. The goal is to position the brand as approachable and beginner-friendly, using clear language, a supportive tone, and a simple onboarding process. Success is measured by how many visitors sign up for the trial."

Building a problem statement isn't refining the ask; it helps you judge whether the brief’s request captures the intended result.

Practical Illustration:

Language as a Growth Engine

ZEE5 wanted to boost subscribers in smaller Indian towns. Instead of mimicking global streaming brands, they leaned into local belonging: a new identity, "Apni Bhasha, Apni Kahaniyan" (Our Language, Our Stories), and paired this with affordable regional subscription packs. This pivot tied product, pricing, and positioning to a single cultural truth: language creates loyalty. The result was lower acquisition costs and double the organic traffic. Source

Takeaway: Sharp framing unlocks relevance. Local beats global when the audience feels seen and understood.

Selling Trees, Not Tents

UK brand Tentsile faced a challenge: it needed to increase sales of its tents in the US market. It repositioned itself not as a tent company, but as a reforestation movement. The message, "we sell tents so we can plant trees," turned a novelty product into a purpose-led brand, unlocking partnerships and planting over a million trees in the process. Source

Takeaway: Reframe the product as the mission. People buy why you exist, not what you make.

Outthinking the Competition

With a limited budget and low brand awareness, Iceland's adult toy manufacturer, Blush, utilized surveys to shift its positioning to body-positive curiosity, then employed guerrilla marketing (unconventional, cost-efficient strategies aimed at mass exposure) to amplify this message. What started as customer insight became national recognition and award-winning media coverage. Source

Takeaway: Audience insight beats budget. Knowing who you are talking to is worth more than ad spend.

Self Audit: Revisiting Your Last Brief

Look back at your last project. Be honest. Were you solving the real problem, or just answering the ask? Use these checks to find out:

What was the real goal? Not always what the client asked for, what outcome were they actually chasing?
Who was the actual audience? Did you define what they needed, or list their demographics?
Where were the contradictions? What conflicting expectation or unclear ask did you ignore, or realize too late?
What context were you missing? What surfaced mid-project that changed the work? Should you have caught it earlier?
Could you write a single, clear problem statement now? If not, you did not frame the problem. You reacted to it.

If you can't answer these clearly, you likely missed the real problem and just reacted to the brief instead of reframing it.

Closing Note: What Comes Next

Framing the problem is only half the job. Next, you need to explain your solution. Creative Work as Argument shifts from defining what we are solving to showing why your answer holds up. Design isn't decoration; it is argument. Every color, word, and layout is a statement. You're the one who has to prove it makes sense.

We will get into how to build proof into your work, how to explain your decisions without sounding defensive, and how to turn feedback into something useful instead of something painful. If this chapter helped you ask the right questions, the next one is about answering them with work that speaks for itself.