How to Tell Whether Your Digital Problem Is a Format Problem or a Brief Problem

A client came to us after spending three months briefing, revising, and re-briefing a digital feature that still wasn't working. The format had changed twice, first a chatbot, then a guided quiz, and the engagement numbers barely moved. The team assumed they had a format problem. What they actually had was a brief that had never asked the right question in the first place. The format was fine. The problem it was solving was not the problem the user had.

The format was fine. The problem it was solving was not the problem the user had.

This happens more directly than people expect. A team identifies a drop-off, a low completion rate, or a feature nobody uses, and the instinct is to reach for a different format. Make it shorter. Make it interactive. Add animation. Change the flow. Sometimes that works, and sometimes it works briefly, because a new format draws attention before the underlying gap reasserts itself. The real diagnostic question sits further back: are we solving the wrong thing, or are we solving the right thing badly?

Separating a format problem from a brief problem is not especially complicated, but it does require slowing down before you brief anyone. It means asking a set of questions in order, before a single line of brief is written, before a designer opens a file, before the conversation about which component library to use. The questions are not difficult. The discipline is in actually asking them.

Why Format Gets Chosen Too Early

Format is concrete. A quiz, a modal, a tooltip, a progress bar, these are things you can show in a deck, discuss in a meeting, and hand to a developer. A brief problem is harder to point at. It lives in assumptions, in the framing of the original question, in what nobody checked before the work started. So teams reach for format not because it is the right starting point but because it is the most visible one.

There is also a confidence dynamic at play. Arriving at a meeting with a proposed format feels like having an answer. Arriving with a diagnostic question feels like having nothing yet. This is especially true in organisations where speed is prized, where the pressure to show visible progress pushes decision-making earlier than the thinking warrants. The format gets chosen in week one, and the brief gets written around it, which means the brief is defending a decision rather than discovering whether that decision was right.

The consequence is that format becomes load-bearing in a way it was never designed to be. The brief says "we need a guided quiz to improve onboarding completion." That sentence has already answered a question nobody asked out loud: is a guided quiz the right response to low onboarding completion? The format is in the brief before the problem has been diagnosed. Everything that follows, the design, the copy, the testing, inherits that assumption and cannot easily escape it.

The First Diagnostic Question: What Behaviour Are You Actually Trying to Change?

Before format, before brief, the first question is behavioural. What is the user doing that you want them to do differently, or what are they not doing that you want them to start? This sounds obvious, but stated outcomes are often proxies for the real behaviour. "Increase completion rate" is not a behaviour. "Get users to answer five questions before they close the app" is closer. "Get users to feel confident enough in the product to answer personal health questions on their first session" is closer still, and it changes what you would design.

On the genetics wellness app we worked on, the stated problem was low comprehension and high drop-off. But when we ran focus groups and five-second tests before and after a rewrite, what we found was that users were interpreting genetic results as errors. The behaviour we actually needed to change was the moment of interpretation, the three seconds between seeing an unexpected result and deciding what it meant. Reframing those results as "this is to be expected, everyone is different" shifted comprehension scores and retention measurably in the second round of testing. The format hadn't changed. The brief had.

Write the target behaviour as a sentence describing what a real person does differently after the intervention. If you cannot write that sentence, the brief is not ready.

Getting this specific about behaviour forces the brief to be honest. It surfaces assumptions about what users want, what they fear, and what state they are in when they arrive. A brief that cannot name the behaviour it is changing is a brief that is describing a feature, not solving a problem.

Where in the Journey Does the Problem Sit?

Once you know the behaviour, the next question is where in the user journey the problem actually lives. Drop-off at question four of an onboarding flow is not necessarily a problem with question four. It could be a problem with how the flow was framed at the start, before question one. The drop-off is where the symptom shows up. The cause is often earlier.

We saw this directly on a fitness app project. Early abandonment during the orientation questions was being attributed to the questions themselves, too many, too personal, too soon. The fix being considered was cutting questions. What actually worked was telling users, upfront, how long the process would take. Drop-off went from around 80 to 85 percent to roughly 5 percent after we introduced that single piece of priming. The problem was never the questions. The problem was that users arrived without expectations, encountered something open-ended, and left because they could not see the end of it. The fix sat at the start of the journey, not at the point of drop-off.

The drop-off is where the symptom shows up. The cause is often earlier.

