How to Brief a Development Agency so Behavioural Intent Doesn't Get Lost

A development brief that lists screens, flows, and feature requirements but says nothing about how a user should feel when they get there is a brief that will produce a functional product and an emotionally flat one. The developers will build exactly what they were asked for. The problem is that nobody asked for the right things.

A brief that skips emotional intent doesn't save time. It produces a functional product that nobody wants to use twice.

We worked on a wellness genetics product where the brand's emotional promise and the product experience were completely misaligned. The packaging and online presence were luxurious and aspirational, all about transformation and reaching your full potential. The app itself was cold and clinical, purely functional in its copy and design. Users moved from beautiful marketing, through ordering a kit, doing a test, and then opened the app to see their results. The journey broke down entirely at that point. The development team had built what the brief described. The brief just hadn't described the brand.

That experience shapes how we think about briefs now. The gap between what a brand promises and what a product delivers is almost always a briefing problem, not a development problem. Developers are not mind-readers, and they are not emotional designers. They need to be told, clearly and specifically, what the product should feel like at every stage. This article sets out how to do that.

Why Development Briefs Fail at the Behavioural Layer

Most development briefs are written by people who understand what needs to be built, not how it should feel to use. They describe screens. They list acceptance criteria. They specify what happens when a button is pressed. What they rarely describe is why a particular interaction matters, what emotional state the user is likely to be in when they reach it, or what the product should be communicating beyond the function it performs.

You can spot when emotions were treated as an afterthought because the emotional considerations arrive late in the design process, making them feel bolted on. Features appear that don't quite belong to the product. Marketing copy mentions emotions while the design brief focuses entirely on functionality. The two tracks never meet, and users feel the disconnect even if they can't name it.

According to arXiv, 2007.01761, 78% of requirements-related rework was traced to avoidable gaps in shared understanding between stakeholders and development teams. That figure describes technical requirements. The same gap, applied to behavioural intent, produces products that work correctly and feel wrong.

The fix is to write different briefs entirely. A brief that includes an emotional arc, a brand personality baseline, and clear documentation of the rationale behind key decisions gives a development team something a feature list never can: the ability to make good judgment calls when the brief runs out.

The Emotional Arc Section: Mapping How Users Should Feel at Each Stage

One of the documents we produce from a research debrief is a map of the emotional arc of users through a product. It captures how users feel at each stage of their journey, what they are likely anxious about, what they need reassurance on, and where confidence typically builds. This sits alongside brand personality documents and gets handed to development teams so that implementation decisions are emotionally coherent, not just functionally justified.

The principle behind this is straightforward. A user opening a wellness app for the first time is in a different emotional state from a user who has been using it for three months. The interface should reflect that. In high-anxiety moments, for instance when seeing health data for the first time, the design should simplify and reassure, reducing that heightened state through clarity and careful information layering. As a user grows more confident, complexity can increase. The emotional arc tells you when each of those transitions happens.

Map the emotional state your user arrives with at each key screen, not just the task they need to complete. A user arriving anxious needs different information architecture from a user arriving curious.

Without this document, developers make their own assumptions about what information to show and when. Those assumptions are usually functional ones. The result is an app that presents everything it knows at the earliest opportunity, which is the opposite of what an anxious first-time user needs.

The emotional arc section of a brief should describe, for each significant stage of the journey, what emotional state the user is likely to be in, what the product needs to do for them emotionally at that moment, and how that should shape the pacing and depth of information shown.

The Brand Personality Baseline: Giving Developers a Human Benchmark

One of the exercises we run with clients before auditing copy or micro-interactions is something we call the dinner party. We ask the client to picture the product as a person at a dinner: how do they dress, how do they talk, are they the loudest voice in the room or the quiet listener, who do they gravitate towards? Once that personality is defined clearly enough to feel like a real person, it becomes a benchmark. You can hold any piece of copy or any interaction up against it and ask whether that person would actually say this, or whether they would phrase it differently.

