Framing: What Are We Solving?

As we shift from the creative 'what' of Creative Theory in Design to the strategic 'why', we start where every 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're creating, who it's for, and when it's due. But most briefs don't get that far. Even a clear brief can hide flawed thinking. If you act too quickly, you risk solving the wrong problem.

That's why the first step isn't action. It's interrogation. Look for assumptions, contradictions, and missing context. These are your 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 the client's failure, but a natural part of defining human problems. Every brief is incomplete.

Assumptions

Start with assumptions. They're 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 dismiss assumptions; note them for later during creation. Assumptions aren't always wrong, but if we take them for granted, they can cause issues during development.

Contradictions

Contradictions are trickier. They often stem from misaligned client goals or conflicting audience needs. The common mistake: creatives are trying to 'solve' contradictions on their 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. It's normal. 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. That affirmation should always be welcomed.

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 logo wasn't the problem. It was the symptom. What they needed wasn't a logo. They needed a brand.

That's 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.

Brief to Problem Statement Example

Here is an example of what a brief may say:

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 framing. 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:

Building a problem statement isn't refining the ask, it's defining what needs to exist. Until you write the problem statement, you don't know what you're building or why it matters.

Context Gives the Statement Its Spine

A problem statement without context is just posturing. It might stand up, but it lacks substance. Context gives it a spine. It's what holds the work upright when someone asks, "Why this direction?" Before you write anything, 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, not just direct competitors. Listen to real users describe the problem when no brand is listening. Trace the history of similar ideas and note why they worked. These facts become the vertebrae of your statement. Each one adds strength. Context turns opinion into evidence. We'll dig into how to decipher these observations in Chapter Four.

How to Write a Problem Statement

• 1. Name the Goal. Clarify what outcome the work is intended to achieve. Clients often ask for visibility or aesthetics. Dig deeper. Are we trying to convert? Retain? Change behavior? A problem statement without a clear goal is just decoration.
• 2. Define the Audience. Who are we solving for? The audience isn't just demographics. Identify emotional states, hesitations, or expectations that shape how your audience engages with the problem.
• 3. Map the Context. A solution doesn't 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.
• 4. Reframe the Request. Most briefs describe symptoms. Your job is to find the problem. Translate asks like "we need a logo" into real challenges, like brand positioning or clarity of communication. Reframing shifts the project from execution to problem-solving.
• 5. Define Success. How will you know when the work works? Success metrics force specificity. Without them, the work is judged by taste alone.
• 6. Keep It Sharp. Write the statement plainly. No metaphors, no marketing language. It should be clear enough for anyone on the project to repeat back without confusion. A problem statement isn't 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.

Defining the Edges of the Problem

A problem statement isn't just about what to solve. It's about shaping the edges of the solution. This is where the constraints introduced in Creative Theory in Design become practical. Boundaries like time, budget, platform restrictions, and legal requirements aren't 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 don't limit creativity. They focus on realistic expectations.

Equally important is defining what success will look like for us. Without that, you're endlessly solving. What does "working" mean? Sometimes, success is measured by clear metrics, such as KPIs (Key Performance Indicators), 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 measureable 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 solving the problem, identify who controls the outcome. It's not just the end user. You're working inside a system, one shaped by the people who experience the problem, benefit from the solution, or decide whether your work moves forward. Stakeholder analysis is about finding who has authority on the project.

• Who lives with the problem right now? These are the people who experience the issue firsthand. They define why solving it matters.
• Who benefits if it's solved? This includes both external users and internal teams. Knowing where the messaging is felt tells you where your solution will have the most impact.
• Who controls the constraints? These are the people who enforce guardrails, legal, compliance, brand, and account.

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 in isolation, the idea begins to fracture. What you're building isn't 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 solution has to succeed in both. If the concept can't survive internal scrutiny and external adoption, it's not ready.

Keep the End User in Focus

Stakeholders shape the work. But the end user decides whether it was worth making. Internal alignment isn't 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's living with the problem? That's who you're designing for. Let that answer steer the conversation. If the solution doesn't work for them, no approval process will save it. Get the audience wrong, and no amount of polish can hold the work together.

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](https://www.campaignindia.in/ article/why-zee5s-language-first-bet-may-be-its-best-yet/503463)

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 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're 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 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 didn't 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. Because design isn't decoration, it's an argument. Every color, word, and layout is a statement—and you're the one who has to prove it makes sense.

We'll 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.