What Belongs in a Pre-Build Emotional Arc Document, and What Doesn't

Before a single screen gets designed, there is a window where the most consequential decisions get made. Not decisions about colour or typography or component libraries, but decisions about what a person feels when they arrive at your product, what you want them to feel when they leave, and what happens emotionally in between. Miss that window and you spend the rest of the project retrofitting emotional considerations onto a structure that was never built to hold them.

The artefact that holds all of this together is what we call a pre-build emotional arc document. It maps the emotional journey a user takes through a product before anyone writes a line of code or places a component on a canvas. Done well, it changes everything downstream: design decisions get made for a reason, copy hits the right register at the right moment, and development teams understand what to build and why it needs to feel a particular way.

Recording the arc, not just the states

The document should also show movement: where the user's emotional state should shift between one touchpoint and the next, and by how much. A sharp upward shift requires something in the product to produce it. A plateau is a choice too. Mapping the intended arc makes it obvious when a product is trying to do too much emotional work in too short a time, or when a low point is being ignored rather than managed. According to LinkedIn / Samer Tallauze, 2024, organisations that implement journey maps systematically report 83% increases in conversion rates, which points to what becomes possible when the emotional logic is built in rather than added later.

At each touchpoint, write down the emotional state the user arrives with before you write down the state you want them to leave with. The gap between those two things is the design problem.

Matching Brand Personality to Each Stage

Brand personality is not a fixed setting. A brand that presents itself identically across every touchpoint will feel tone-deaf at some of them. A brand that is warm and playful at the point of onboarding should probably dial back the playfulness when a user is managing a complaint or navigating something high-stakes. The emotional arc document captures this variation, mapping which facets of the brand personality are appropriate at each stage.

The starting point for this is a clear understanding of the brand as a person. Not in the abstract brand-strategy sense, but specifically: if this brand were a person standing next to the user at this moment in their journey, how would they speak? What would they not say? How much space would they give? The answer changes depending on whether the user is curious and exploratory or stressed and in a hurry.

Consistency within variation

The goal is for the brand to feel consistent across the whole journey while behaving differently at each point. Think of it like a skilled professional in any field. They have a consistent character, but they read the room. The emotional arc document gives the product the information it needs to read the room, because without it, the default is to pick one register and apply it uniformly, and that uniformity is what produces experiences that feel either too casual or too stiff depending on what the user needed at that moment.

The Concierge App Case: Emotional State Dictating What Gets Shown and When

On a concierge app we built for residents moving into a new block of flats, the emotional arc document shaped one of the most consequential product decisions we made. The users were predominantly high-net-worth individuals, and the product needed to serve them from the day of move-in. The standard approach for this type of product is to surface the full directory of information immediately: recycling locations, emergency procedures, building management contacts, local area guides, all of it available on arrival.

We mapped the emotional state of a user on move-in day and found something that changes how you think about information architecture. Some users had just bought their first property and were elated but overwhelmed. Others were moving following a separation or divorce. The emotional range was wide, and almost none of it was calm and receptive. Giving every user the full directory on day one was not an information architecture decision. It was an emotional design failure dressed up as helpfulness.

So we drip-fed content through notifications, timed to match when users would actually need it. Recycling information arrived a couple of days after move-in. Local area recommendations came over the first weekend. If the product had bombarded users with everything at once, it would have contradicted the whole promise of the product: that it was human and community-oriented, not just a digital notice board. The emotional arc document made that contradiction visible before any design began.

When you map emotional states at each touchpoint, pay attention to what users are not emotionally ready to receive. Timing what you withhold is as consequential as timing what you show.

What Does Not Belong in the Document

The emotional arc document has a specific job, and it does that job poorly when other things get loaded into it. Here is what to keep out.

• Design decisions. The document informs design, but does not make it. "Use warm colours at onboarding" is a design decision and belongs in the brief, not here.
• Feature lists. What the product contains is separate from how users feel about it. Features belong in the product specification.
• Persona summaries. A persona describes a user type. The arc document describes emotional states at specific moments. Paste personas in and the document becomes unreadable.
• Business objectives. User acquisition targets and revenue goals are not emotional states. They belong in the project charter.
• Aspirational language about brand values. Saying the brand is "empowering" or "trustworthy" at every stage tells a designer nothing about how to produce those qualities in a specific interaction.

The test for anything that might go in is simple: does this tell a designer something specific about how a user feels at a named point in the journey, or how the brand should respond to that feeling? If it does neither, it does not belong. A bloated document gets ignored, which defeats the purpose entirely.

How the Wellness Genetics Project Shows What Happens Without It

We were brought in to work on a wellness genetics product: a premium, wellness-focused brand with a data-heavy product that had been built in a functional way that did not match the brand feel at all. The brief was to improve the emotional layer, to get users to engage with something that was rich in information but cold in experience. The product had been built without a pre-build emotional arc document, and the gap between what the brand promised and what the product delivered was visible at every touchpoint.