This is why mapping the journey before writing the brief matters. A brief written at the point of symptom will produce a solution at the point of symptom. The right format for fixing a comprehension problem mid-flow may be a single sentence at the beginning of the flow that sets up what is coming. That sentence is a brief decision, and it costs almost nothing to implement.

Locating the cause

When looking at where a problem sits, work backwards from the moment of failure. Ask what the user needed to believe, feel, or understand before they reached that moment, and whether the product gave them any of it. The gap between what they needed and what they had is usually where the brief was thin.

What Has to Be True Emotionally Before Format Can Work?

Format operates on top of emotional state. A user who arrives anxious, confused, or suspicious will not be rescued by a well-designed modal. The emotional preconditions for a format to work are part of the brief, and they are almost always missing from it. Most briefs describe what the user needs to do. Very few describe what the user needs to feel before they can do it.

The meditation app teardown we ran made this visible in a specific way. The breathing animation was doing its job before users had read a single word, the interface was producing a calming effect through motion, not through copy. That is a brief that understood the emotional precondition: a user arriving anxious needs to be slowed down before they can receive any content. The format (animation, pacing, visual rhythm) was the answer to a brief that had asked "what does this user need to feel in the first ten seconds?" rather than "what do we need to show them?"

By contrast, a brief that skips the emotional question will produce a format that assumes the user arrives ready. The product design failure we see most often is designing for the ideal user, calm, rational, motivated, rather than the actual one who shows up. On the meditation app, the actual user was frequently anxious. The brief had to account for that before format could do anything useful.

Add an emotional state column to your journey map. For each stage, describe what the user is likely feeling, not what you want them to feel. Brief from that description, not from the ideal.

The Difference Between a Format Problem and a Brief Problem

A format problem is real but bounded. The information architecture is wrong, the interaction model creates confusion, the visual hierarchy buries what the user needs. These are fixable within the existing brief. You know what you are trying to achieve, you know for whom, and you have a reasonably accurate picture of the moment of use. The format is just not serving that well enough.

A brief problem sits underneath all of that. It means the brief was answering the wrong question, describing the wrong moment, or targeting the wrong behaviour. Format changes will not fix it because the format was always going to struggle, no matter how well executed, because it was built on a brief that missed something.

The dating app project we worked on is a direct example of a brief problem producing real cost. The client skipped discovery for the messaging component and briefed only on onboarding. The onboarding was rigorously verified against bots and fake accounts. The messaging feature, built without discovery, allowed automated and fake messages, which directly contradicted the product's entire premise. That mismatch required a full rewrite of the messaging section, adding approximately £15,000 to the budget and two months of additional work. No format change could have fixed it. The brief had never asked what the messaging feature needed to be consistent with.

How Expectation-Setting Can Outperform the Format Itself

One of the clearest illustrations of a brief problem hiding behind a format assumption is what happens when expectation-setting is built into the brief rather than the format. The fitness app work showed this in numbers. The team was looking at format options for reducing abandonment in the orientation flow, shorter questions, fewer steps, a different visual design. The actual fix was a single sentence before the flow began, telling users how long it would take.

Completion rates rose from around 15 to 20 percent to approximately 95 percent. The format did not change. The brief changed, from "design a better orientation flow" to "prepare the user emotionally before the flow begins." Those are different briefs, and they produce different solutions. One produces a redesigned flow. The other produces a sentence that sits above it.

Expectation-setting is a brief-level decision because it determines what the product needs to communicate before any feature does its job. If the brief does not account for the user's starting emotional state, confused, time-pressured, uncertain about commitment, then no amount of format refinement will compensate. The gap exists before the user reaches the interface. The brief has to reach back and close it.

Before briefing any interaction, ask what the user needs to know, expect, or feel before they encounter it. If the answer involves anything the interface cannot deliver in under three seconds, the brief needs a pre-step.

When the Problem Is the Moment, Not the Medium

Some problems are about the specific moment in which the user encounters the product, rather than about format or brief in the abstract. Checkout flows are a good example. A flow that tests well in a usability session can still produce drop-off in a live environment, because the emotional state of a person about to spend real money is fundamentally different from the emotional state of someone reviewing a prototype. In testing, users assess the flow rationally. Live, they are in a moment of financial commitment, and any element that erodes trust, a line of copy that reads as ambiguous, a data-use disclosure that feels vague, is enough to cause them to leave.

The brief problem here is that it treated a test scenario as equivalent to the real moment. Testing told the team the flow worked. Live analytics told a different story. The medium was fine. The moment was different from the one the brief had imagined.

