Do you still need Figma designs before development?

The design phase used to be unarguable: you could not build a website without deciding what it looked like first, and deciding on canvas was cheaper than deciding in code. Both halves of that are now under pressure — tools generate working interfaces directly, and Figma itself is dissolving the boundary between design file and code. Here is where the mockup still earns its money, and where it is a line item you can honestly cut.

What the design file is actually for

A Figma file is not a picture of the website. It is a decision document — 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 see it once it is built" tends to cost more than it saves.

The economics are simple and hold up in practice: moving a section on canvas takes minutes, moving it in built code takes hours and can invalidate testing. The design phase exists to concentrate the expensive changes into the cheap part of the project.

What genuinely changed in 2026

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 design context straight into a developer's AI tooling instead of a screenshot, 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 and becomes a shared reference that stays accurate. Animation specs no longer get lost in a Slack thread; a token change in the design system does not require a translation meeting. It makes the design phase cheaper — not unnecessary.

When you can genuinely skip the mockups

Small, well-understood scope with an established pattern: 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 made when the template was chosen. In all of these, designing first duplicates work someone already did.

Also: 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. Paying for a polished design of something disposable is the actual waste.

When skipping it costs more than it saves

Multiple pages that need to feel like one site. Anything with a review chain — two stakeholders with different opinions will find them eventually, and finding them on canvas is much cheaper than finding them in staging. Custom interfaces without an obvious precedent: configurators, dashboards, multi-step flows, anything where interaction states outnumber screens.

And any project where the site is the main commercial channel. If the layout determines revenue, it deserves a round of deliberate thinking before it becomes a build — that is what a free UX audit or a scoped landing page design is for.

The middle path we usually recommend

Design the two or three hardest screens properly, define the system underneath them — type scale, spacing, colour, component states, breakpoints — and build the rest 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.

This is also what makes AI-assisted building actually work. Given real tokens and two reference screens, generated output is coherent; given a prompt and no system, it produces plausible screens that do not belong to the same website. The design system is the constraint that makes speed safe.

What to ask your agency

Ask what happens to the design file after launch — if it is abandoned, you paid for a deliverable rather than a system. Ask whether the design defines states and breakpoints or only desktop screens, because everything missing becomes a developer's guess. And ask what you can cut: a competent team should be able to tell you which parts of the design phase your specific project does not need.

The design has to survive translation

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 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. The cheap version of this is to lay out the tightest components with the longest locale in the box, or at minimum to paste the three worst strings in before sign-off. The expensive version is finding out on launch day for the second market.

Sources

Tooling changes and the translation-expansion figures referenced above, checked August 2026.

• Figma — Config 2026 recap ↗

  June 2026 launch: Figma Motion with Dev Mode animation export, expanded canvas design agent with MCP connectors and skills, and code layers previewed on the canvas.

• Figma — Introducing our Dev Mode MCP server ↗

  Feeds structured design context — variables, components, layout — into AI coding tools directly, rather than via screenshots.

• Nielsen Norman Group — Design Systems 101 ↗

  The distinction between a component library, a style guide and a design system, and why the shared, documented source of truth is what actually removes rework at handoff.

• W3C WAI — Understanding Success Criterion 1.4.3: Contrast (Minimum) ↗

  The 4.5:1 and 3:1 ratios a design file has to satisfy before development starts — one of the cheapest things to check in Figma and one of the most expensive to retrofit in code.

• W3C Internationalization — Text size in translation ↗

  Cited IBM guidance: source strings up to 10 characters can expand 200–300% in translation, 11–20 characters 180–200%, while passages over 70 characters settle near 130%.