When Your Brand and Your Product Disagree: Closing the Gap Customers Can See

Open almost any software company's homepage and then sign in to the product. There is a good chance you will experience a small, hard to name discontinuity. The marketing site is warm, confident, generous with space, and photographic. The application is grey, dense, and functional, built from a component library that has never met the brand. Same company, two different personalities, and a customer crossing between them several times a week.

Nobody decided this. It is the predictable outcome of two teams solving two different problems with two different toolchains on two different timelines. Marketing hired an agency and got an identity. Product built a component library because engineers needed one. Neither was wrong; they simply never shared a foundation, and by the time anyone noticed, both had a year of accumulated decisions to defend.

This article is about closing that gap. What it actually costs, why the obvious fix of making the product match the marketing site is wrong, and a sequence for getting to shared foundations without freezing either team for a quarter. It draws on the visual design and product work we do at companies that have grown past the point where one person held it all together.

What the gap actually costs

It is tempting to treat this as an aesthetic complaint from designers. It is not, and framing it that way is why it stays unfunded. The cost shows up in four measurable places.

Trust at the moment of conversion

A prospect who has spent twenty minutes on a polished marketing site and then enters a trial that looks like a different product experiences a small correction of expectation. Nobody articulates it as a design observation. It surfaces as hesitation, as a support question about whether this is the right plan, and occasionally as an abandoned trial. The site made a promise the product did not visibly keep.

Duplicated work, permanently

Two systems means every shared element gets built twice. A pricing table on the site and a plan selector in the app. A form on the site and a form in the product. Two sets of icons, two button styles, two definitions of what a card is. The duplication is not a one time cost; it recurs on every change, forever, and it grows with the surface area.

Slower delivery on anything spanning the boundary

Onboarding flows, in product upgrade prompts, and any campaign landing somewhere authenticated all straddle the two systems. Each one requires a negotiation about which set of rules applies, and the negotiation costs more than the work.

Accessibility debt in two places

Contrast, focus behaviour, and target sizing have to be solved twice, and in our experience one of the two is always considerably worse. Usually the product, because it was built by engineers under delivery pressure without a designer specifying states, and it is the surface where a customer spends actual hours.

“Customers do not experience your marketing and your product as separate things. They experience one company that seems to change its mind at the login screen.”

How the two systems drift apart in the first place

Understanding the mechanism matters, because the same forces will pull the systems apart again after you have aligned them unless something changes structurally.

The usual sequence runs like this. A company builds a marketing site early, often with an agency, and gets an identity tuned for persuasion. Then it builds a product, and the engineers reasonably reach for an existing component library rather than implementing a brand from a PDF under delivery pressure. That library arrives with its own opinions about colour, spacing, and shape, and those opinions are now in production.

Then both sides accrete. Marketing runs a campaign that introduces a gradient. Product ships a feature that needs a component nobody had, so somebody builds one in the nearest available style. A year of individually sensible decisions later, the two surfaces have different vocabularies and each has a constituency who will defend theirs, because both took real work.

The structural cause underneath all of it is that no single person owns the space between the two. Marketing owns its surfaces, product owns its own, and the boundary belongs to nobody. That is a solvable problem, and it is a different problem from the visual one, which is why alignment programmes that only address the visuals drift back within a year.

Why making the product match the website fails

The instinctive fix is to take the brand and apply it to the application. This is attempted regularly and it fails for reasons that are worth understanding, because the failure is informative about what the right answer looks like.

Marketing design is built for a short, low attention encounter. Large type, generous whitespace, saturated colour, expressive imagery, motion that draws the eye. Every one of those properties is correct there and actively harmful in a tool somebody uses for six hours. Saturated brand colour on every interactive element removes the ability to signal what matters. Generous spacing means a table shows four rows. Expressive motion becomes an irritant by the fortieth repetition.

There is also a density question nobody raises early enough. Marketing pages have one job per screen. Product screens routinely present a hundred pieces of information and thirty actions, and the visual system has to make that navigable rather than beautiful. A brand applied literally to that context produces something that photographs well and is exhausting to use.

So the goal is not sameness. It is family resemblance: an unmistakable sense of one company, achieved through shared foundations expressed at different intensities.

What should be shared, and what should not

This is the whole design problem, and it resolves cleanly once stated as a list.

