Why brand and product UX need to share a discovery phase before a redesign starts, and what tends to break when one workstream gets finished before the other begins.
A style guide arrives first, forty pages of color values and type pairings, plus a full set of logo lockups, months before anyone opens a prototyping tool. Then the interface work starts. The approved buttons don’t have a defined disabled state. The approved palette has no accessible contrast pair for form errors, and half the component library needs a variance request before it can ship. Nobody did anything wrong. The two workstreams just never sat in the same room.
This is still one of the most common ways a redesign loses weeks it never gets back. A brand identity design company and a product UX team are usually hired on separate contracts with separate briefs, even when the output of one directly constrains the other. This piece looks at what breaks when they meet too late, and what a shared discovery phase needs to include.
Key Takeaways
- A brand system finished before UX work starts is usually built for print and marketing pages, not interactive states like hover and error, let alone loading or disabled.
- A UX flow shipped before brand work starts creates the opposite problem: a working product that then needs a full visual reskin without breaking anything already tested.
- Running brand and UX discovery in the same phase, with the same brief, catches most of these conflicts before either team has committed real hours to a fix.
- The fix is making sure whoever is hired coordinates from day one, regardless of how many contracts are involved, rather than assuming one combined team solves it by default.
Design-mature companies treat this coordination as a structural decision, not an afterthought. Top-quartile scorers on McKinsey’s Design Value Index outgrew their industry peers by 32 percentage points in revenue growth over five years, a gap McKinsey ties to how deliberately those companies integrate design decisions across a product rather than sequencing them as separate deliverables.
According to McKinsey, top-quartile performers on its Design Value Index grew revenue 32 percentage points faster than industry peers over a five-year period, tied to how consistently design decisions get integrated rather than handled as isolated deliverables. (McKinsey, 2018)
What happens when brand finishes first
A finished brand system built without product input tends to describe a static world: a logo, a palette, a type scale, maybe a handful of marketing page templates. It rarely specifies what a button looks like mid-loading. It says even less about what an error state should feel like without breaking the palette’s contrast ratios. And it almost never addresses how dense a data table can get before the approved type scale stops being readable.
When product UX work starts afterward, the design team has two bad options. Follow the brand guide literally and ship interface states that are technically on-brand but functionally weak, or deviate from it without saying so to solve a real usability problem, which reopens a conversation everyone assumed was closed. Neither option is cheap, and both usually show up as delay once someone notices mid-sprint.
What happens when UX ships first
The reverse order has its own failure mode. A product team validates flows, ships a working interface, and only afterward brings in brand work to formalize the visual language. By then, component patterns, spacing decisions, and interaction conventions are already tested and, in many cases, already in production.
A brand identity effort that arrives at that point ends up reskinning something that already works, under pressure to avoid breaking flows real users already tested, rather than building a system from scratch. That constraint often produces a brand system that looks fine in isolation but never quite resolves into the product, because the product’s own logic was locked in before brand had a seat at the table.
Why sharing a calendar isn’t the same as sharing a brief
Some teams think they’ve solved this by scheduling brand and UX work in the same quarter. Running in parallel isn’t the same as running from a shared brief. Two teams working the same three months on separate documents, checking in occasionally, still end up making incompatible decisions, just faster than if they’d worked sequentially.
A shared brief means both teams start from the same research: the same user interviews, the same competitive scan, the same list of interface states that need to exist. Brand decisions get tested against real screens, not mockups of a homepage. UX decisions get made with the visual system’s real constraints in view, not a placeholder palette swapped out later.
According to McKinsey, more than 40 percent of surveyed companies were not talking to their end users during development, one of the gaps its Business Value of Design research ties to weaker design integration. (McKinsey, 2018)
What a joint discovery phase produces
Run well, this phase leaves a project with things a separate-track process usually misses. An interaction inventory names every distinct state a component needs to support, built before anyone finalizes a color or type decision, while a shared component vocabulary keeps brand and product design from naming the same element two different ways. Conflicts between brand and usability get logged with a decision and a reason attached, instead of surfacing as a surprise six weeks into build.
None of this requires one company to run both workstreams. It requires whoever runs each one to work from the same source material and check in against the same milestones, not just a shared kickoff call and radio silence after.
Expert insight. Oleksandr Kostiuchenko, Marketing Manager at Phenomenon Studio, has observed that budget size rarely predicts how smoothly a joint brand and UX engagement goes. What predicts it is whether both teams sat down with the same research before either one started producing final work, so a decision made on one side never ran headfirst into an assumption the other side had already set aside.
What a brand identity partner needs from product research
A brand identity design company doing this work well doesn’t start with a mood board. It starts by asking what the product needs the visual system to do, including how many distinct interface states exist, how dense the data views get, and what accessibility contrast requirements apply to form validation. Skip that step and the brand identity design company ends up designing for a version of the product that only exists in a slide deck.
A user experience design agency that finalizes flows without knowing what the brand system can support downstream risks building interactions that look nothing like the finished visual language, forcing a second round of revisions once the two finally meet. A user experience design agency and a brand identity design company that review the same research together avoid both problems at once, because neither side is guessing at what the other one needs.
The vendor categories this decision touches
Buyers scoping this work often end up comparing providers that sound different but overlap heavily. A web development agency handles the engineering layer, while a website development agency or website development company frequently means the same kind of provider, chosen by whichever term a buyer searched first. None of these three labels guarantees brand or UX capability is included by default.
A web design agency sits closer to the interface side without necessarily including brand strategy, and a UX design agency narrows further into research and interaction work specifically. Mobile introduces its own version of the same ambiguity. Calling a provider a mobile app development company or a mobile app development agency rarely signals a real distinction in what work gets delivered. Neither does calling it a seller of mobile app development services. Web app development sits in its own category, in the browser-based space between native apps and a standard website.
Branding companies are where this gets most confusing. Some fold brand identity into a broader website design services package by default. Others treat it as a fully separate engagement with its own timeline, billed apart from any interface work. Neither approach is wrong on its own, but assuming one when the contract specifies the other is exactly the gap that lets brand and UX drift apart before anyone notices.
Your browser does not support embedded video.
Getting proposals that price the same work
Once a company decides brand and UX should move together, comparing vendor quotes gets harder, not easier, because most proposal templates were never built for a joint scope. A quote built around web development services alone rarely accounts for the coordination overhead of syncing with a separate brand vendor, and a package advertised as web design services can mean anything from full research to a template restyle depending on the provider.
Ask specifically whether website design services in a given quote includes brand system work, or assumes it’s already finished elsewhere. The same question applies to UI UX design services line items, since some providers bundle interaction design with visual identity work and others keep them strictly separate, billed under different scopes entirely.
Mobile scoping runs into an identical gap. A quote for mobile engineering work might assume brand assets already exist and simply need to be applied, while a full UI UX design services engagement for the same app would include defining those visual states from scratch. Confirm which assumption a given proposal is making before comparing its price against a competing bid.
A short example of how this plays out
A B2B software company we partnered with had already commissioned a full brand refresh, complete with a new palette and logo system, before product work began. The interface team spent the first two weeks of the engagement documenting every screen state the approved palette couldn’t support on its own, rather than designing new screens.
Rather than treating that as a setback, both teams used the list as the basis for a short, joint working session with the brand vendor still under contract. Three color pairs got added specifically for error and disabled states, and the component library shipped without another mid-project palette dispute. The fix cost a week. Skipping that conversation would likely have cost more once development had already built against the wrong assumptions.
Two contracts or one: what the paperwork should reflect
Some companies run this as a single contract with one accountable team covering both brand identity design company work and user experience design agency work under one scope. Others keep them as two separate vendors but require both to work from the same brief and attend the same milestone reviews. Either structure holds up. What fails is treating the two contracts as unrelated just because the invoices come from different companies.
Once engineering gets scoped separately, a provider delivering web development services on a fixed timeline needs to know what the brand identity design company and user experience design agency teams are still finalizing, or its estimate gets built on assumptions that shift under it later. A website development agency quoting web development services under a different label carries the identical risk.
Mobile and web builds carry the same exposure. A mobile app development company pricing a build against an unfinished visual system is pricing against a moving target, and a website development company estimating web design services runs into the same problem before brand work has settled on a final direction. A web design agency asked to quote website development agency-style engineering work as an add-on should flag the same dependency rather than pricing around it silently.
None of this requires picking one model over the other permanently. A team that starts with two separate vendors can still consolidate later once trust is established, and a mobile app development company already under contract can absorb additional web design services scope if the same coordination discipline carries over.
What a shared discovery brief should include
A useful joint brief names the interface states that need visual definition before either team starts producing final assets, at minimum:
- Default and hover
- Focus and error
- Loading and empty
- Disabled
It also names who has final say when a brand decision and a usability finding genuinely conflict, since that ambiguity is what turns a five-minute disagreement into a two-week standoff.
It should also specify a checkpoint before either team moves into high-fidelity work: a short review where both sides confirm the visual system, as currently drafted, supports the states the product needs. Skipping that checkpoint is the single most common reason this coordination effort fails even when everyone involved had good intentions.
Timeline and cost: what coordinating costs
Running brand and product UX from a shared brief adds one to two weeks upfront for joint discovery before either team starts producing final deliverables. That cost is usually smaller than the alternative. A mid-project palette revision or component rebuild is common, and sometimes it takes a full brand refresh to accommodate screens already locked into production.
The teams most likely to skip this step are the ones under the most schedule pressure already, which is exactly backwards. A rushed timeline is when the cost of a late-discovered conflict is hardest to absorb, since there’s no slack left to fix it without pushing the launch date.
How to tell the coordination worked
A glowing kickoff meeting tells you very little. The clearer signal shows up six weeks into build, when engineers start hitting edge cases the original brief didn’t anticipate. If brand and product teams can resolve those cases together in a single short conversation, the shared discovery phase did its job. If every edge case turns into a multi-day standoff over which system takes priority, the coordination was surface-level, regardless of how good the kickoff felt at the time.
A second, quieter signal shows up in the component library itself. A well-coordinated project produces a library where visual and interaction decisions read as one system, not two systems politely coexisting. Reviewers looking at the finished product usually can’t tell where brand work ended and UX work began, which is the outcome the joint discovery phase was meant to produce.
Questions worth asking a prospective partner
Ask any user experience design agency under consideration how they handle a brand system that arrives already finished, and ask any brand vendor how they handle a product interface that’s already shipped. How specifically each side answers tells you more about how the actual engagement will run than anything written in the proposal.
Also worth asking directly: has this provider run brand and UX discovery together before, on a project close in scope to yours, and what changed as a result of that coordination. A vague answer here is usually a sign the two workstreams will end up running on separate tracks regardless of what the contract implies.
Deciding how to structure this for your own project
Not every project needs a fully combined team to get this right. What it needs is an explicit agreement, in writing, about which interface states get defined jointly, who resolves conflicts between brand and usability findings, and when the two teams check in against each other’s progress. A single provider covering both disciplines makes that coordination easier by default, but it isn’t the only path to the same outcome.
What consistently fails is treating brand and UX as sequential deliverables with no shared checkpoint between them. Whether that’s solved with one combined team or two well-coordinated vendors matters less than making sure the coordination itself is scoped, scheduled, and owned by someone specific from the start.
Frequently asked questions
Does brand identity work always need to happen before product UX work?
No. Sequencing either discipline fully first tends to create the same kind of problem in reverse. Running the two in parallel from a shared research base avoids both failure modes.
What’s the fastest way to tell if a brand system is missing interaction states?
Check whether it defines anything beyond a static palette and type scale. Hover and focus need their own defined treatment, and so do error and loading. Empty and disabled states matter just as much. If none of those are specified, the system was likely built for marketing pages rather than an interactive product.
Can one provider realistically handle both brand and UX without either discipline suffering?
It can, provided the team has solid depth in both areas rather than treating one as secondary. Ask for work samples in both disciplines from the same engagement, not separate portfolios that never overlapped on a shared project.
How long should a joint brand and UX discovery phase take?
One to two weeks for a mid-sized product, longer for a multi-product suite with more interface states to define. The time spent here is usually smaller than the cost of a mid-project revision caused by skipping it.
What happens if brand and product teams disagree on a design decision?
A shared brief should name who has final say before that disagreement happens, not after. Without that agreement upfront, a five-minute disagreement can stall a project for weeks while both sides wait for someone else to decide.
Is it too late to coordinate brand and UX if one workstream already shipped?
Coordination is still possible, though the fix looks different. Instead of joint discovery from scratch, the newer workstream needs a documented list of what already exists and where it constrains the work still ahead, reviewed jointly before final decisions get made.
Does this coordination matter as much for a small redesign as a full product rebuild?
It matters at any scale, but the cost of skipping it scales with the project. A small, narrow redesign can absorb a missed interaction state more easily than a full rebuild touching dozens of screens across web and mobile.
