Ephemeral Design

Since 2024, I haven't seen a single Figma file that stayed up to date as a full replica of a product's UI. The only thing still carefully maintained is the design system. Every other design file gets opened when someone needs it and set aside when they're done.

At first I thought teams were just being lazy. Then I noticed almost every team works this way, and the ones that do haven't gotten worse. Many of them move faster. I started to think the design process was finding a better shape on its own.

I call this Ephemeral Design. Design files go back to being drafts and communication tools, the design system is the only asset worth maintaining long term, and designers and engineers work together around the code.

Two sources of truth

For a long time, teams treated it as best practice to maintain two high-fidelity versions of the product: one in Figma and one in code. Figma held the intent, what the product should look like. Code held the implementation, what the product actually looks like and how it works.

That made sense when code was expensive. Changing code was slow and costly, so you simulated everything in cheap design files before writing any. But the simulations kept getting more detailed. Designers started drawing every state, every response and every logic branch at pixel level, which amounts to building a parallel universe next to the code.

However high its fidelity, a design file is still a simulator. It has no real network latency, no messy real data, no browser rendering and no screen reader feedback. Users interact with the code, and only the code contains every detail of the system.

Keeping that parallel universe running is expensive. The most common cost is designers going back after a feature ships to update Figma so it matches the implementation. That work creates no value for users. Its only purpose is to make the design file still look like the truth.

High-fidelity mockups also hide implementation complexity. An input that looks simple in Figma may involve backend validation, error states and compatibility with legacy systems. A polished static mockup also suggests that every decision has already been made, so engineers hold back technical objections early, then have to raise them later, and the process gets messy. Both sides spend their time explaining details like "this shadow can't be rendered on Android" or "this data isn't available when the list first loads."

Drift is unavoidable too. Shopify's Polaris team spent a year pushing design system coverage in their admin to 86.6%. Later, when they shipped a product-wide visual update, about 86% of the admin changed automatically once they updated Polaris. The hard part was the remaining 14% of code that had drifted off Polaris (source). If a design system in the same codebase drifts that much, a separate replica in Figma has no chance of keeping up.

Design and engineering often end up in something like a cold war. Designers add Dev Mode annotations, variables and tokens in Figma to get more control over the implementation. Engineers, under pressure to ship, ignore that complexity and build something that looks close enough in code. When a bug shows up, people first argue about whether the design file or the code is wrong, and the broken user experience comes second.

Figma got heavy

The variables, modes and prototyping logic Figma has added in recent years were meant to close the gap between design and code. On many teams, the result was an over-engineered design system.

Designers are now expected to think like software architects, keeping dependency trees in their heads and managing variable mappings across scenarios. Their attention moves from the user experience to system maintenance, and a lot of their time goes into fixing broken variable bindings and conflicting component properties. They end up working like Figma admins.

This logic is also fragile. When you refactor code, the IDE, linting and tests have your back. In Figma, renaming a low-level variable can silently break hundreds of component connections across every team, with no error at all, until someone opens a file and finds the damage. Rolling back is much harder than in version-controlled code. So designers get more and more careful, and sometimes skip meaningful exploration just to avoid breaking the system.

If all this configuration turned straight into code, or clearly made the whole team faster, it might be worth it. But very few teams have built a pipeline that syncs Figma variables into code. The interactions, hover states and responsive breakpoints designers set up in Figma are mostly ignored at handoff. Engineers look at the final visuals and rebuild them their own way. A "smart" component a designer spent hours building loses all its internal logic at handoff. It becomes zombie logic: carefully built and never used.

Code got cheap

Meanwhile, AI is changing the cost structure of building products.

The old logic was that code is expensive and pixels are cheap, so you validate ideas thoroughly in mockups before writing expensive code. Componentization had already made code cheaper, and AI pushed it much further. A description or a rough sketch can become usable prototype code in minutes, and assembling a common screen from existing design system components takes almost no time. A prototype that used to take days now takes hours, sometimes less time than building a high-fidelity mockup in Figma with auto layout and variables. At that point, high-fidelity simulation in Figma is hard to justify.

Designers don't need to become programmers to benefit. With tools like Cursor, they describe the change they want, AI writes the code, and they open a PR. Adjusting spacing, tweaking an animation or fixing a visual bug no longer means filing a ticket and waiting. Designers on many great teams already work this way.

Handoff is fading too, especially on small, fast-moving teams. Engineers join during the design phase and use AI to build working prototypes quickly. Designers don't wait until development is done to do QA. They work in the development environment and take over a lot of the fine-tuning that used to belong to engineers. Design and development stop being upstream and downstream and happen at the same time, and you hear "the design can't be built" or "engineering got ahead of design" much less often.

Ephemeral Design

Put all of this together and you get what I described at the start. Designers maintain very few design files and a lean but accurate design system. Feature design happens in draft files that get set aside once they've done their job. Ephemeral means design files are process tools, not long-term assets.

There are three principles.

First, Figma is a whiteboard. In Figma, the focus is on exploring widely and working through the logic, using rough drafts to try several directions fast. Rough here means skipping the tedious work of building and maintaining structure. Visually, these drafts are often still polished.

Second, archive after launch. Once a feature moves into development, its design file is no longer worth maintaining. Archive it as a historical record. When the feature needs to change later, start from the live product, which is the code, instead of a mockup from months ago.

Third, a lightweight design system is the only asset worth maintaining long term. The only thing in Figma worth keeping up is a lean component library tightly aligned with code, so designers can assemble ideas quickly. Its real source lives in code, which is also why 86% of Shopify's admin could update automatically.

This approach doesn't suit every team. Right now it works best for teams that are strong on product logic, move fast and have a high bar for talent. Where visual expression is the product itself, like marketing sites, landing pages and brand experiences, fully letting go of traditional design files needs more experimentation.

Getting started

The teams that made this transition smoothly mostly did a few things.

First, they redefined what a draft is. They made it clear to stakeholders that Figma files are drafts and concept validation, not final contracts. At the end of each sprint, they marked the related design files as archived and stopped maintaining them. In decisions, they gave more weight to designers with taste and technical skills, and moved the team toward judging by results.

Next, they put the design system on a diet. If a component or piece of logic doesn't exist in code, it shouldn't exist in Figma, and the components, tokens and variants in Figma stay consistent with code.

Then they made designers comfortable in the code environment. They encouraged AI coding tools like Cursor, and treated touching code as neither overstepping nor an extra burden, just another tool in the toolbox. They also improved the developer experience so anyone could easily pull the code, run Storybook, open a PR and spin up a staging environment for testing.

Finally, they made code previews the new shared language. They used preview links from real code instead of, or alongside, Figma prototypes, so everyone got used to making decisions based on the real experience.

Design has always been about planning and solving problems. Maintaining full sets of high-fidelity mockups used to be a necessary way to reduce engineering risk. Now that code is fast and cheap, and Figma keeps getting more complex, the marginal value of that process is close to zero, and often negative. Once designers let go of the idea that the design file is the truth, they can give their time back to what matters: understanding users, and deciding what to build and what to cut.