This means briefs need to name the moment explicitly. Not "user reaches checkout" but "user is about to enter card details for the first time, on a brand they have used for less than ten minutes, on a mobile device, possibly on public transport." That level of specificity changes what the brief asks for and what the format needs to do. A vague moment produces a format that works in the abstract and fails in practice.

Running the Diagnostic Before You Write a Single Line of Brief

The diagnostic is a set of questions asked in order, before the brief document opens. They are not part of the brief, they generate the brief. Running them takes an hour. Skipping them costs weeks.

1. What specific behaviour are we trying to change, and in whom?
2. Where in the journey does the problem actually sit, not just where does it show up?
3. What does the user need to feel, believe, or understand before they can do what we are asking?
4. What emotional state are they in when they arrive at this moment?
5. Has the format been chosen because it fits the answer to those questions, or because it felt like the obvious thing to try?

If question five reveals that the format was chosen before questions one through four were answered, the diagnostic has done its job. The format needs to wait. On the genetics wellness app project, we ran focus groups and five-second tests at the brief stage, before any significant build had happened. The comprehension scores from that first round of testing were low enough to rewrite the brief entirely, from "make the results page clearer" to "reframe unexpected results as expected variation before users interpret them as errors." The second round of testing showed marked improvements in clarity, purpose, and retention. The brief changed. The format largely did not.

Common Format Mistakes and the Brief Gaps Behind Them

Format mistakes tend to follow patterns, and each pattern points to a specific brief gap. Recognising the pattern tells you where to look for the gap.

Format that assumes readiness

A product asks users to make a decision or provide information before they have enough context to do so comfortably. The brief described the decision but not the prior state. The fix is a brief that accounts for what the user needs before the decision point.

Format that solves the wrong problem

A travel app we worked on was asking users to rate their holiday experience with a standard review prompt. Engagement was low. The brief had framed this as a format problem: the rating interaction needed improving. The actual problem was the framing of the ask. Rewriting the copy from "rate this experience" to "what would you tell other travellers about this?" changed the psychological frame entirely, users felt they were helping other people, not feeding data to a company. The format stayed the same. The brief had missed what the user needed to feel about the act of responding.

Other common brief gaps behind format problems include a missing emotional precondition, a target behaviour that is actually a feature description, and a moment of use that was imagined rather than observed. Each produces a format that is well-executed and wrong.

How to Pressure-Test Your Format Decision With What You Already Know

Before committing to a format, run what you know against three questions. First: does the format assume an emotional state the user is unlikely to be in? A format that requires calm, focused attention will fail in a moment of anxiety or time pressure. Second: does the format address the behaviour named in the brief, or does it address a proxy for it? A progress bar addresses visibility of progress, it does not address the user's fear that the process will take longer than they have. Third: if the format were removed entirely and replaced with a single sentence, would the problem still be solved? If yes, the format is doing less work than the brief language suggests.

Asking permission rather than demanding information is a good example of a brief-level answer that makes format almost irrelevant. Changing "enter your address" to "can we connect your address?" shifts the psychological relationship between user and product. Users feel they have control. Engagement and retention improve, and the change costs nothing in format terms. It is a brief decision, made before a designer touches anything.

Pressure-testing a format decision with existing knowledge, analytics, prior test results, what you know about the emotional state of the arriving user, is the work that prevents the other work from being wasted.

Conclusion

The distinction between a format problem and a brief problem is not subtle once you learn to look for it, but it does require asking questions before reaching for solutions. Format is visible and concrete. A brief problem is quieter and sits further back in the process, which is exactly why it tends to go undiagnosed until the format has been changed twice and the numbers have barely moved.

The fitness app work, the genetics wellness app, the dating app, each of these shows the same pattern from a different angle. A brief that had not asked the right question produced a solution that addressed a symptom rather than a cause. In the dating app case, skipping discovery on the messaging brief cost £15,000 and two months. In the fitness app case, a single sentence of expectation-setting shifted completion from around 15 to 20 percent to approximately 95. The brief was the variable. The format was almost incidental.

Running the diagnostic before the brief is written is the thing that makes the brief worth writing. Knowing the target behaviour, the moment of use, and the emotional state of the arriving user means the brief can ask the right question. When the brief asks the right question, the format has a chance of answering it.

If you are looking at a digital problem and unsure whether you have a format issue or something sitting underneath it, let's talk about your brief before you write it.

Frequently Asked Questions