What Belongs in a Product's Emotional Design Principles Document?

Every product team reaches a point where the brief runs dry. The research is done, the personas are built, the emotional arc is mapped, and then someone has to make a decision the brief never covered. A new onboarding screen. A notification that feels slightly off. A tooltip that nobody can agree on. In those moments, teams reach for whatever shared reference point exists. If there isn't one, they guess.

That is the gap an emotional design principles document fills. And it is a bigger gap than most teams expect. A brief describes a product at a point in time. A principles document describes how the product thinks, which means it stays useful long after the brief has expired. It travels with the team through sprints, through handovers, through the arrival of new designers who were not in the original workshops.

The question is what actually belongs in that document. A lot of principles documents exist in name only, full of warm language about empathy and delight that gives teams no real direction when a decision needs to be made. Writing something useful takes a different kind of discipline. The principles have to be specific enough to rule things out, grounded in the emotional territory the product genuinely occupies, and written in a way that people will actually read.

Why Briefs Run Out and Principles Documents Fill the Gap

A project brief has a natural lifespan. It captures the problem to solve, the audience to serve, and the constraints to work within. It is written at the start, when understanding is still being built, and it tends to reflect the questions the team was asking at that moment. By the time the product is being built and iterated, the brief has already started to feel like a historical document.

Emotional design decisions keep arriving long after the brief stops being relevant. The brief might establish that users feel anxious during the checkout process, but it rarely specifies what to do when a micro-interaction accidentally amplifies that anxiety rather than easing it. It might describe the product's personality in broad strokes, but it does not resolve the debate between two copywriters about whether a success message should feel warm or energising.

This is why the principles document exists. It takes the emotional territory that research has uncovered and turns it into standing guidance. Where the brief describes the problem, the principles document describes the product's character and its commitments to the people using it. Teams that work without one often rediscover the same emotional tensions across successive sprints, resolving them inconsistently each time.

The documents that work are not long. They do not try to cover every scenario. They articulate the emotional logic behind the product clearly enough that the team can apply it to scenarios nobody anticipated. That is a different and harder thing to write than a list of values.

The Anatomy of a Useful Principles Document

Most principles documents contain the same sections because most design teams are drawing on similar templates. The useful ones contain something those templates tend to leave out, which is a clear statement of the emotional problem the product was built to solve. Before any principle can be written, the team needs to agree on what emotional friction the product is addressing. A scheduling tool built to relieve the anxiety of forgotten commitments is a different product, emotionally, from one built to give professionals a sense of control over their time, even if the features are nearly identical.

From that foundation, a useful document tends to contain four things. First, a description of the emotional states users arrive with and the ones the product aims to leave them in. Second, a personality statement that describes the product as a character, covering how it speaks, what it prioritises, and how it behaves under pressure. Third, the principles themselves. Fourth, brief notes on what each principle rules out as well as what it rules in.

Emotional arc before personality

The order matters. Personality defined before the emotional arc tends to produce character descriptions that are decorative, a list of adjectives that sound appealing but have no functional connection to the people the product serves. Mapping the emotional arc first grounds the personality in something real. The product's character should be a direct response to the emotional territory it is entering.

Before writing a single principle, write one sentence describing the emotional state your user arrives in and one sentence describing the state you want them to leave in. Every principle should serve that transition in some way.

Writing Principles That Actually Make Decisions

The test of a principle is whether it resolves a disagreement. If two people read the same principle and reach different conclusions about what to do in a specific situation, the principle has not done its job. Most principles fail this test because they describe an aspiration rather than a position. "We treat users with respect" is an aspiration. Almost any design decision can be argued to be respectful. It gives the team nothing to hold on to when a genuine tension arises.

Principles that make decisions tend to be written as trade-offs. They say what the product prioritises when two reasonable things are in conflict. A principle like "we slow down when users are uncertain rather than pushing them forward" makes a clear call: when there is a choice between conversion speed and user confidence, user confidence wins. That resolves disagreements. It also rules things out, which is what principles are for.

The emotional engineering question is always what the product is trying to make people feel, and each decision should be traceable back to that. When a team has agreed that the product's job is to make people feel capable rather than efficient, copywriting decisions, interaction patterns, and error messages all start to point in the same direction. Without that agreement written down somewhere, the same debate happens repeatedly.

Design principles only earn their place when they are specific enough to rule things out and grounded in the emotional territory users actually occupy.

Writing in this way requires the team to have genuinely resolved some disagreements before the document is written, rather than using the document to defer them. If the team cannot agree on what the product prioritises, the principles will be vague because vagueness is the only thing everyone can sign off on.

For each principle, write a brief "this means we would not" note alongside it. If you cannot name at least one thing the principle rules out, it is probably not specific enough to be useful.

Language and Tone Within the Document Itself

