By following this guide you will produce a complete interaction design specification inside Figma — covering states, animation values, transition logic, and developer notes — in roughly two to three hours. The spec travels with your design file, eliminates back-and-forth with engineers, and ensures the micro-interactions you design are the ones that ship.

What You'll Build

  • A dedicated Interaction Spec page inside an existing Figma file that documents every animated state
  • Annotated component frames that capture easing curves, duration values, and trigger conditions
  • A reusable Spec Token table that maps motion values to design tokens developers can consume
  • A handoff-ready checklist that lets a developer self-verify implementation without a walkthrough call

Prerequisites

  • Figma Professional or Organisation plan (Figma as of 2026 requires a paid seat to use Advanced Prototyping and Dev Mode)
  • An existing component library or at least one interactive component to document
  • The Figma plugin: Handoff Notes (free, by Figmojis) and EightShapes Specs (free) installed
  • Basic familiarity with Figma Variables — if not, see your team's existing token setup
  • A development team using React, Flutter, or SwiftUI — the token format differs slightly per platform

Step 1: Audit Your Existing Animated Components

Before writing a single annotation, map what actually moves. Open your main design file and create a new page called Interaction Spec. On that page, add a simple text frame titled "Motion Inventory."

How do you decide what to document first?

Prioritise by user impact. List every component that changes visual state: buttons, modals, toasts, skeleton loaders, navigation drawers, and form validation messages. In most SMB product files, this list runs between eight and twenty components. Document high-traffic flows first — onboarding screens and checkout flows affect conversion directly.

For each component, note four things inline:

  • Trigger — what causes the animation (hover, tap, focus, scroll, data load)
  • Start state — the visual condition before the animation
  • End state — the visual condition after
  • Priority — P1 (blocks release) or P2 (enhancement)

Common pitfall: Designers often document only the happy path. Make sure you list error states, loading states, and empty states — these are the transitions developers most frequently implement incorrectly.

Step 2: Define Your Motion Token Table

A motion token table is a single source of truth for every timing and easing value in your product. Without it, developers hard-code values and your product ends up with eight slightly different animation durations.

What values belong in a motion token table?

Create a Figma table frame (use a simple auto-layout grid) with five columns: Token Name, Duration (ms), Easing Curve, CSS Value, and Use Case.

A minimal, production-ready motion token set looks like this:

/* Motion tokens — paste into your design system's tokens.css */
--motion-instant:     100ms ease-in-out;   /* state toggles, checkboxes */
--motion-quick:       200ms ease-out;      /* tooltips, dropdowns */
--motion-standard:    300ms cubic-bezier(0.4, 0, 0.2, 1); /* modals, drawers */
--motion-expressive:  500ms cubic-bezier(0.34, 1.56, 0.64, 1); /* onboarding, celebrations */
--motion-slow:        700ms ease-in-out;   /* page transitions, hero reveals */

These values align with the Material Design 3 motion guidelines (updated Q1 2026) and the Apple Human Interface Guidelines spring animation defaults. Using established curves reduces negotiation with developers because they recognise the values immediately.

In Figma, encode each duration as a Number Variable and each easing curve description as a String Variable. Group them under a motion/ variable collection so they appear alongside your colour and spacing tokens in Dev Mode.

Step 3: Build Annotated State Frames for Each Component

This is the core of the spec. For every component in your motion inventory, create a dedicated frame on the Interaction Spec page.

What should each annotated frame contain?

Structure each frame as a horizontal row of states. Left to right: Default → Interaction State → End State. Below each state, add an annotation label using the EightShapes Specs plugin. The annotation must include:

  • Token name (e.g. motion/standard)
  • Property being animated (opacity, transform, height, color)
  • Direction of change (e.g. opacity: 0 → 1)
  • Trigger condition (e.g. "on user tap")
  • Any delay (e.g. "200ms delay after parent mounts")

Between the Default and Interaction State frames, add a Figma arrow connector. Label the connector with the trigger and token. This arrow is what developers see first in Dev Mode — make it informative.

Pro tip: Use Figma's Prototype tab alongside the spec frame. Wire the actual prototype interaction to match the spec. When a developer opens the file in Dev Mode, they can preview the intended motion directly without needing a separate Principle or ProtoPie file. As of Figma's 2025 Dev Mode update, prototype previews are visible inside Dev Mode without leaving the browser.

Step 4: Document Conditional and Sequential Logic

Many interactions are not simple A-to-B transitions. A form might animate differently when validation fails than when it succeeds. A modal might have a staggered child animation. This logic must live in the spec — not in a Slack message.

How do you show conditional logic without writing code?

Use a simple flowchart notation inside Figma. Create a small connector diagram beneath the state row. Use diamond shapes (available as Figma shapes) for decision points and rectangles for states.

Example for a submit button:

  • User taps → Button enters Loading state (motion/standard, spinner fades in)
  • API returns success → Button enters Success state (motion/expressive, checkmark scale-in)
  • API returns error → Button returns to Default state (motion/quick, shake animation 8px left-right x2)

