The design phase used to be unarguable. You could not build a website without deciding what it looked like first, and deciding on a canvas was cheaper than deciding in code.
Both halves of that are now under pressure. Tools generate working interfaces directly from a prompt, and Figma itself is dissolving the boundary between the design file and the codebase. So the question a client asks in the kickoff call — "do we actually need this step?" — is a fair one, and answering it with "yes, obviously" is no longer good enough.
The honest answer is that some projects should skip it entirely and some projects will pay three times over for skipping it. What separates them is not budget or ambition. It is how many decisions the project contains.
The file is not a picture of the website
This is the misunderstanding underneath most of the argument. A Figma file looks like a deliverable, so it gets priced and judged like one: here is a picture, here is the invoice, why is a picture this expensive.
It is a decision document. It is the place where layout, hierarchy, spacing, states, responsive behaviour and edge cases get settled while changing your mind is still nearly free. The visual output is a side effect of that process, which is why "we can just see it once it's built" tends to cost more than it saves.
The economics hold up in practice and they are not subtle. Moving a section on a canvas takes minutes. Moving it in built code takes hours, touches tests, and sometimes invalidates a round of QA that already passed. The design phase is not there to produce artwork. It is there to concentrate the expensive changes into the cheap part of the project.
Which means the real question is never "design or no design". It is: where do you want to be wrong?
What genuinely changed in 2026
Enough that the old defence of the design phase needs updating rather than repeating.
At Config 2026 in June, Figma shipped Motion with animation export in Dev Mode, expanded its canvas design agent with MCP connectors, and previewed code layers living on the design file itself. Combined with the Dev Mode MCP server, which feeds structured design context — variables, components, layout — straight into a developer's AI tooling instead of a screenshot and a guess, the handoff is measurably less lossy than it was two years ago.
The practical effect is that the file stops being a one-way deliverable thrown over a wall and becomes a shared reference that stays accurate. Animation specs no longer die in a Slack thread. A token change in the design system does not require a translation meeting.
Read that carefully, though, because the conclusion people jump to is the wrong one. Better handoff makes the design phase cheaper. It does not make it unnecessary. The tooling improved at transmitting decisions; it did not start making them.
When you can genuinely skip the mockups
I would rather say this plainly than pretend every project needs the full process, because the padded version of this step is a real thing and clients are right to be suspicious of it.
Skip it when the scope is small and the pattern is established. A single landing page following a layout that has already proven itself. A page built from an existing design system. A template-based build where the design decisions were effectively made at the moment the template was chosen. In all three, designing first duplicates work that someone has already done, and you are paying for the duplicate.
Skip it for internal tools, prototypes, and anything you intend to throw away. If the audience is three colleagues and the lifespan is a quarter, build it and iterate on the real thing. Paying for a polished design of something disposable is the actual waste in this industry, and it happens more often than skipping design does.
When skipping it costs more than it saves
Multiple pages that have to feel like one site. Coherence is not a per-page property, and it is the first thing to disappear when every screen is invented at build time.
Anything with a review chain. Two stakeholders with different opinions will find each other eventually, and finding each other on a canvas costs a comment thread while finding each other in staging costs a sprint. This is the one people underestimate most consistently, because the disagreement is invisible at kickoff.
Custom interfaces without an obvious precedent: configurators, dashboards, multi-step flows, anything where interaction states outnumber screens. If a page has one appearance you can build it and look at it. If it has eleven, you need somewhere cheap to see all eleven at once.
And any project where the site is the main commercial channel. If layout determines revenue, it deserves a round of deliberate thinking before it becomes a build.
The middle path, which is what most projects actually want
Design the two or three hardest screens properly. Define the system underneath them — type scale, spacing, colour, component states, breakpoints. Build everything else directly from that system.
You get the benefit of decided design without paying to draw every page, and the developer is never guessing what a hover state or an error message should look like. Nielsen Norman Group's distinction is worth internalising here: a component library is not a style guide is not a design system, and the thing that removes rework at handoff is specifically the documented, shared source of truth — not the pile of components.
This is also, and I think this is the underrated part, what makes AI-assisted building actually work. Given real tokens and two reference screens, generated output is coherent and genuinely fast. Given a prompt and no system, it produces plausible screens that do not belong to the same website — each one defensible alone, collectively obviously assembled. The design system is the constraint that makes the speed safe. Skipping design does not make AI generation faster; it makes its output unusable at the point where you try to combine it.
The constraint nobody designs for until it bites
If the site will ever ship in more than one language, the mockup you are approving is not the design. It is the shortest of three.
W3C's internationalization guidance, citing IBM's figures, is that a source string of ten characters or fewer can expand by 200–300% once translated, and one of eleven to twenty characters by 180–200%. Only long passages behave, settling around 130%. German is the usual culprit: "views" becomes "-mal angesehen", roughly 2.8 times the length.
That is a design constraint, not a translation problem, and it lands hardest exactly where designs are tightest — nav items, button labels, tabs, card headings, table columns. A label that fits the English artboard to the pixel will wrap onto a second line, clip, or shove its neighbour out of alignment in another locale, and it will do it after the templates are built and approved.
The cheap version of this is laying out the tightest components with the longest locale in the box, or at absolute minimum pasting the three worst strings in before sign-off. The expensive version is finding out on launch day for the second market, which is how a content job turns into a redesign.
Same category, same timing: WCAG's 4.5:1 and 3:1 contrast ratios are among the cheapest things to check while a design is still a file, and among the most expensive to retrofit once a brand palette is threaded through built components.
What to ask, if you are the one paying
Three questions, and the answers tell you more than the portfolio does.
Ask what happens to the design file after launch. If it is abandoned, you paid for a deliverable rather than a system, and the next change starts from zero.
Ask whether the design defines states and breakpoints or only desktop screens. Everything left undefined becomes a developer's guess, made at speed, under deadline, without you in the room.
And ask what you can cut. A competent team should be able to name the parts of the design phase your specific project does not need. If the answer is "all of it is essential" on a five-page site, that is information too.
Read the full version
This is the condensed version. The full article covers how much of a budget design should realistically be, what to do when an agency owns your design file, whether designing straight in the browser is a legitimate approach, and the rest of the questions clients actually ask before signing.
Do you still need Figma designs before development?
Sources
Tooling changes are from Figma directly — the Config 2026 recap and the Dev Mode MCP server announcement. The design-system distinction is Nielsen Norman Group's Design Systems 101. The expansion figures come from W3C's Text size in translation, and the contrast ratios from WCAG 2.2 Success Criterion 1.4.3. Where to draw the line is mine, from projects that went both ways.
If you have shipped something recently with no design phase at all, I would like to know what it cost you later — or whether it genuinely cost nothing, which does happen and is worth hearing about.
Top comments (0)