Figma has always been more than a drawing tool—it’s been the place where teams align on design decisions, collaborate in real time, and increasingly, where prototypes start to feel like products. With its latest update, Figma is pushing that trajectory further by adding capabilities that look less like “nice-to-have” polish and more like infrastructure for a new kind of workflow: one where design files can carry meaning that’s closer to what developers actually ship.
The headline features—code layer support, motion support, shader support, and AI-powered custom plugins—might sound like separate upgrades. But taken together, they point to a single strategic direction: Figma is trying to become a more complete environment for building interactive experiences, not just static screens. And that matters, because the gap between design intent and production reality has never been purely visual. It’s behavioral, technical, and often surprisingly hard to translate.
Below is a deeper look at what these changes mean in practice, why they’re significant for teams, and how they could reshape day-to-day work for designers, prototypers, and developers.
A new “code layer” inside design files: bridging intent and implementation
For years, designers have lived with a translation problem. A design file can describe layout, typography, spacing, and component structure with impressive fidelity. But when the work moves into logic—conditions, data-driven behavior, dynamic states, or even just the need to express something precisely—design tools tend to fall back on approximations. Prototypes help, but prototypes are still a layer on top of design rather than a direct representation of code.
Figma’s new code layer support is best understood as an attempt to reduce that friction. Instead of treating code as something that only exists outside the design environment, Figma is introducing a way for code to live alongside design constructs. The practical impact is that teams can start to think about design artifacts as something closer to “executable structure,” even if the final runtime still happens elsewhere.
What does this unlock?
First, it improves continuity between design and engineering. When a design decision depends on logic—say, how a component behaves under different conditions—having a code-adjacent representation can make the handoff less interpretive. Developers spend less time reverse-engineering intent from screenshots or interaction notes, and designers spend less time guessing how their prototype will be implemented.
Second, it supports more consistent iteration. In many teams, the fastest path to progress is to prototype quickly, then refine once engineering confirms feasibility. But when the prototype is disconnected from the eventual implementation model, iteration becomes expensive. A code layer can act like a shared “source of truth” for certain behaviors, reducing the number of times teams have to re-align after the fact.
Third, it encourages a more modular mindset. Code layers naturally push designers toward thinking in terms of inputs, outputs, and reusable logic—concepts that map well to component-based development. That doesn’t mean every designer needs to write code. But it does mean the design file can become a more structured container for behavior, not just visuals.
The unique twist here is that Figma isn’t positioning this as “designers become developers.” It’s positioning it as “designers gain a better language for expressing technical intent.” That distinction is important, because it keeps the workflow accessible while still moving the platform forward.
Motion support: making interaction feel native, not bolted on
If code layers address the logic gap, motion support addresses the experiential gap. Static designs can be correct and still feel wrong once users interact with them. Motion is one of the most underestimated parts of product design because it’s where timing, hierarchy, and feedback converge. Yet historically, motion has often been treated as an afterthought—something added later by animation specialists or implemented by engineers with limited context.
By adding motion support, Figma is making it easier to incorporate animated behavior directly into the design process. This is not just about prettier prototypes. It’s about enabling designers to communicate how the interface should behave over time, including transitions, emphasis, and state changes.
In real teams, motion is where misunderstandings happen. Designers might specify easing curves, durations, or transition patterns, but those details can get lost in handoff. Engineers may implement motion differently due to constraints or interpretation. Even small differences in timing can affect perceived responsiveness and usability.
Motion support inside Figma helps because it makes motion part of the design artifact rather than a separate spec. When motion is represented more directly, teams can review it earlier, test it with stakeholders sooner, and iterate without waiting for implementation.
There’s also a broader implication: motion is a bridge between design and front-end realities. Modern UI frameworks increasingly treat motion as a first-class concern—whether through CSS animations, Web Animations API, or dedicated animation libraries. When designers can author motion more naturally in the same environment where they build components, the distance between “what we intended” and “what we built” shrinks.
And because motion is inherently tied to interaction, motion support pairs naturally with the platform’s move toward more technical expressiveness. If code layers help represent behavior, motion helps represent how that behavior feels.
Shaders support: expanding visual prototyping beyond the usual UI palette
Shaders are where things get interesting for designers who want to go beyond standard UI effects. In traditional product design workflows, visual effects are often constrained to what’s easy to implement: gradients, shadows, blurs, overlays, and a handful of common filters. Shaders open a different world—one where effects can be procedural, dynamic, and highly expressive.
By adding shader support, Figma is giving designers a way to prototype advanced visual treatments without immediately leaving the design environment. This can be especially valuable for teams working on immersive experiences, brand-forward interfaces, creative tools, or marketing pages where visual identity is meant to feel alive rather than merely polished.
Why shaders matter in a design tool:
1) They enable experimentation with “feel,” not just appearance. Shaders can create depth, texture, and movement that static effects can’t replicate. That means designers can explore brand expression in a more experiential way.
2) They reduce the dependency on specialized tooling. Historically, shader work often lives in specialized environments (like WebGL-focused tools or creative coding setups). When designers can preview shader-like effects within Figma, collaboration becomes easier. Engineers still own the final implementation, but designers can bring more accurate references to the table.
3) They encourage new kinds of prototypes. A prototype isn’t just about layout and interaction anymore. It can become a visual sandbox where teams test how effects respond to user input, time, or state.
Of course, shaders also introduce complexity. Not every team needs them, and not every effect will translate cleanly across platforms. But the value of shader support isn’t that every design will use shaders—it’s that Figma is acknowledging a growing segment of product design where advanced visuals are part of the mainstream workflow.
AI-powered custom plugins: turning Figma into a programmable assistant
The most “platform” change in this update is the ability to create custom plugins using AI for various tasks. Plugins have always been a way to extend Figma, but AI-powered plugin creation changes the equation. It lowers the barrier to building automation and specialized tools, which historically required engineering effort and deep knowledge of the plugin ecosystem.
With AI-assisted plugin creation, teams can potentially generate plugins for repetitive workflows, complex transformations, or consistency checks—things that currently consume designer time. Think about tasks like:
– Converting design tokens into structured styles
– Generating variants based on rules
– Applying consistent spacing or typography systems across large files
– Creating structured documentation from components
– Automating naming conventions and component organization
– Assisting with accessibility checks or contrast suggestions
– Building custom import/export pipelines for specific engineering stacks
The key shift is that AI doesn’t just “suggest” improvements inside Figma—it can help create the tools that perform those improvements. That means the platform can evolve faster than any single team’s internal scripts. Instead of waiting for a developer to build a one-off automation, designers and teams can prototype the automation themselves, iterating on the plugin until it fits their workflow.
There’s also a cultural impact. When automation becomes easier to create, teams can move from “we do this manually because it’s too hard to automate” to “we automate it because it’s now feasible.” Over time, that can change how design systems are maintained and how quickly teams can scale their output without sacrificing quality.
However, there’s an important nuance: AI-powered plugins are only as reliable as the underlying logic and the constraints you provide. For high-stakes tasks—like generating production-ready assets or enforcing strict design system rules—teams will still need validation. The best approach is to treat AI-generated plugins as starting points that require review, testing, and guardrails.
Still, the direction is clear: Figma is moving toward a future where the platform itself becomes more adaptable, and where automation is no longer limited to those who can build and maintain custom tooling from scratch.
What these features collectively signal: design-to-production is becoming more literal
It’s tempting to view each feature as a standalone improvement. But the deeper story is how they reinforce each other.
Code layers and motion support both relate to behavior. Shaders relate to advanced visual expression. AI-powered plugins relate to workflow scalability and customization. Together, they suggest Figma is aiming to reduce the distance between:
– Design intent (what the team wants)
– Design representation (how the design file expresses it)
– Implementation feasibility (how it maps to what developers can build)
– Iteration speed (how quickly teams can refine)
In other words, Figma is trying to make the design file a more complete artifact—one that can carry more of the “why” and “how,” not just the “what.”
This matters because the biggest cost in modern product development isn’t always the initial design. It’s the repeated alignment cycles: clarifying requirements, reconciling differences, updating specs, and reworking assets when assumptions change. When design files can express more technical intent and experiential detail