For sequential (staggered) animations, add a numbered overlay to each child element showing its delay offset. Example: card list where each item enters with a 60ms stagger. Label item 1 as "0ms delay," item 2 as "60ms delay," item 3 as "120ms delay." This is the most commonly mis-implemented pattern in handoffs — explicit stagger values eliminate guesswork entirely.

Step 5: Add the Developer Handoff Checklist

A spec that requires a meeting to explain has failed. Add a one-page handoff checklist at the top of your Interaction Spec page. Developers use this to self-verify their implementation before QA.

What belongs on the handoff checklist?

Format it as a Figma text frame with checkboxes (use Unicode ☐ characters — they copy cleanly into Jira or Linear). Include:

Interaction Spec — Developer Checklist

☐ All motion tokens imported from tokens.css (or tokens.json for React Native / Flutter)
☐ Each component matches the annotated start and end state visually
☐ Easing curves match the cubic-bezier values in the Motion Token Table
☐ Duration values are within ±10ms of the specified token value
☐ Reduced Motion: all animations respect prefers-reduced-motion (CSS) or AccessibilityFeatures.reduceMotion (Flutter)
☐ Stagger delays confirmed on real device — not just in browser simulation
☐ Error state animations tested with slow network (Chrome DevTools: Throttling → Slow 3G)
☐ No layout shift occurs during any transition (check with CLS measurement in Lighthouse)

The prefers-reduced-motion check is non-negotiable. As of WCAG 2.2 (the active standard in Australia, Canada, Singapore, and the US in 2026), motion that cannot be disabled is a Level AA failure. Include a note in your spec pointing developers to the MDN Web Docs: prefers-reduced-motion reference.

Step 6: Share the Spec and Set a Review Cadence

A spec only works if it stays current. Establish a lightweight maintenance process before you share the file.

How do you keep the spec from going stale?

Set three rules and document them at the top of the Interaction Spec page:

  1. Any new animated component requires a spec frame before the Figma file is handed to development. No exceptions.
  2. If a developer changes an animation value during implementation, they update the spec frame and tag the designer. This prevents the spec drifting from production.
  3. Motion tokens are reviewed every major release cycle. Token names should be versioned (motion/standard-v2) if a value changes after initial ship, so legacy screens are not silently broken.

Share the Figma file link with view permissions in your project management tool (Linear, Jira, or Notion). Pin it to the relevant sprint board. If your team uses Notion, embed the Figma frame directly — Notion renders live Figma embeds as of 2025.

At Lenka Studio, we include the interaction spec link in every design handoff package, alongside the component library and design token JSON export. Teams that receive all three artefacts together reduce their QA revision cycles by a significant margin compared to teams that receive only a prototype link.

Frequently Asked Questions

Do I need a paid Figma plan to follow this guide?

Yes. Dev Mode — which is where developers view annotations and motion specs — requires a Figma Professional or Organisation plan as of 2026. The Figma Starter plan does not include Dev Mode access for developers.

How is an interaction spec different from a prototype?

A prototype shows what an animation looks like. An interaction spec tells a developer exactly how to build it — with precise duration values, easing curves, trigger conditions, and token names. Prototypes alone are not buildable references; specs are.

What if my team uses a design system that already has motion tokens?

Reference your system's existing tokens in the Motion Token Table instead of creating new ones. Replace the CSS variable names in Step 2 with your system's naming convention (e.g. $animation-duration-fast in Salesforce Lightning or motion.duration.fast in IBM Carbon). The spec structure stays the same.

Can this workflow be used for mobile apps — React Native or Flutter?

Yes. For React Native, export motion tokens as a JSON file and consume them via your animation library (Reanimated 3 or Moti). For Flutter, map token values to AnimationController duration parameters and Curves constants. Add a platform-specific column to your Motion Token Table for each target platform.

How long does it take to spec a typical product screen?

A screen with four to six interactive components takes roughly thirty to sixty minutes to fully annotate once the Motion Token Table exists. The first time you build the token table and establish the spec page structure, budget an additional one to two hours. Total upfront investment for a ten-screen product is typically four to six hours.

Next Steps

Once your interaction spec is live, the natural next step is to validate that your motion choices actually improve usability — not just aesthetics. Run a quick usability test on your prototype (Figma's built-in usability testing share link works for basic sessions) and measure whether users notice state changes faster with the new animations.

If your product is part of a broader brand experience, it is worth checking how your motion language aligns with your overall brand identity. A misaligned animation style — expressive transitions on a brand that is meant to feel clinical and efficient, for example — undermines trust. Use the free brand health score assessment from Lenka Studio to surface gaps between your motion design choices and your wider brand positioning before you ship.

If you are working through a large design system migration or building an interaction spec for a complex product with many animated states, the Lenka Studio team is happy to help. We work with SMBs across Australia, Singapore, Canada, and the US to build design systems and handoff workflows that development teams actually use. Get in touch to talk through your project.