← All resources

Do you still need Figma designs before development?

Design tools export code, AI generates screens from a sentence, and clients increasingly ask why they are paying for pictures of a website. Fair question.

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.

Sources

Tooling changes referenced above, checked July 2026.

Frequently asked questions

Want to know which parts of the design phase your project needs?

Send us the scope and we will tell you what to design, what to build directly, and what to skip.