# Redesigning Motion Path — From a Wall of Controls to a Calm Panel _July 26, 2026 · 7 min read · by Systergon_ > A design case study on rebuilding the Motion Path for Figma panel. Traction and feature requests had grown it into a ~3,000px scroll of ~105 controls that overwhelmed new users. Here is how research, an interactive Claude prototype and a phased Claude Code build turned it into a calm Setup → Essentials → Effects layout — without dropping a single one of its 70 fields. Tags: Figma, Plugin, UX, Case Study URL: https://systergon.com/blog/motion-path-figma-ui-redesign-case-study --- **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 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](https://github.com/addyosmani/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. [Install Motion Path — it's free →](https://www.figma.com/community/plugin/1654530170219655744) [See the product page](https://systergon.com/products/figma-plugins/motion-path)