This gives development teams something they almost never get in a brief: a human reference point. When a developer needs to write error copy, or decide how a loading state should behave, or choose between two animation options, they can ask what the dinner party person would do. That question is answerable. "Which option is more on-brand" usually is not, because nobody defined the brand in terms a non-marketer can use.

A human benchmark turns every micro-decision into something a developer can answer without escalating.

The brand personality baseline section of the brief should describe this person in enough concrete detail to be useful. Adjectives alone are not enough. "Warm but professional" tells a developer nothing they can act on. A description of how that person handles an awkward moment, or what they would never say, is actionable.

Give the brand personality as a short character description, not a list of adjectives. Describe how this person behaves under pressure, not just how they present on a good day.

Protecting the Emotional Handoff: When Marketing Promise Meets Product Reality

The wellness genetics project is the clearest example we have of what happens when the emotional handoff between marketing and product is not protected. The brand had done the hard work of building an aspirational promise. Users arrived at the app already emotionally primed, expecting an experience that matched what they had seen and felt throughout the purchase journey. The app delivered data. Accurate, well-organised data. But data without the emotional continuity the brand had promised.

This is not a design failure in the conventional sense. The app was well-built. It was a briefing failure. Nobody had written down that the app needed to carry forward the emotional register of the packaging and the website. Nobody had told the development team that a user arriving to see their genetic results had been on an aspirational journey for weeks, and that the product needed to honour that.

A brief that protects the emotional handoff maps the user journey from the first marketing touchpoint through to the product experience, and identifies the points where the emotional register needs to be consistent. It names the emotional tone at each stage. It flags where a drop in warmth or aspiration would feel like a broken promise.

The specific risk is at the moment a user transitions from something a brand controls entirely, like a website or packaging, to something a development team has built. That transition is where the emotional gap tends to open.

The Decisions Already Made and Why: Documenting Rationale, Not Just Requirements

A development brief typically describes what to build. It rarely explains why certain decisions were made, which means that when developers hit an obstacle, they have no basis for deciding what to protect and what to trade away. A constraint that looks arbitrary to a developer might be carrying significant emotional weight. If nobody explained why it exists, it will be the first thing cut when the build gets complicated.

On the wellness genetics project, when our designs moved to a third-party designer and then to the development team, the rationale behind the emotional design choices was not documented in a way the development team could use. The result was a back-and-forth that cost time and came close to losing the intent entirely. The design looked luxurious but the development team struggled to understand how to implement it on their existing codebase, partly because they didn't know which elements were carrying the emotional weight and which were decorative.

The rationale section of a brief should document, for every significant design decision, what it is trying to achieve emotionally or behaviourally, and what would be lost if it were changed. This is about giving developers the context to make good decisions.

For every interaction that carries emotional intent, write one sentence explaining what it is doing for the user psychologically. That sentence is what saves it when the build gets pressured.

Defining What the App Should and Should Not Replace

During focus groups we ran for a concierge app project, we included participants from social housing, not the target market, but a group that gave us a clear view of how community actually forms. What we found was that these participants were having meaningful, deep conversations with each other, not superficial ones. That depth was what created a genuine sense of community. The temptation with a concierge app is to push everything into it, to make it the single point of contact for every resident need. Our recommendation was the opposite.

The app should handle the mundane and transactional: maintenance requests, fire drill procedures, recycling locations. Those tasks are friction. Removing them from human conversation frees the actual concierge and residents to have the deeper exchanges that build community. Pushing everything into the app would have destroyed the thing the product was meant to support.

This distinction needs to be in the brief. Developers will, quite reasonably, try to build comprehensive solutions. If nobody has documented that some human interactions are deliberate, that the app is meant to protect them rather than replace them, those interactions will be automated away.

• List the tasks the app should handle, because they are low-value or transactional.
• List the interactions the app should actively route to a human, and say why.
• Note any community or relationship dynamic the product depends on and must not disrupt.

Flagging the High-Stakes Moments: Where Trust Is Being Asked For

Trust becomes a design problem at specific moments: when the product asks something of the user. Browsing a content feed requires nothing, so hesitation there is probably a navigation or interest problem. Sharing health data, granting access to a contact list, or entering payment details are a different category entirely. Those are the moments where hesitation carries real information about whether the product has earned the right to ask.