• Share the colour ramps. The same hues at the same numbered steps. Marketing reaches for the saturated end; product mostly uses the quiet middle and reserves the saturated step for genuine emphasis. One palette, two habits of use.
• Share the type family and the underlying scale. Marketing uses the top of the scale and product uses the bottom. Same ratios, same family, wildly different sizes, and the result still reads as one voice.
• Share the spacing rhythm. The same base unit and the same progression. Product compresses to two or three steps where marketing uses six, but nothing is off grid.
• Share shape language. Corner radius, border weight, and the treatment of edges are cheap to align and disproportionately effective at making two surfaces feel related.
• Do not share density. Product needs compact rows and tight vertical rhythm; marketing needs air. Trying to reconcile this makes both worse.
• Do not share motion. Marketing motion is expressive and can be slow. Product motion should be functional, fast, and mostly imperceptible.
• Do not share imagery. Photography carries marketing. Product surfaces are better served by clear iconography and restraint, and photographic treatment inside a working interface is nearly always a mistake.

Written down like that, the disagreement between the two teams usually turns out to be small. Most of the conflict in these conversations comes from arguing about the whole thing at once rather than separating the layer that must agree from the layer that should not.

The four places the seam shows most

If you want to find the gap in your own product rather than take our word for it, four surfaces expose it reliably, and they are the four worth fixing first because customers meet all of them early.

Signup and login. Almost always built by whoever owned it last, inheriting neither system properly. It is the literal boundary between the two worlds and it is frequently the worst designed screen a customer will see, which is an unfortunate distinction for the moment somebody commits.

Onboarding and empty states. A new user sees these before they see anything the product is actually for. They are the closest a product surface comes to needing marketing's persuasive job, and they are typically built with the plainest components available because nobody scoped them as design work.

Transactional email and notifications. Produced in a third system entirely, usually a template editor nobody has opened in a year, and frequently still carrying the previous brand. These arrive in an inbox next to competitors' communications, which is a harsher comparison than any page on your own site.

Billing and account settings. Considered administrative rather than experiential and therefore never designed, despite being where customers go at precisely the moments they are reconsidering the relationship. A renewal decision made on an ugly screen is not helped by it.

Tokens are the mechanism, not the goal

The practical way to hold shared foundations with divergent expression is a token architecture in three tiers. It sounds like an engineering concern and it is really an organisational one, because it encodes who gets to change what.

1. 01Primitive tokens. The raw values, named neutrally: teal 500, space 4, text size 3. Owned by the brand team. Nobody consumes these directly.
2. 02Semantic tokens. Meaning, mapped to primitives: surface raised, text muted, border interactive. Shared, and where the two contexts start to differ, because a semantic name can point at a different primitive per context.
3. 03Component tokens. Per component and per context: button primary background in product, button primary background on marketing. Owned by whoever owns that surface.

That structure means a brand refresh changes the primitives and propagates everywhere, while the product team retains control of density and emphasis without ever holding a hardcoded hex value. It also makes the governance question concrete: disputes are about which tier a decision belongs in, which is a far more tractable argument than whether something feels on brand. This is the same discipline that keeps a brand identity system coherent as a company grows, applied across two codebases instead of across two teams.

One warning worth stating. Tokens are a mechanism, and companies routinely spend three months building a token pipeline while the two systems continue to diverge. Ship the shared primitives first, in whatever crude form works, and refine the tooling afterwards. The value is in the alignment, not the architecture.

Two ways this goes wrong even with good intentions

The first is the rebuild. Somebody concludes the only clean answer is to rewrite the product interface against the brand, and the estimate arrives at two quarters of engineering time producing no new capability. It gets funded roughly never, and when it does get funded it tends to be cancelled at the halfway point, leaving the product in two states at once, which is worse than where it started.

The second is the design system that becomes a product of its own. A team is formed, tooling is chosen, a documentation site is commissioned, and eight months later there is an impressive component library that three teams have partially adopted while the original inconsistency remains. The system became the goal instead of the alignment it was meant to produce.

Both failures come from the same instinct, which is to solve the whole problem properly rather than to solve the visible part quickly. The version that works is unsatisfying to anyone who likes clean architecture: agree the foundations in a week, apply them to the four surfaces customers actually cross, and let everything else migrate on contact.

A sequence that does not freeze either team

Nobody can stop shipping for a quarter to reconcile two design systems, and any plan requiring that will be declined. This is the order we use, and each step is independently useful if the programme stalls.

