I expanded the LottieFiles for Figma plugin from a tool for finding and exporting assets into a creation tool for making motion, identifying issues, and handing work off to production. By making this evolution easy to understand and share, I helped drive the plugin’s growth.
Client
LottieFiles
Role
Product Designer
Period
2024–2026
Signal
650K → 1M users / 2.07 → 3.18 saves per user / ~20K monthly render failures → fewer than 50
2024–2026 · Product Designer
I designed the end-to-end plugin experience: successfully converting and saving Figma designs as Lottie motion, connecting new Lottie specifications with Figma, and creating cohesive paths into the dashboard, Lottie Creator, production environments, and the wider experience beyond the plugin.
650K → 1M · Figma plugin users, approximately 54% growth
More than 50% increase · Animations saved per plugin user
Across the plugin · Interactions, Motion Tokens, compatibility checks, and AI UX
~20K → fewer than 50 · Average monthly render failures
By 2024, Figma users were already expressing motion through multiple frames and prototype connections. But turning that work into animation that could run in a real product meant learning a separate motion tool and a keyframe-based way of working. The LottieFiles plugin was already loved by many users because it respected the frame-by-frame way Figma users worked and let them create animation without a separate learning curve. They could create motion from selected frames, preview it, and export it as Lottie.
Starting from a workflow familiar to Figma users did not erase the technical differences between Lottie and Figma prototypes. The hardest problem was translating the layer structure between frames into Lottie.
As users edit frames on the Figma canvas, they naturally duplicate several frames and keep building an animation, much as they would create a prototype flow. Along the way, they might add a layer to only one frame, add an entirely new frame to the flow, or freely use Figma features that Lottie does not support. But converting the work to Lottie required a consistent layer structure across frames. The plugin could not fully reconcile those disconnected frames. When it received a different structure or a value it could not recognize, it showed a failure screen instead of an animation. Given the plugin’s scale, this had become serious: from 2024 until the improvement shipped in December 2025, there were about 20,000 render failures per month on average.
I applied the principle behind the Feature Checker across the plugin: read the intent users had already expressed in Figma and connect it to the Lottie capability they needed. The Explore tab already let people find and use animations from the community, while Raster to Vector and Prompt to Vector were available as subtabs under Tools for users preparing their own graphics.
Because those tools were tucked away, many users passed by without knowing they existed. I wanted to reveal these AI capabilities contextually, without disrupting the reason someone had opened the plugin. For example, when a user selected an image layer in Figma, I surfaced Vectorize as a primary action. When the conditions were right, they could discover the value of Raster to Vector on the first screen and begin immediately. We also recognized that someone specifically looking for vector conversion had a different mental model from someone entering the existing LottieFiles plugin. We quickly launched AI Vectorizer as a separate plugin, creating a dedicated search presence and entry point for vector conversion while preserving the established motion workflow. As a result, we attracted more new users without cannibalizing the existing Figma plugin audience.
The moment Figma intent becomes Lottie
The design behind the same Export button can vary. A user might create motion across several frames, connect interactions in a prototype, or build reusable designs with variables and components. Rather than asking them to enter that working context again inside the plugin, I designed it to recognize what was already set up and connect them to the relevant capability. Frame-based motion led to Figma Motion, prototype interactions to State Machines, and values stored in variables to Motion Tokens and theme flows. Elements that could not be carried into Lottie appeared in the check results, with a direct path to the layer that needed editing. This helped users continue working with their own designs and live animation previews instead of navigating setup screens for unfamiliar technology.
Continuing the work beyond the plugin
I did not try to fit every editing and management capability inside the plugin. When users needed more precise motion editing than Figma could provide, the work continued in Lottie Creator. When they needed version management and CDN delivery for a saved animation, it continued in the web workspace.
The point was not to finish everything inside the plugin. It was to let people keep using a design that started in Figma in the tool suited to the depth and purpose of the work, without repeatedly explaining or rebuilding it.
Through these improvements, users can now convert designs made in Figma through the LottieFiles plugin into a form that can be used in production. The single plugin grew from 650,000 to one million users, an increase of approximately 54%. The number of Lottie animations saved per user rose from 2.07 to 3.18, more than 50% above the previous level.
I shared the situation with the team and asked two questions.
Could we make exports succeed more reliably?
If a failure was inevitable, could we at least explain it helpfully?
Our goal was not to hide these problems and render errors. It was to minimize unexplained failures and ultimately turn them into problems users could solve themselves.
To solve this properly, I wanted to know exactly when rendering failed. Through dozens of online and in-person community sessions and enterprise customer onboarding sessions, I collected recurring failure cases and defined and documented best practices. I reviewed the technology with the engineers on the team and documented the conditions to check, together with sample files. The checks and guidance covered not only layer structure but also Figma effects unsupported by the Lottie specification, such as inner shadows. Wherever partial rendering was possible instead of a complete failure, we kept that path open. I designed the checker to show the name of the problematic layer and select it when clicked, so users could move directly to what needed fixing instead of searching through the entire file.
Immediately after the release in December 2025, failures dropped sharply. Since then, the monthly average has remained below 50. This improvement includes the engineering team’s work to allow partial rendering and reclassify some former failures as detected unsupported elements with guidance. Instead of encountering an unsupported Lottie feature or layer mismatch they had not noticed as the extreme outcome of a “render failure,” users could now see it in a form they could understand and fix themselves.
