What problem do you actually have?
The question that settles the decision is not which to redesign but what is failing. Three different diagnoses lead to three different orders:
| Symptom | Real problem | What comes first |
|---|---|---|
| “We do not look serious” / the brand does not represent what we are | Identity | Brand |
| Traffic arrives but nobody gets in touch | Message, structure, or friction | Web (and leave the brand alone) |
| Every piece looks different | No system | A contained update, in parallel |
Why does the brand usually come first?
For an economic reason before an aesthetic one: the site is the largest application of the identity. If the identity changes afterwards, the site has to be rebuilt — not adjusted, rebuilt, because typography, palette, and tone affect every component.
The sequence brand → system → site avoids that double payment and also arrives at development with the visual decisions already made, which is where web projects get stuck.
When should you NOT touch the brand?
When the problem is conversion. A site that gets visits and generates no contacts almost always fails on three things: what you do is not clear in the first five seconds, the form asks for more than it needs, or there is no measurement showing where people drop off.
None of the three gets fixed with a new logo. A rebrand in that scenario changes what is visible, keeps the causes, and consumes the budget that would have solved the real problem.
What is a contained identity update?
It is the middle ground almost nobody proposes because it does not sell as well as a rebrand. It keeps the logo and the name and defines what is missing: a palette with clear roles, a type scale, a spacing system, and application rules.
It solves the real symptom most companies that are already selling have — “every piece looks different” — without the cost, the risk, and the paralysis of a full rebrand. And it leaves the ground ready for the site to be built on rules rather than on individual judgment.
Can they be done in parallel?
Yes, and it is usually most efficient when the identity update is contained. The condition is that the fundamental visual decisions — palette and typography — are closed before layout starts, not before the whole build.
What does not work is running them in parallel without that internal sequence: the web team makes provisional decisions, the brand team decides something else, and somebody ends up redoing the work. We chain the two because of that concrete dependency, not as a matter of process.