A product you understand
before you even use it.

We look at what your users actually do, not what they say. We draw the screens in grey before talking about colour, so the discussion is about the journey. We test with five real people. We deliver files a developer can use without calling you back.

What you get: An approved site map, wireframes, mockups in all their states, a clickable prototype of the main journey, and the source files, which belong to you.

What you do not have to do: Choose between three visual directions without knowing what they imply, or settle visual details before the structure is decided.

Design is not a coat of paint applied at the end. It is the stage where you decide what the user sees, in what order, and what you ask them to do.

We work in Figma, from low-fidelity wireframes through to a reusable design system. The aim is not to produce attractive boards, it is to reduce the number of decisions left to make during the build, and to avoid costly back-and-forth once development has started.

On projects we deliver end to end, this stage is included. It can also be run on its own, for your own teams or for a technical supplier already in place.

In practice, this means we refuse to start with a visual direction. A mockup approved before anyone has settled what the user must do, in what order and with what information, produces an attractive screen that will have to be rewritten during the build. It is the most common way a project drifts, and it is paid for twice.

Design is also inseparable from the tool it will be built in: a mockup drawn without knowing what the platform can do generates rework. We have set those constraints out in our comparisons, in particular Framer or Webflow and Webflow or WordPress.

These three words are often used for one another, and that is the most frequent source of misunderstanding on a project. They do not serve the same moment or the same audience.

The wireframe is there to settle things, not to please

With no colour, no image and no chosen typeface, it shows one thing only: what is present on the screen and in what order. That is deliberate. A grey wireframe stops the discussion sliding towards taste, and forces the only useful question at that stage: does the user find what they are looking for, and do they know what to do next?

It is the least spectacular stage and the most profitable. Moving a block in a wireframe takes five minutes; moving it after the build takes a day.

The mockup is there to decide the execution

It fixes the typography, the colours, the spacing, the iconography and the tone. It is approved screen by screen, and above all in its states: an empty screen on first use, a screen full of data, a screen loading, a screen in error. Those states are the ones users meet most often and the ones people most systematically forget to draw.

The prototype is there to test, not to demonstrate

A clickable prototype lets you put a real user in front of a real sequence and watch them, without building anything. It is the only honest way to know whether a journey holds, because an approval meeting only ever measures the politeness of those present.

We build it short and targeted, on the journey that carries the stakes, rather than complete across the whole product. An exhaustive prototype costs as much as the build and serves less.

A design system is not a brand guide. A brand guide describes an identity; a design system describes reusable components, with their rules of use and their states.

What it actually contains

• Foundations: the type scale, the palette with its uses, the spacing grid, radii and shadows. These are decisions taken once, which then stop being rediscussed on every screen.
• Components: buttons, fields, cards, tables, messages, each in its normal, hovered, active, disabled and error states.
• Assembly rules: how those components combine, and above all what you are not allowed to do with them.

The gain, which is a gain of time and not of beauty

On a project of ten or so screens, it is not always worth it. From twenty screens, or as soon as several people are designing or building in parallel, it becomes the thing that prevents drift. Without it, every new screen reinvents its margins and its buttons, and the product becomes inconsistent without anyone having made a bad decision.

The second gain is less visible and often more important: it makes the product modifiable by people other than those who designed it. A design system that is kept up is what lets your internal team, or the next supplier, carry on without starting again.

What kills it

A design system dies in two ways. Too early, when it is built before anyone knows what the product needs, and it becomes a catalogue of unused components. Too rigid, when no exception is allowed for, and teams end up working around it in silence. So we deliver it deliberately incomplete, with an explicit rule for the cases it does not cover.

These two subjects are treated as constraints to be endured, to be settled at the end. Taken the other way round, they are two of the best design tools available.

Designing for the small screen first

A phone screen leaves no room for what is not necessary. Designing under that constraint forces real prioritisation, and the wide version comes out better because it was built on a hierarchy somebody committed to rather than on available space.

