The site went live. It worked. It just didn't look like the brand — and nobody caught it until it was already built.
It made sense at the time. The developer said design was included. The price was reasonable. The timeline was fast. You had seen their portfolio — the sites looked clean and professional. You said yes.
Weeks later, the developer presented a working site. All the pages were there. The buttons clicked. The forms submitted.
But something was wrong.
It didn't look like the brand. The layout felt like a template someone else had chosen. And when you compared it to what had been agreed — the gap was significant.
Now the revisions start. Everyone has an opinion. The developer is quoting additional hours. The launch date is slipping.
This happens to teams more often than it should. And it almost always comes from the same root cause: development started before design.
Web design and web development are not the same job
Development is building the website — code, database, forms, integrations. Making things function.
Design is deciding what the website should look like, how it should feel, and how a visitor moves through it — before a single line of code is written. Making things communicate.
When a developer says design is included, they usually mean they'll choose a theme, select fonts, and place the logo. That is template customisation. It is not UI/UX design.
Real design happens before the developer opens a code editor — not during the build.
Real UI/UX design happens in a tool like Figma — where every page is designed as a complete visual document, reviewed and approved, before the developer is briefed. Without that document, the developer makes design decisions in code. And decisions made in code are expensive to change.
Photo by Amélie Mourichon · Unsplash
But can't AI just build the website?
AI website tools are genuinely capable now. Tools like Framer AI and Relume can generate a clean, responsive website from a text prompt in minutes. The layouts are modern. The output is technically competent.
If all you need is a presentable website, they work.
But a presentable website and a brand-accurate website are not the same thing. AI generates from patterns — what good websites generally look like. It doesn't know what your specific brand needs to communicate, who your audience is, or what a visitor needs to feel the moment they land.
Without a brand strategy as input, AI produces a well-dressed stranger wearing your logo.
Feed AI your brand strategy — your positioning, visual identity, audience profile, tone of voice — and it becomes genuinely useful. It can accelerate layout exploration and speed up the early stages of design significantly. But the strategy has to exist first. AI amplifies what's already defined. It cannot define it.
A designer can only be as specific as the brand strategy they're given
This is where most website projects quietly break down — before design even starts.
A brand strategy is not a logo file and a colour palette. It is the working document that answers every question a design decision depends on: what does this brand stand for, who is the audience and what do they need to feel, what position does this business hold in its market, and how should the visual language reflect all of that.
Without it, a designer makes assumptions. They choose a layout based on what looks current, not what fits the brand. They select a typographic hierarchy based on aesthetics, not on how this specific audience reads and decides.
The brand strategy is the brief the designer works from. It is what separates a website that looks designed from a website that communicates with intention.
It is also what makes stakeholder sign-off a logical conversation instead of a matter of opinion — because every decision can be evaluated against a shared standard, not personal taste.
What gets built when design is skipped
A proper design process — done before development — covers what template customisation never touches:
- Brand application — your visual identity, colour palette, and tone applied to every page before the build starts
- User journey — every section leads the visitor toward a specific next step, designed around how your audience thinks and behaves
- Component design — buttons, navigation, forms, and cards designed consistently across the site
- Responsive layouts — desktop, tablet, and mobile designed before development, not retrofitted after
- Developer handoff — high-fidelity mockups, a component library, and clear specifications so the developer builds exactly what was designed
Skip this, and you get a website that works technically and misses the mark entirely. The decisions that should have been made before the build were made during it — by the wrong people, at the wrong time.
There is also an alignment problem that precedes the design problem. When multiple stakeholders are involved, each carries a different version of what the site should do and say. If those versions are never reconciled before design begins, they collide during the build. Every revision round becomes a negotiation about what the business is and who it's for.
The revisions aren't a design problem. They're an alignment problem wearing a design problem's clothes.
What this looked like in practice
The alignment problem doesn't always live between a client and a developer. Sometimes it lives inside the team.
A team came to Gazeable with a website project already in progress. They had been through multiple designers. The brand had a look — colours, fonts, a logo. What it didn't have was agreement. Every revision round sparked new feedback. Different people had different ideas about what the business was, who it was for, and what the website needed to say. No one could sign off.
The solution wasn't a better designer. It was a brand strategy session — with the whole team in the room. Not to talk about colours. To get aligned on what the business stood for, who the customer was, and what the site needed to make them feel.
Once that was clear, the design direction wasn't a matter of opinion anymore. It was a logical outcome of a shared decision. The website came together without the back-and-forth. The team launched proud — because they had agreed on what it meant before anyone touched a layout.
The brief didn't change. The team did. And when a team is aligned before design begins, the process stops being a negotiation.
What changes when design comes first
- The site reflects the brand. Every decision was made with the brand in mind from the start — not adapted to fit a theme after the fact.
- Development moves faster. The developer has a complete reference instead of making calls on the fly. Changes caught in Figma cost a fraction of what they cost in code.
- Revisions drop significantly. The design was approved before a single line of code was written. What goes live is what was agreed.
- The team launches confidently. What went live is what was decided together — not a surprise that arrived with the invoice.
The site that went live and the site you imagined are two different things.
Strategy first. Design second. Development last. That's what closes the gap.
Common questions
What's the difference between web design and web development?
Design decides what the site looks like and how it communicates — before code is written. Development builds it. Both are necessary. The order matters.
Why does my website look like a template even though I paid for custom design?
Because the design phase wasn't separated from the development phase. Custom design means every decision was made for your specific brand and audience, in a design tool, before the build started. If that didn't happen, what you received was a theme with your content applied.
Can't AI just generate the website?
AI tools can produce a presentable, responsive site quickly — and they're getting better. But without a brand strategy as input, the output will look competent and feel generic. AI is most powerful once your strategy is defined and documented. Without that foundation, it generates a well-dressed stranger in your logo.
How do we get stakeholders aligned before design starts?
A brand strategy session before design begins gets every decision-maker in the same room to agree on positioning, audience, and what the site needs to achieve. It replaces revision cycles with a shared brief that design can actually be built from.
Does designing first cost more?
At the front of the project, yes. Design takes time, and time costs money. But framing it as an added cost misses where the real money goes in a website project.
The expensive part of any website build is not the design. It is the rework — changes made in code after the design has been approved, or worse, after the site has gone live. A change that takes an hour in Figma takes significantly longer in a built website. Every revision round that happens after development starts is more expensive than the round that would have happened in the design file.
There is a principle in software development sometimes called the 1-10-100 rule: fixing a problem during design costs one unit of effort. Fixing the same problem during development costs ten. Fixing it after launch costs a hundred. The numbers vary by project, but the direction is always the same — the later you catch it, the more it costs.
A website that goes live without a proper design process does not just cost more to fix. It often costs more to replace. A full website rebuild — which is what teams frequently end up doing when the site never felt right — typically runs between $15,000 and $100,000 depending on complexity. That is a significant cost to carry for skipping a design process that would have been a fraction of that investment.
Designing first does not add cost to a website project. It moves the decisions — and the conversations — to the only phase where they are cheap to have.
This is what Gazeable does — strategy first, design in Figma, development from a complete approved blueprint. In that order, every time. Start with a free discovery call and leave knowing exactly what needs to happen before your developer opens a new file.
Start A Conversation →
