Motion Path animates a layer along a vector path — you draw a line, select it with the thing you want to move, hit Apply, and get real, editable Figma Motion keyframes. As more people used it, the requests rolled in, and I said yes to most of them. Every yes made the plugin more capable. It also made the panel one section longer — until the day a new user opened it and simply froze. This is the story of fixing that without removing a single feature.
A small plugin that kept saying yes
Motion Path found an audience. Installs climbed, the Community page filled up, and — the good problem — the feature requests started arriving. Can it do motion blur? Anticipation? A colour shift along the path? Randomize a swarm? Connectors that follow the object? I shipped most of them, and the plugin genuinely got more powerful with each one.
But each new capability also arrived as another section in the panel. A tool that started as a tidy column of controls slowly became a tower of them. Nothing was wrong with any single control — every one had been asked for, and every one did something useful. The problem was what they added up to.
Powerful, and quietly overwhelming
On one object and one path, the panel rendered ~105 controls across 18 stacked sections — 14 of them effect sections, all expanded — in a single scroll nearly 3,000 pixels deep. I measured it from the shipped build; the screenshot below is that exact panel. Scroll it.
A returning power user knew where everything lived. A first-timer met a wall. They'd freeze, scroll, lose the thread — and, ironically, miss features entirely, because half of them sat two thousand pixels below the fold. The tool had grown a discoverability problem in the exact place it was trying to show off.
"It clearly does everything. I just can't tell where to start — or which of these I actually need."
— the theme underneath a lot of the feedback, paraphrasedThe complaint wasn't about any one control
Before touching the UI, I wanted to be sure I was solving the right thing — so I did the unglamorous work first.
Every comment and request, sorted
I went through the Community comments and the feature-request emails and tagged each one: bug, request, or confusion. The bugs and requests were scattered. The confusion clustered — almost all of it was some version of "too much at once," never "this specific control is wrong."
I counted my own panel
I opened the built UI as a stranger would and took inventory: 105 visible controls, 18 sections, 14 always-open effect blocks, 2,926 px of scroll on a single selection. Naming the number made the problem impossible to hand-wave.
What does a first-timer actually need?
I traced the shortest real path to a result: pick the object and the path, set a duration, press Apply. Four moves. Everything else — spin, trail, colour, squash, connectors — is optional depth, not part of the core loop.
Essential vs. on-demand
I sorted all 70 option fields and the dozen feature blocks into two piles: the handful nearly every animation touches, and the long tail you reach for occasionally. The split was cleaner than I expected — and it became the skeleton of the new layout.
The problem was never the controls. It was making a newcomer recall everything when they only needed to recognise a few.
Every control had earned its place. What hadn't earned its place was the decision to show all of them, flat, all the time. The fix wasn't subtraction — it was information architecture: surface the essentials, and let depth arrive on demand. An empty effects list should say "this is enough — a clean move is ready to apply." A library behind one button should say "…and here's everything else, the moment you want it." Same power, calmer door.
Designed in Claude, built in Claude Code
I wanted to feel the new flow before committing a line of plugin code. So I designed and prototyped the redesign as an interactive spec in Claude — a live, clickable Figma panel I could operate, flip between light and dark, and toggle before / after on. Alongside it I built a coverage map: an explicit table proving every one of the current panel's controls had a home in the new one. If the prototype felt wrong, I changed it in minutes, not in a build.
Then I imported that design into Claude Code and used its frontend AI to implement it against the actual plugin — the same React + TypeScript, the same real Figma tokens, no restyle. The prototype was the north star; Claude Code did the wiring, the parity checks and the light/dark passes.
Claude
An interactive prototype and coverage map to pressure-test the flow and prove nothing got dropped — before any plugin code changed.
Claude Code
Imported the design and implemented it in the real React/TS plugin, reusing existing components and the native token system.
Agent Skills
I followed Addy Osmani's agent-skills to keep the work disciplined: spec first, task breakdown, incremental implementation, review.
That last piece mattered more than I expected. Even though this is a Figma plugin, not a typical web app, the agent-skills steps mapped cleanly onto it. Spec-driven development gave me a written plan and a to-do list; planning and incremental implementation turned a scary rewrite into eight small, independently shippable phases — each behind a beta flag, each keeping the old layout intact as a side-by-side baseline. A standing parity check made it structurally impossible to drop a feature: the build fails if any of the 70 fields loses its home.
Setup → Essentials → Effects, on demand
Same plugin, same tokens, same features — reorganised into three plain sections and one library. The panel now opens at about 600 px instead of 3,000, and grows only when you ask it to.
Setup names the two roles (Object → Path) and the source. Essentials holds the three knobs almost everyone touches — duration, loop, easing. Effects starts empty, with a single Add effect button that opens a searchable, grouped library. The output tools — presets, copy-as-code, config JSON — moved into a titlebar ⋯ menu, where finished-work tools belong.
A first-timer's thirty seconds
The numbering here is the real order of a new user's journey — and the whole point of the redesign is that it stays this short whether they want a plain move or a confetti swarm.
Assign, then set a duration
Click the object and the line it should follow — the panel labels each role and offers a Swap if it guessed wrong. Duration, loop and easing sit right there, pre-set to sensible defaults. For a lot of animations, this is the whole job.
Add an effect — or don't
Happy with a clean move? Skip straight to Apply. Want spin, a trail, a colour shift, a swarm? One tap opens the library, grouped by what each effect does and searchable by name. Picking one drops it in as a card, expanded and ready — and the picker only ever offers what can apply to your selection.
Tune what you added, then Apply
Each effect is a compact card with a live summary — "3 copies · fading". Expand it to reveal exactly its controls, and nothing else. Remove it with one click. The primary Apply button was in view the whole time.
Calmer by default, complete on demand
Nothing was removed. A formal parity check proves every one of the 70 fields has exactly one home — zero missing, zero duplicated. Presets, round-trip editing and the 300+ examples all keep working, because the new UI renders the very same config. The Figma-native look — real tokens, Inter, control heights, full-bleed dividers, light and dark — is untouched.
What I'd tell another maker
If your plugin or app is growing, some of this will sound familiar. Four things I took away:
- Traction surfaces the IA debt. Ten controls in a column is fine. The same growth that proves people love your tool is what turns that column into a wall.
- Measure before you redesign. "It feels cluttered" is easy to argue with. "105 controls, 2,926 pixels, on the first selection" is not.
- Recognition over recall. Show the few things everyone needs; let the rest arrive on demand. An empty list is a feature — it says this is enough.
- Prototype the flow before the code. Designing the panel as a live artifact in Claude, then building it in Claude Code, meant the hard calls were made in minutes — and a parity check made "lose a feature" structurally impossible.