· 12 min read
Ephemeral Design
Design process in the AI era
Loading article…
· 12 min read
Design process in the AI era
Loading article…
For a long time, digital product teams have treated a particular workflow as "best practice": maintaining two highly detailed, mirror-image versions of the product as parallel sources of truth — one in Figma and one in code. But as designs become increasingly over-engineered (and expensive to maintain), and as AI expands what's possible in software development, this dual-truth model is frustrating designers and slowing teams down.
There's a way out of this tension. It's called Ephemeral Design. Design files return to what they fundamentally are: drafts and communication artifacts. The design system remains the only durable asset, while designers and engineers collaborate directly in a code-centered environment.
The principle of a single source of truth says that any piece of information should be owned and edited in only one place so the system stays consistent. But for years, digital product development has violated this principle by creating a dual-truth architecture:
This split made sense when engineering was expensive. Changing code used to be slow and costly, so teams simulated and validated everything in a cheaper design environment first. But over time, that structure became a burden. When designers model every state, every response, and every logic branch at pixel-level fidelity, they're essentially building a parallel universe.
And design files are, by nature, a flawed source of truth. No matter how polished they look, they're still a simulator. They don't account for network latency, data complexity, browser rendering behavior, or accessibility tooling. Code is what users actually interact with. It's the only artifact that contains the full reality of the system.
A recurring pain point across teams is the cost of forcing design files to mirror the real product. That cost shows up as communication overhead and alignment overhead, and it doesn't grow linearly — it grows exponentially as products get more complex.
In traditional product development, designers often go back after a feature is already built and update the Figma file to match the final implementation. That's busywork dressed up as documentation. It creates no user value. Its only purpose is to preserve the illusion that the design file is "the truth."
High-fidelity mockups often hide implementation complexity. A text input that looks simple in Figma may require backend validation, error handling, and compatibility work for legacy systems in code.
When designers hand off a fully polished static mock, it creates the impression that all decisions have already been made. Engineers hold back technical objections early, only to raise them later when implementation constraints surface. That creates confusion and disruption midstream.
Designers build a perfect utopia in a vacuum. Engineers wrestle with reality under constraints. Teams burn communication bandwidth on details like, "This shadow can't be rendered that way on Android," or "This data isn't available when the list first loads."
Even top-tier teams with mature design systems can't fully prevent design-code drift. One internal audit at Shopify found that even with a robust design system, 14% of implementations in a highly standardized admin interface had drifted from the system within a year.
That drift doesn't happen because engineers are careless. It happens because code is dynamic and environment-dependent, while design files are static and controlled. As long as design and code live separately, drift is inevitable; synchronization is only temporary.
On most teams, the collaboration model has started to resemble a quiet cold war between design and engineering.
Designers try to exert more control over implementation by introducing increasingly complex tooling in Figma — dev mode, variables, tokens. Engineers, under pressure to ship, often ignore that complexity and build something close enough in code.
This doesn't just increase friction — it blurs the definition of what the product actually is. When a bug appears, teams end up debating whether "the design file is wrong" or "the code is wrong," instead of focusing on the only thing that matters: the user experience is broken.
Figma's newer capabilities — tokens, variables, modes — have made component systems more complex and increased overhead across the design industry. This has become a recurring theme in industry conversations since 2024.
Figma introduced these capabilities with good intention: to close the gap between design and code, to make design files feel more like software systems. In practice, though, this often leads to over-engineering.
Designers are now expected to think more like software architects. Building and maintaining a deeply layered system requires strong abstraction skills. Designers have to mentally model dependency trees and manage variable mappings across multiple scenarios.
The result is that attention shifts away from user experience and toward system maintenance. Designers don't design as much anymore. They become Figma admins — spending time debugging broken variable bindings and conflicting component properties instead of improving user flows or shaping product vision.
Worse, the logic structures inside Figma are fragile.
In a codebase, refactors are supported by IDEs, linting, and tests. In Figma, renaming a low-level variable can silently break hundreds of component connections across teams with no automated warnings. You don't discover the damage until you open the file and realize everything is broken. Rolling back is far messier than it would be in a version-controlled code environment.
This fragility makes designers overly cautious. Some avoid meaningful exploration because they're afraid of breaking the system. The tool that was supposed to amplify their capabilities becomes a constraint.
If all of this complexity in Figma translated directly into code or dramatically improved team-wide productivity, it might be worth the investment. But it usually doesn't.
Very few organizations have a real automation pipeline that syncs Figma variables directly into the codebase, let alone anything more advanced.
So in practice, designers spend hours configuring interactions, hover states, responsive breakpoints, and other details in Figma, only for developers to ignore most of it during implementation. Engineers look at the final visual and rebuild the UI from scratch to something they consider good enough.
That creates massive waste on both sides. A designer spends 10 hours building an "intelligent" component in Figma, and all that internal logic dies at handoff. Zombie logic: painstakingly built, never used.
This happens everywhere. One team had over 300 components in their Figma library with carefully configured variants, responsive behaviors, and interaction states. The codebase had about 120 components. Nobody could account for the gap, and nobody was using the Figma-only ones.
The work required to maintain perfect replicas inside Figma just creates frustration and drains motivation over time. This is part of why so many designers are burning out or leaving the industry.
Beyond workflow friction, economics are pushing this shift too. Pricing changes in tools like Figma have triggered widespread frustration.
For a lot of teams, the cost of full-feature seats is getting harder to justify in terms of ROI. That forces a hard question: do we really need to maintain a large, complex "truth" in Figma where only designers live?
If the code repository — which the team already pays for and depends on — is the final source of truth, why are we investing so much budget and time in maintaining another one?
Psychologically, designers are hitting tool fatigue. Constant feature changes, plus the expectation that they now need to understand and design pseudo-programmatic logic, is leading to burnout. A lot of designers feel powerless to meaningfully improve the real product experience, and over time, they just check out.
The industry needs to get back to the two fundamentals of design: problem-solving and crafting.
AI is increasing engineering output fast, and it's changing the cost structure of product development.
In traditional software economics, code was expensive and pixels were cheap. So teams tried to validate ideas thoroughly in cheap pixels (design mocks) before writing expensive code.
But modern software engineering already lowered the cost of code through componentization, and now AI is pushing that even further by enabling teams to:
When a prototype that used to take three days can now be built in three hours — or even faster than creating a high-fidelity Figma mock with layers, auto layout, and variable setup — the economic case for high-fidelity simulation in Figma starts to collapse.
In this model, creators don't need to write every line of code manually. They describe functionality and interaction behavior in natural language, and AI handles the implementation.
This approach still has limits. It won't replace full product development or solve every complex problem. But for designers, it's a big deal: they can make simple changes directly, inspect the real product state, and experiment in a live environment, without needing to become traditional programmers or spending excessive time coordinating with engineering.
Some designers are already using tools like Cursor to adjust spacing, tweak animations, and fix visual bugs without filing a ticket. They describe the change they want, the AI writes the code, and they submit a PR. It's not theoretical — it's happening.
As AI accelerates software cycles and shortens development loops, the traditional design handoff process is starting to disappear. In its place, we're seeing tighter, more collaborative workflows between design and engineering, especially in fast-moving startups and small teams.
In this model, design and development are no longer sequential upstream/downstream phases. They become parallel co-creation:
This eliminates alignment overhead and ensures product decisions are validated in a real code environment early, avoiding the "the design can't be implemented" or "engineering shipped something before design caught up" situations.
All of this points in the same direction.
Designers maintain very few design files and a lean but accurate design system. Actual feature design happens through disposable draft files that support fast iteration. This is Ephemeral Design.
"Ephemeral" means design files are no longer permanent assets. They're process tools, not long-term records of truth.
The core principles:
Before rolling out a no-handoff workflow, teams need to be honest about where Ephemeral Design works best.
Right now, it's most effective for teams that are strong in product logic, move quickly, and have a high bar for talent. In contexts where visual expression is the product — marketing sites, landing pages, brand-heavy experiences — fully abandoning traditional design deliverables requires more experimentation.
Teams leading this transition are typically adopting the following changes:
1) Reshape the culture: redefine what a "draft" is
2) Put the design system on a diet
3) Encourage designers to embrace AI and the code environment
4) Make code previews the new shared language
The shift toward Ephemeral Design is more than a workflow change. It's a correction — one that reflects how modern product work actually happens.
The essence of design has always been planning and problem-solving, not producing polished specification documents that nobody maintains.
Maintaining high-fidelity mocks used to be a necessary way to reduce engineering risk. But as software engineering got faster and cheaper, and as the design complexity in Figma went up, the marginal value of the old process fell close to zero. In a lot of cases, it's gone negative.
Letting go of design as a source of truth isn't a loss. It means designers stop spending their weeks on pseudo-design work — updating files after the fact, debugging variable bindings, maintaining components that only exist in Figma — and start spending that time on the things that actually matter. Understanding users. Shaping product direction. Making hard calls about what to build and what to cut.
That's what design was always supposed to be.