Design Handoff Communication

Spec / redline vocabulary — "specs" (short for specifications) and "redlines" both refer to the precise measurements a designer provides so an engineer can implement a layout accurately without guessing.

• Spec — the general term for any documented design requirement (spacing, colour, typography, behaviour)
• Redline / red-lines — historically, literal red lines and numbers drawn over a design mockup showing exact pixel measurements (older term, from print/production design); today this is usually done via Figma's built-in Inspect panel rather than manually drawn lines
• Inspect mode / Dev Mode — the Figma interface that lets a developer click any layer and see its exact CSS-equivalent properties: padding, margin, colour hex/token, font size, border radius
• Design tokens export — many teams export their token values (spacing scale, colour palette) as a JSON or CSS variables file, so developers pull exact values from a single source of truth instead of eyeballing the design file

"Refer to the Inspect panel" is a signal that the designer trusts the tool's exact values over any written approximation — always check the live file rather than relying on a screenshot, which can misrepresent exact pixel values.

Interaction specification writing — a complete spec states the trigger, the exact resulting value, and the transition/animation parameters, leaving no room for developer guesswork.

Anatomy of "On hover, the background changes to `$color-surface-hover` with a 150ms ease transition":
• Trigger — "on hover" (could also be on focus, on click, on load)
• Exact target value — `$color-surface-hover`, a named design token, not a vague "slightly darker"
• Duration — 150ms (a specific number, not "quickly")
• Easing — "ease" (could also be `ease-in`, `ease-out`, `ease-in-out`, `linear`, or a custom cubic-bezier curve)

Animation vocabulary to use precisely in specs:
• Easing — the acceleration curve of an animation over time; "ease-out" starts fast and slows down, common for elements entering the screen; "ease-in" starts slow and speeds up, common for elements leaving
• Duration — how long the transition takes, typically 100-300ms for micro-interactions (hover, focus), 200-500ms for larger transitions (modal opening)
• Delay — a pause before the animation starts, e.g. for staggered list-item entrances
• `prefers-reduced-motion` — a CSS media feature/OS setting that signals the user wants minimal animation; specs should note "respect prefers-reduced-motion — skip or drastically shorten this transition for users with this setting enabled," since large motion can trigger discomfort or vestibular issues for some users

Designer-to-developer communication about deviations — an essential, precise phrase pattern for handling exceptions without accidentally corrupting the shared design system.

"The design deviates from the component library here because…" does three things:
1. Flags the deviation explicitly — so the engineer doesn't assume it's a bug in their implementation or silently "fix" it to match the standard component
2. States the reason — "needs a wider card to fit the chart legend" — giving the engineer context to judge whether the deviation is reasonable
3. Scopes the change — "treat it as a one-off, not a new variant" explicitly prevents the deviation from being misread as a request to add a new permanent variant to the shared component library, which would need its own governance/proposal process

Without this kind of explicit scoping language, deviations tend to cause one of two problems: engineers "fix" intentional exceptions back to the standard (losing needed context-specific adjustments), or engineers assume every deviation should become a new reusable variant (causing design system sprawl). Precise handoff communication prevents both failure modes.

Design tokens export — the practice of generating a structured, machine-readable file containing every design token value (colours, spacing, typography, radii, shadows) so it can be consumed directly by code, instead of a developer manually transcribing values from a design file (which is slow and error-prone).

Common export formats:
• JSON — a generic, tool-agnostic format (often following the W3C Design Tokens Community Group spec) that can be transformed into any platform's native format via tools like Style Dictionary
• CSS custom properties — e.g. --color-primary-500: #2563eb;, consumed directly in stylesheets
• iOS export — Swift constants or `.xcassets` colour sets
• Android export — XML resource files (`colors.xml`, `dimens.xml`) or Kotlin constants

Handoff notes referencing "the token export" signal that engineers should pull from this generated source of truth rather than hardcoding a value they read off the screen — this keeps design and code in sync automatically when a token value changes, since regenerating the export updates every platform at once.

`prefers-reduced-motion` in specs — a precise, inclusive way to write animation requirements that account for users who experience discomfort, dizziness, or distraction from motion (a documented accessibility need, not an edge case to skip).

The complete spec pattern:
1. Default behaviour — "200ms ease-out slide-in" for users without the preference set
2. Conditional override — explicitly describing what happens when `prefers-reduced-motion: reduce` is detected: skip the animation, or replace it with a much shorter/subtler alternative (a simple opacity fade rather than a spatial slide)

Why this matters as a handoff habit: leaving motion accessibility unspecified means engineers either implement nothing (missing an accessibility requirement) or implement an inconsistent, ad hoc solution per component. A design system should define this once at the token/pattern level ("all entrance animations respect prefers-reduced-motion") so individual specs can simply reference the rule rather than re-deriving it every time.

Note this is different from disabling animation for performance reasons — `prefers-reduced-motion` is a genuine accessibility/vestibular-disorder accommodation, set by the user in their OS settings, and should be respected as a deliberate user choice.

Liam isn't just noticing a difference; he's seeking to understand *why* that difference exists. He's prompting Maya to review the underlying design specifications (CSS variables) to ensure consistency and avoid future discrepancies. The goal is collaborative alignment, not simply stating an observation.

Ben's PR description demonstrates a good understanding of handoff communication. He explicitly links his work to the existing design system, explains *why* he made specific changes (the .highlight class), and provides context for reviewers to understand the impact of his code. This approach minimizes ambiguity and facilitates efficient feedback.

Chloe's message goes beyond just stating a preference. She's communicating specific design parameters – full-width image, transparent overlay, and the *reason* for these choices (immersive experience and brand alignment). David needs this information to accurately translate the design into code.

The JSON spec provides a precise definition of the modal's animation. Emily must ensure that the code implements the specified parameters (slide-in type and 0.3s duration). Discrepancies between the specification and the implementation will lead to inconsistent behavior and potential usability issues.

Animation performance is critical, especially on mobile. A long slide-in animation can significantly impact responsiveness and potentially freeze the UI on devices with limited processing power. Optimizing for performance is often prioritized over visual fidelity in these scenarios.