1. 01Audit both surfaces honestly. Every colour actually in use, every type size, every button variant. The number is always larger than either team expects and the shock is useful.
2. 02Agree the shared foundation. One colour ramp set, one type scale, one spacing unit. This is a decision meeting, not a design project, and it should take days rather than weeks.
3. 03Define the semantic layer for each context separately. Same names, different mappings where the contexts genuinely differ. Write down why each divergence exists.
4. 04Migrate the most visible boundary first. Usually signup, onboarding, and the account area, because that is where customers cross between the two and where the seam is felt.
5. 05Adopt by replacement. New work uses the shared foundation; existing surfaces migrate when touched. No mass rewrite.
6. 06Put one person in the room for both. The single most effective intervention, and the cheapest.

Step six deserves emphasis because it is organisational rather than technical. The gap exists because two groups made reasonable decisions independently. A standing forum where both are represented, meeting briefly and regularly, prevents the next year of divergence more reliably than any amount of documentation.

On timing, a realistic version of the whole sequence is six to ten weeks of part time effort for a company with one product and one marketing site, spread across two teams who are otherwise shipping normally. The audit takes days. The foundation decision takes a meeting and a week of follow up. The boundary surfaces take two or three sprints. Everything after that is absorbed into work that was happening anyway, which is exactly why the migration by replacement rule matters so much.

Who owns the space between the teams

Every alignment programme we have seen succeed had a named owner for the shared layer, and every one that stalled did not. This is worth being specific about because it is the cheapest thing on the list and the most frequently skipped.

The owner does not need to be senior and does not need a new title. They need three things: the standing to say that a proposed component belongs in the shared layer rather than in one team's, a regular slot where both teams are present, and enough time allocated that it is not the thing that slips when a release is late.

What does not work is a shared committee with rotating attendance, and what works even less is assigning it to whoever has capacity. Both produce a shared layer that nobody defends, and an undefended shared layer is quietly bypassed within two sprints by a team under pressure who needed one component slightly different.

In smaller organisations the practical answer is often one designer who works across both surfaces rather than being embedded in either. It costs a fraction of a role and removes the entire coordination problem, because the negotiation happens inside one person's head rather than across a boundary.

Judging whether it worked

Alignment work is easy to declare finished and hard to prove, so it helps to agree in advance what evidence would count.

• Token coverage. What share of colour and spacing values in each codebase come from the shared set rather than from hardcoded values. This should climb steadily and is trivial to measure.
• Time to ship a boundary spanning feature. Onboarding changes and in product prompts should get measurably faster, because the negotiation disappears.
• Accessibility conformance on both surfaces, measured the same way, with the gap between them closing.
• Qualitative evidence from users crossing the boundary. Five people moving from site to trial while thinking aloud will tell you more than any internal review.

What is not evidence is an internal opinion that things look more consistent now. Everyone involved has been staring at both systems for months and has lost the ability to see them freshly, which is exactly why the user sessions are worth the afternoon they cost.

The underlying point

Brand consistency is not about every surface looking identical. Nobody expects a homepage and a settings screen to resemble each other, and a company that achieved that would have made one of them considerably worse.

What customers notice is coherence: the sense that the same organisation, with the same standards and the same judgement, made both things. That comes from shared foundations, applied with different emphasis, by people who occasionally speak to each other. It is a genuinely modest requirement, and the reason it goes unmet is almost never disagreement about design. It is that nobody owns the space between the two teams.

If you take one action from this, make it the audit. Put every colour and every type size from both surfaces on one page and show it to both teams together. In our experience that single artefact does more to start the work than any argument about brand equity, because the problem stops being an opinion and becomes a picture nobody can defend.

Everything after that is a sequence of small, unglamorous decisions: which ramp wins, which scale wins, who owns the shared layer, and which four surfaces get fixed first. None of it is difficult design work. What makes it hard is that it sits between two teams who are each doing their job correctly, and problems in that position tend to stay unowned until somebody decides to own them.

The companies that feel coherent are rarely the ones with the most sophisticated systems. They are the ones where somebody looked at the whole customer path, noticed the seam, and treated it as work rather than as an aesthetic preference. That decision costs very little and it is visible in every surface a customer touches afterwards, which is an unusually good return for a week of meetings and a shared set of design foundations.