There is an obvious irony in a document about emotional design being written in cold, corporate language. The principles document is itself a product communication, and the way it is written should reflect the emotional character it is describing. If the product is warm and steady, the document should feel warm and steady. If the product is precise and confident, the document should reflect that too.

This is not about making the document sound clever. It is about coherence. When the document's own language contradicts the personality it is describing, it creates a subtle but real credibility problem. Teams start to feel the gap between what the document says and what it does, and that gap tends to make them trust the document less.

Concrete language over aspirational language

Concrete language also helps. Principles documents that lean on abstract nouns, words like harmony, empathy, and authenticity, tend to be ones that teams stop referring to. The words feel meaningful in isolation but carry too little specific content to be applied. Replacing "we communicate with empathy" with "we acknowledge what the user is feeling before we ask them to do anything" gives the team something they can actually check a design against.

The document should also be honest about tension. Stating that two principles will sometimes pull in different directions, and explaining how to weigh them, is more useful than pretending principles exist in perfect harmony. Users reading a notification during a high-anxiety moment need different things from users exploring the product out of curiosity. Acknowledging that is not a weakness in the document. It is the document doing its job.

Testing Whether a Principle Is Decision-Useful

Before a principles document is finalised, it is worth running a simple check on each principle. Present the team with two or three real design decisions from the current or recent product, things that actually caused disagreement or took longer than expected to resolve. Ask each person to apply the principle independently and see whether they arrive at the same answer.

If the answers diverge, the principle needs work. If everyone arrives at the same answer but it is the wrong answer for the product, the principle is either pointing in the wrong direction or missing a qualifying condition. If everyone arrives at the right answer, the principle is doing what it is supposed to do.

Gut check questions for each principle

A few gut check questions work well alongside this process. Does the principle still hold under pressure, meaning when time is short or commercial pressure is high? Does it apply to copy, interaction design, and visual decisions equally, or does it only really work in one mode? And if a new team member read this principle on their first day, would they know what to do differently because of it?

• Present the principle with two conflicting design options and see which it selects.
• Check whether the principle applies equally to copy, interaction, and visual decisions.
• Ask whether someone new to the team would make a different decision after reading it.
• Confirm that the principle names at least one thing it rules out, not just things it encourages.

Run any new principle past the most recent unresolved design disagreement on the team. If it would not have resolved it, the principle is probably still too broad.

Principles that only apply in ideal conditions are not principles. They are preferences. A product that commits to acknowledging user anxiety before asking for action needs that commitment to hold even when the commercial case for a faster conversion flow is being made loudly. The document has to be written in a way that gives teams the confidence to hold the line.

Principles in Practice: Charity Product and Automotive Booking Tool

The same structural approach produces very different documents depending on the emotional territory involved. A digital product for a charity working with people in financial difficulty arrives in a completely different emotional context from a premium automotive booking tool. The difference is not just tone. It is the entire emotional problem being solved.

For the charity product, the emotional arc might run from shame and uncertainty at the point of arrival to a sense of agency and quiet confidence by the time a user has completed their first task. Principles built around that arc would prioritise reducing the cognitive weight of each step, avoiding any language that implies judgement, and ensuring that progress is made visible in ways that feel earned rather than patronising. A principle like "we never ask for more than the user needs to give right now" would resolve real decisions about form design, data collection, and notification timing.

For the automotive booking tool, the emotional arc is different. Users arrive in a state of considered excitement, looking for confirmation that their choice is a good one. Principles here serve confidence rather than relief. They prioritise clarity over thoroughness, and they protect the sense of pleasure in the decision. A principle like "we answer the question the user has before offering information they have not asked for" shapes copy, information architecture, and the sequencing of content in concrete ways.

The same structural logic applies to both documents. The emotional problem, the arc, the personality, and then the principles. What sits inside that structure is entirely different because the people and their emotional states are entirely different.

Conclusion

A principles document earns its place when it stays useful after the project that produced it has ended. That means being specific about the emotional problem the product solves, grounding the personality in that problem, and writing principles that name trade-offs clearly enough to resolve genuine disagreements rather than paper over them.

Most documents of this type fail not because the team did not care, but because the writing happened too early, before the emotional territory was really understood, or because the pressure to produce something agreeable produced something too vague to be applied. Specificity requires decisions to have already been made. The document records those decisions in a form that travels.

The language the document is written in matters as much as its content. A document that contradicts its own product character in the way it is written trains teams to distrust it quietly. Concrete language, honest acknowledgement of tension, and principles written as trade-offs rather than aspirations are what make the difference between a document people reference and one that lives in a folder nobody opens.

Getting this right takes time and a clear understanding of the people the product serves at an emotional level. If your team is working on a principles document and finding that the principles keep coming out vague or that the same design debates keep recurring, it is usually a sign that the emotional foundation needs more work before the writing can do its job. Let's talk about your product's emotional design foundations.

Frequently Asked Questions