Look and layout

On Doctolib, every "Prendre rendez-vous" button looks the same, on thousands of pages. Nobody styled them one by one. The look comes from CSS, files of style rules that every page loads: "main buttons are blue, with rounded corners and white text", "headings use this font". A rule describes a kind of element, so it applies to all of them, on every page, including pages written next year.

So on a well-built site, the number of pages hardly matters when the look changes. Change the rule once and every page follows. What sets the cost of a change is how many times a value is written out. If a colour was typed by hand into hundreds of rules, someone has to find each one, change it and check every page, and the one they miss leaves an old colour on a new page. That's how a change that should take an hour gets quoted in days.

You can see the rules yourself. Right-click a button, choose Inspect, and the Styles panel lists every rule that applies to it, with the file each one comes from.

Developers avoid copies by naming the values. The site's colours, fonts and spacing are each defined once, under a name such as "brand colour" or "large spacing", and every rule uses the name. These named values are called design tokens. Changing the brand colour becomes one edit, and every button and banner follows, on every page.

Tokens make bigger changes cheap too. A dark mode is a second set of values for the same names, with dark backgrounds and light text. Nothing else on the pages changes. A good dark mode follows the setting visitors chose for their whole phone or computer, and remembers their choice if they switch it on the site.

Designers can use the same token names in their own tool, often Figma, so the mockups and the site speak the same language: that's the base of a design system. Any new colour needs one check before it goes live, its contrast with the background. Click a colour in the developer tools' Styles panel and it shows the ratio: aim for at least 4.5 to 1 for body text.

Open Vinted on a laptop and on a phone. The laptop shows the items in a wide grid, several across; the phone shows two columns, and the menu takes less room. Nobody built a second site. Both devices received the same HTML and CSS, and each browser laid the page out for its own screen, following rules the designers decided: below this width, use fewer columns and fold the menu away.

That's what a mockup can't show. It's a picture of one screen, usually a large one, with perfect content, while the real page is laid out again by every visitor's browser, from a small phone to a wide monitor. How it rearranges is a design decision, and if nobody makes it, phones get a shrunken desktop page or developers improvise. Since most visitors are on a phone, the usual method is "mobile first": design the phone version first, then add columns as the screen widens. CSS has layout tools made for this, which let blocks wrap, stack or change columns. The developer tools' device mode (Ctrl+Shift+M) previews any screen size.

A page also has to adapt to the person reading it. Many people, older readers especially, set a larger text size on their phone or zoom in. Sizes written relative to the reader's own text size (developers use a unit called rem) grow with it, and the layout makes room. Sizes fixed in pixels ignore the setting, or the text grows and spills over everything around it. Telling people they can zoom isn't a plan for small screens: they'd scroll sideways on every line.

Real content is messier than any mockup. A headline twice as long as planned, a word like "anticonstitutionnellement" on a narrow screen, an article without a photo, a portrait photo in a landscape frame: each one needs a rule, or it breaks the layout on the day it appears.

Some things a still picture can't show at all. When you move through a page with the Tab key, the current link should have a visible outline. Designers often remove it because it looks untidy, and keyboard users get lost. Text over a photo has to stay readable over the photo's lightest part. And visitors who asked their system for less motion should get a calmer page.

Ask these when a mockup or a quote arrives, before anyone signs.

Before approving a design, ask to see the phone version and how the page rearranges between phone and desktop. Ask what happens with real content, such as the longest title you publish or an article with no photo. Ask for the design as a system, with colours, fonts and spacing defined as tokens, and reusable blocks such as a card or a button, so the hundreds of pages to come follow the same rules. Ask what the keyboard outline will look like.

When a change is quoted, ask what it touches. A new colour on a site built with tokens costs one edit and some checking; if it costs days, ask why, and ask for the tokens to be set up as part of the work. If a developer says a change won't apply on some pages, ask what is overriding it. Forcing it with !important, an override that beats the usual rules, makes every later change harder.

Then test the first built pages yourself, on a real mid-range phone with the text size turned up.