The Web Design Process, Step by Step
Web design is not the part where someone chooses colours. It is a sequence of decisions that narrows from "what is this site for" down to "this button, this size, this label", and each step is cheaper to change than the one after it.
This guide covers the stages in order, what each one produces, and the two points where design projects reliably stall.
Discovery: what the design has to achieve#
Before anything visual, the designer needs the same things a developer needs: the primary goal, the audience, the page structure and the constraints. If they start without those, you get a design that looks good in a portfolio and fails when the real content arrives.
This stage produces agreement, not artefacts. A one-page summary that both sides accept is enough.
- The one action the site must drive, and how it will be measured.
- Two or three visitor groups and the question each arrives with.
- Brand constraints that genuinely exist: logo, colours, typefaces, tone.
- Technical constraints: the CMS, the platform, the devices that actually matter.
- Examples of sites the client likes — and, more usefully, why.
Structure and wireframes#
Wireframes settle arrangement and hierarchy without the argument about colour. They answer what is on each template, in what order, and what the visitor is meant to do — while changes still cost minutes.
Wireframe the templates, not every page. Most sites have four to eight distinct templates and dozens of pages built from them.
| Template | Question it answers | Primary action |
|---|---|---|
| Homepage | What is this and is it for me? | Go to the right section |
| Section hub | What is in here? | Choose an item |
| Article / detail | The actual answer | Read, then take the next step |
| Product | Is this the right one and what does it cost? | Add to basket |
| Contact / form | How do I start? | Submit |
| Search results | Did you find it? | Open a result or refine |
Wireframe with realistic content lengths. A layout designed around a six-word headline breaks the moment a real one runs to fourteen.
Visual design and the design system#
Visual design applies the brand to the wireframes: type scale, colour, spacing, states and components. On anything larger than a brochure site it is worth producing a small system — a set of components with defined states — rather than a set of unrelated page pictures.
The reason is not tidiness. It is that a system tells the developer what happens in cases the mockups do not show, and those cases are most of the site.
- A type scale and spacing scale, so nothing is a one-off number.
- Colour tokens with contrast checked against their actual backgrounds.
- Component states: default, hover, focus, active, disabled, loading, error, empty.
- Responsive behaviour for each component, not just a mobile version of the homepage.
- What happens with too much content, and with none.
Where design projects stall#
Two failures account for most of the delay, and both are process problems rather than taste problems.
- Feedback without an owner. Six people comment, two of them contradict each other, and the designer is left to arbitrate. Name one person who consolidates feedback and makes the final call.
- Content that does not exist. Designs are approved against placeholder text, then the real copy arrives at twice the length and the layout is redone. Design with real content, even rough real content.
- Unlimited revision rounds. Agree the number up front — usually two or three — and what a further round costs. Without a limit, projects drift rather than finish.
- Sign-off that is not sign-off. "Looks good" in a meeting is not approval. Get it in writing, per template, with a date.
The most useful question in a review is not "do you like it" but "does this help the visitor do the thing we agreed the site is for". Taste arguments have no end; goal arguments do.
Frequently asked questions
How many design revision rounds should I expect?
Two or three is normal for a template-based project. What matters more than the number is that it is agreed in writing along with the cost of an extra round. Unlimited revisions sound generous and in practice mean the project never reaches a decision, because there is no forcing function for anyone to commit.
Should design and development be the same person or team?
On small projects one person doing both is efficient and avoids a handover. On larger ones they are genuinely different skills and separating them usually produces better work — provided the designer produces a system with states and responsive rules rather than a set of pictures. The handover is where the risk sits, not the split.
Do I need a full design before development starts?
You need the templates designed, not every page. Development can start once the design system and the two or three most complex templates are settled; the rest can be finished while the build runs. Starting development with nothing settled means rework, and finishing every last page before writing code means paying for idle time.
What deliverables should I get at the end?
Editable source files for every template and component, a stated type and colour scale, exported assets in the formats the build needs, and the responsive rules written down. Ask before you start whether you receive the source files or only exports — the difference matters the first time you need a small change without the original designer.
web design processwebsite design stepswireframesdesign systemwebsite mockupsweb design workflow
