Website design — what gets settled here, before any code exists

Design is often treated as the layer that arrives last and concerns appearance. It is the most expensive misunderstanding in the whole project, because this is the stage where decisions get made that code can no longer undo cheaply — and they look like decisions about colour.

This section is not a guide to aesthetics. It is a switchboard: two texts, one for each question companies actually arrive with.

What this section settles

Three things, and not one of them is a matter of taste.

What is visible, and in what order. Which element comes first, what can be left out, where the first screen ends. These are business decisions made through graphic means, not the other way round.

What will not be there. The most uncomfortable part of design and the one least often said out loud: not everything fits, so somebody has to choose. If the designer does not choose it with you, chance will.

What you will be able to change yourself. A block designed to be editable and a block designed to be fixed look identical in a picture, and differ in cost for years afterwards.

The easiest way to see this is an example that recurs here regularly. A company asks us to "move the form higher up, because clients are not seeing it". On a sketch that is one rectangle dragged upwards. On a live site the same request means rebuilding a component, changing fields in the content management system, adjusting the data queries, refactoring styles, and testing that nothing next to it fell over. The request sounds identical in both cases. Only the invoice differs.

It is worth drawing the line to the neighbouring sections straight away, because in most proposals these three things arrive glued together. When each stage happens and what has to be delivered by then belongs to the process section. What it will all stand on — the system and the platform — belongs to the technology section. What sits here is only how the site should be built in terms of layout and behaviour.

Two questions, two texts

It is enough to recognise your own situation.

Somebody has shown you a design and you do not know what to judge on it. You get a file, you are expected to approve it, and the only tool that comes to mind is "I like it" or "I don't". The text offers something better: six principles from an international standard translated into risk and cost, ten usability heuristics turned into a checklist for the person paying, and the citation chain behind the circulating "9,400 per cent return on UX investment" followed all the way to its end — with an answer about where it actually comes from: UX and UI — what they are and how to judge them.

The site looks wrong or behaves badly on a phone. Before you commission a rebuild, it is worth checking how much mobile traffic you actually have — because the most repeated figure in this field does not hold for every market, and in some it points the wrong way. The text gives the measurement for six markets, shows why "three breakpoints cover 95 per cent of devices" is not true, and hands you three tests to run yourself: responsive web design — how much traffic really comes from phones.

And if both questions are yours? Start with the second. The reason is practical: the phone tests take a quarter of an hour and produce hard results, whereas judging a design needs an unhurried hour and is better done already knowing what does not work on the current site. On top of that, the traffic data can change the priority of the whole project — if it turns out most of your audience is sitting at a desk while the agency is proposing a mobile-first design, you have something to discuss before anything gets signed.

And if you do not have a site at all yet? Then this section is early. Start with the brief — without answers about the goal and the audience, every design will be guesswork, however handsome.

Three things settled earlier than you would think

This is the only substantive passage this page keeps, because it applies to both texts at once and it helps structure the conversation with whoever is building the site.

The sketch settles layout: the order of sections, how many steps lead to an action, what matters most. A change here costs a quarter of an hour. The same change in finished code costs us roughly thirty times more, and we set that sum out in the wireframe text.

The visual design settles the surface layer and — more importantly — the system: whether what emerges is a coherent set of components or five unrelated pictures. The first can be extended without a designer; the second needs one for every new page.

Code settles only what nobody settled earlier. And that is the worst possible place for such a decision, because it is then taken by a developer, on the basis of what seems sensible to them.

The practical conclusion: the more questions you ask while everything is still grey rectangles, the less you pay for the answers.

What is not in this section

Four topics sound like design and get settled elsewhere.

Order of work and deadlines. What happens after what, how long it takes, and what eats the time — the process section.

Conversion. This topic left this section, and it is worth saying why: design affects conversion, but so do copy, speed, the offer and the quality of the traffic. Keeping it here asserted that it belongs to one ingredient. It now sits in the marketing section, together with our own funnel and with the reason other people's case studies do not transfer.

Accessibility and WCAG. A separate field with its own legal requirements and its own text, not a subsection of design.

What it costs. What you are paying for inside a design job is described within both texts. The full implementation bill is in the cost section.

Start with three tests, not with reading

If you already have a site, a quarter of an hour with a phone in your hand will tell you more than both texts read end to end. All three tests are described in the text on the mobile version, and we ran all three on ourselves first.

The thumb zone — can the most important button be pressed one-handed, without shifting your grip?

Tables and wide content — does the table itself scroll, or does the whole page slide sideways?

Zoom — can you pinch to zoom in, or has somebody disabled it "so the layout does not break"?

Every negative result is something concrete to raise with whoever built the site, instead of a feeling that "something is off".