We produced designs with a third-party designer that looked genuinely luxurious and brand-appropriate. When those designs reached the development team, the problems started. The development team struggled to understand how the new interaction layer could work on top of the existing codebase. There was considerable back and forth to reconcile what the emotional design required with what the technical foundation could actually support.

That friction was not a development problem. It was a planning problem that arrived late. If the emotional arc had been established before the product was built, the technical architecture decisions would have been made with the emotional layer in mind from the start, rather than having to reverse-engineer it onto a structure that was never designed to hold it. Applying emotion as a layer on top of existing code is a fundamentally harder problem than building with emotion from the beginning.

Brief your development team with the emotional arc document alongside the technical specification. If they only receive technical requirements, they will make implementation decisions that are technically correct and emotionally wrong.

Using the Artefact as a Live Reference During Design

The emotional arc document earns its place not by being produced but by being used. It should sit open during design reviews, not filed away after the discovery phase. Every design decision a team makes carries an implicit assumption about the user's emotional state at that moment. The artefact makes those assumptions explicit and checkable.

In practice, this means asking at each review whether the design is responding to the emotional state identified at that touchpoint. A screen designed for a user who is anxious should look and behave differently from one designed for a user who is confident and exploratory. If the two screens are visually and behaviourally similar, the emotional arc has been ignored. That is a conversation worth having during design, not during post-launch feedback.

Resolving disagreements with the document

Design teams disagree about tone, pacing, and hierarchy constantly. The emotional arc document gives those disagreements a shared reference point. Rather than debating which approach "feels right", the team can ask which approach fits the emotional state identified for this stage and why. That question is easier to answer than taste, and it moves decisions forward without requiring someone to win an argument on aesthetic grounds alone.

Handing It to Development Teams

Development teams receive a great deal of documentation. What they rarely receive is a document that explains the emotional logic behind what they are building. The result is that implementation decisions get made on technical grounds, which is appropriate for technical decisions and actively harmful for emotional ones. Animation timing, micro-interaction behaviour, loading state design: these are all emotional decisions that get made by developers when nobody has told them what the emotional goal is.

Handing the emotional arc document to a development team gives developers enough context to flag when a technical decision would compromise the emotional intent. A developer who knows that a particular screen is designed for a user in a high-anxiety state and that the goal is to reduce that anxiety can identify when a proposed loading animation would make it worse. Without that context, they cannot.

What to translate and what to leave

Some sections of the document translate directly: emotional states at each touchpoint, the intended arc, notes about pacing and timing. Brand personality guidance translates less directly and often needs a conversation rather than a handover. Build that conversation into the project plan rather than assuming the document is self-explanatory. It is not, any more than a design system is self-explanatory to someone who has never used it.

Keeping It Current After Launch

User emotional states change. A product that was novel and slightly daunting on first use becomes familiar over time. A feature that initially produced delight becomes unremarkable once users are habituated to it. The emotional arc document needs to reflect that, which means revisiting it at regular intervals after launch, not only before build.

The inputs for those revisions are not guesswork. Dwell time data tells you where users slow down, which often indicates either genuine engagement or confusion. Drop-off points reveal where the emotional experience is failing to hold people. User feedback, when it describes feelings rather than features, maps directly back to the arc. The document should be updated when the data suggests the emotional experience has shifted from what was intended, and design responses should follow.

This is where the artefact becomes genuinely different from a planning document. Planning documents describe intention. A living emotional arc document describes the gap between intention and what is actually happening in the product, and that gap is where the next iteration of work begins. Teams that treat the document as something produced once and then archived lose the return on the investment they made in producing it.

Conclusion

A pre-build emotional arc document is precise work. It requires knowing the difference between what belongs in it and what does not, and being rigorous about that distinction. Stuffed with design decisions, brand values, and persona summaries it becomes unusable. Kept focused on emotional states at specific touchpoints, the intended arc between them, and the brand personality appropriate to each moment, it becomes the clearest brief a design team can have.

The wellness genetics project showed what happens when that clarity arrives late: designs that look right but cannot be implemented without costly back and forth, because the emotional layer was never part of the original architecture. The concierge app showed what becomes possible when it arrives early: a product where even the timing of a notification is an emotionally considered decision, grounded in a document that was written before a single screen was designed.

The artefact does not do the design work. It makes the design work purposeful. Every colour choice, every micro-interaction, every piece of copy has a reason when the emotional arc has been mapped in advance. Without it, those decisions still get made, but they get made in a vacuum, and the product shows it.

If you are starting a project and the emotional arc has not been mapped yet, that is the most productive place to begin. Let's talk about your product's emotional design.

Frequently Asked Questions