The opposite approach, drawing wide then shrinking, almost always produces mobile pages where everything has been stacked for want of a decision. It is immediately visible, and it is also what weighs on display speed, a subject we cover in detail on the SEO and performance page.

Accessibility, which does not concern a minority

In practice the accessibility rules come down to a few requirements everybody gains from: sufficient contrast, tap targets large enough, explicit labels rather than icons alone, a journey usable from the keyboard, and a text size that does not assume perfect eyesight.

Insufficient contrast does not only bother someone with poor sight; it also bothers the person reading your site in bright sunlight. An explicit label does not only serve screen readers; it serves everyone in a hurry. That is why we treat it as a general quality requirement and not as a box to tick.

What we check before delivering

• Every screen exists in a narrow version and a wide version, not only in a presentation version.
• The empty, loading and error states are drawn, because they will be built anyway, with or without a mockup.
• Contrast is measured, not eyeballed.
• Real text is used as early as possible: dummy text props up a mockup that will not hold with the real content.

Most design projects do not start from a blank page. A site or a tool already exists, it more or less works, and something is wrong without anyone knowing exactly what. The first mistake is to start redrawing straight away.

Start with the data, not with opinions

An existing product has an enormous advantage over a blank page: it has users, and therefore traces. Before proposing anything, we look at where people arrive, which path they actually take, at which screen they stop, and which forms they abandon halfway through.

What those traces show often contradicts internal intuition. Pages judged secondary sometimes receive most of the traffic; the button that was long debated is almost never clicked; and the abandonment happens one step before the one everybody suspected. Redrawing without that groundwork amounts to fixing a problem you have assumed.

Watch five people use what exists

The figures say where it breaks, they do not say why. For that you have to watch people, without helping them, giving them a real task and staying quiet. Five people are enough to bring out most of the blockages, and each session lasts under an hour.

It is the most uncomfortable exercise in the trade, for us as much as for you, because it shows live what was defended in a meeting. It is also the only one that settles disagreements without argument: when three people out of five cannot find the button, the discussion about its colour becomes moot.

Separate what is design from what is not

Some of the problems blamed on design are not design problems. A slow page is perceived as badly designed, when the remedy is technical and belongs to performance. A form that is too long is sometimes long because a downstream management tool requires those fields, and the real solution runs through CRM integration rather than the mockup. Confusing content stays confusing whatever the layout.

So we sort explicitly, and we say when the main problem is not ours. Selling a visual redesign to fix a speed problem would be easy and dishonest.

Redesign in stages rather than in one block

A total redesign launched at once has a structural flaw: if the indicators fall, you cannot tell which of the fifty changes caused it. When what exists receives traffic, we therefore prefer to move in batches, starting with the screens that carry the stakes, and measuring in between.

It looks slower and is in fact faster, because each batch informs the next. It also avoids the most painful situation in a redesign project: having to defend a new site you cannot prove is doing better than the old one.

What we deliver at the end of this phase

• A list of observed problems, ranked by what they cost and not by how visible they are.
• For each, the nature of the remedy: design, content, technical or organisational.
• An order of treatment, with what we do now and what we deliberately postpone.

A design quote is hard to compare, because the word “mockups” covers very different scopes. Here is our breakdown.

What is always included

• The framing workshops, which produce the structural decisions before the first screen.
• The site map and the wireframes, meaning the decisions that are expensive to change later.
• The mockups of the templates, in their states, and the clickable prototype of the main journey.
• The source files, which belong to you, and the documentation a developer needs.

What is costed separately, and why

Writing the content, because it depends on who takes it on and because it is almost always the critical path of the project. Bespoke photography and illustration, because a shoot on site has nothing to do with a stock library. Moderated user testing, because it involves recruitment and analysis time unrelated to the number of screens.

The number of templates, which is the real variable

It is not the number of pages that makes the price, it is the number of different models. Thirty pages built on five templates cost less than eight pages that are all different. It is the first question we ask when costing, and it is also the simplest lever for adjusting a budget without degrading the result.