A brief that doesn't identify these moments leaves developers without guidance on how to handle them. The default behaviour is to treat all form fields the same way. A field asking for a nickname and a field asking for financial data get the same design treatment, the same copy tone, the same lack of context. That is the wrong call, and it produces an experience that feels careless at exactly the moment it most needs to feel considered.

The high-stakes moments section of the brief should list every point where the product asks for something that a user might reasonably hesitate over, and describe what the product needs to do at that point to make the ask feel earned. That includes the copy surrounding the ask, the context given, and any reassurance offered.

Calibrating the stakes

A useful way to structure this is a simple table mapping each data request against its trust level.

What Happens When Intent Gets Lost in Implementation

When the design for the wellness genetics product moved through a third-party designer and then to the development team, the intent behind each emotional design decision was not documented in a form the developers could act on. The design looked luxurious. But the development team had an existing codebase, and applying a new interaction layer on top of it without understanding which elements were load-bearing emotionally meant that the back-and-forth to get it right was considerable.

The gap was not between good intentions and bad work. It was between a design that had been created with emotional intent and a handoff that communicated only the visual output of that intent. The developers could see what it looked like. They could not see why each decision existed, and so they could not protect the right things when the build pushed back.

This is the failure mode a well-structured brief is designed to prevent. According to Zeplin, 65% of developers spend four to eight hours weekly interpreting designs due to handoff inefficiencies. That time is wasted on the absence of documented intent, on developers trying to reconstruct thinking that was never written down.

When intent gets lost, the product that ships is functionally correct and emotionally arbitrary. The brand promise is carried up to the product and then dropped. Users feel the discontinuity without knowing what caused it.

How to Structure the Brief So Developers Can Build to Intent

A brief that carries behavioural intent through to implementation needs to be structured so that the emotional and psychological layer is not a separate document a developer can skip. It needs to be integrated into the requirements, so that when a developer reads what to build, they also read why it needs to feel a particular way at that moment.

A working structure

1. Product context: what the brand promises, what users arrive expecting, and what emotional register the product needs to maintain.
2. Brand personality baseline: the dinner party description, written as a character, with concrete examples of what they would and would not say.
3. Emotional arc: for each significant stage, what emotional state the user is in and what the product needs to do for them at that moment.
4. High-stakes moments: a list of every point where trust is being asked for, with specified copy tone and context requirements.
5. Rationale log: for every interaction carrying emotional intent, a sentence explaining what it is doing and what would be lost if it changed.
6. What the app replaces and what it protects: explicit documentation of which human interactions are deliberate and should not be automated.

This structure does not replace a functional brief. It sits alongside it, and the two reference each other. When a developer reaches a screen that asks for health data, they should be able to find, in the brief, both what the field needs to do technically and what it needs to communicate to the user emotionally.

The discipline here is to write the emotional layer before the build starts, not to retrofit it afterwards. A new interaction layer applied on top of existing code can be done, but it requires careful management, and it costs more time than getting it right in the first pass.

Conclusion

A development brief that describes what to build without describing how it should feel will produce a product that works and a brand that quietly loses the trust it spent money earning. The gap between marketing promise and product reality is almost always traceable to a brief that treated emotional intent as somebody else's problem.

The wellness genetics project showed us what that gap costs at its most visible: a luxurious brand promise and a cold, clinical product experience, with users moving between them in a single journey. The concierge app project showed us something different: that knowing what an app should not do is as important as knowing what it should, and that protecting human interaction from automation requires explicit documentation, because developers will quite reasonably build comprehensive solutions if nobody tells them otherwise.

Getting this right is not complicated. It requires documenting the emotional arc before the build starts, giving developers a human benchmark they can apply to micro-decisions, logging the rationale behind interactions that carry psychological weight, and flagging the moments where trust is being asked for so those moments get the care they need. None of that is expensive to produce. What is expensive is the rework when it is missing.

If you are preparing to brief a development agency and you want the emotional layer to survive the handoff, let's talk about your brief before it goes out.

Frequently Asked Questions