Lottie Animation Handoff Checklist for Designers and Developers

1. Define the delivery package

Start with the agreement, then inspect the files against it. A delivered JSON file may satisfy a narrow export task while falling short of a project that also includes source artwork, state transitions and integration notes. The useful question is not “Did we receive a Lottie?” but “Did we receive the package we agreed to ship?”

Separate runtime files from editable production sources. The application consumes an export; a future designer may need the editable project and artwork. For an After Effects-based commission, an agreed source package might include an .aep file and its dependencies. A project authored in another tool requires different sources. Do not call a preview MP4 an editable source or assume that a JSON export preserves every aspect of the authoring workflow.

Choose JSON and/or .lottie based on the actual player. dotLottie packages animations and related resources in an archive format with a manifest; it is not just a renamed JSON file. The official specification is the reference for the selected version. A bundle can simplify packaging, but it does not replace compatibility tests or implementation instructions.

Ask for a short delivery note that distinguishes what is final, what is optional and what remains outside scope. If the client’s developer is implementing the component, the designer’s preview is a reference for that work, not proof that integration into the production application has already happened. This distinction prevents a normal development task from being mistaken for a missing animation deliverable.

2. Document playback and interaction states

Write behavior in product language before translating it into player calls. For a success state, the note might say: “When the application confirms completion, play once and hold the final frame.” For a loader, it might say: “Loop while the request is pending, then replace it with the confirmed result.” These instructions tell the developer which application event owns the animation.

Include what happens before the first frame is available. Should the interface show a static poster, a blank decorative area or ordinary text status? Also describe what happens when the user navigates away, repeats an action or changes their mind. An animation that looks correct in a continuous preview can still behave confusingly when real interactions interrupt it.

For lottie-web, options such as loop, autoplay, source and renderer are separately configurable. A handoff should state the intended values instead of relying on defaults. The official loading options also describe external asset paths and initial segments. When a delivery uses named segments or frame ranges, document how those ranges were defined for the chosen player.

Use a state table for interactive work. Name the trigger, the visual response and the next state. If a hover animation should reverse on exit, state that behavior. If a toggle has an on state and an off state, explain whether it uses separate files, segments or a different interaction system. Avoid calling every scripted interaction a state machine unless that accurately describes the delivery.

Review the connection icon as a motion reference and the interactive demos as behavior examples. Their role is to make a conversation concrete. A new project still needs its own mapping from product events to animation states and its own acceptance criteria.

3. Test the target runtime, not just the preview

Record the exact player, renderer and version used for acceptance. A successful authoring-tool preview or a working file in a public gallery does not test your application’s runtime. When the scope includes multiple platforms, list them separately and give each a meaningful pass condition. “Works on mobile” is not a substitute for naming the relevant application environment.

Compare the first frame, important intermediate frames and the final resting state with the approved reference. Check bounds, clipping, transparency and the appearance of text or raster elements. Then play the complete animation and inspect transitions and loops. A still-image comparison catches visual differences; a playback check catches timing and state problems.

Test the animation where it will appear, at representative sizes and on the intended backgrounds. A transparent export can look correct on the designer’s light preview and lose contrast on a dark product screen. A detailed illustration can become unreadable when reduced to an icon-sized slot. These are integration observations, not necessarily reasons to remake the whole composition.

Agree what file-size evidence means. Raw file bytes, compressed transfer size and runtime cost are different measurements. Record the file’s size and the conditions of any performance check rather than presenting one number as a universal speed guarantee. A small transfer can still require significant rendering work; a larger file may contain a simple playback task with an embedded asset. The performance guide provides the wider context.

For a practical review set, compare the wallet illustration with the more detailed AI files composition. They illustrate different visual scopes. The library’s file information is a useful starting point, but acceptance should use the actual files and runtime included in your delivery.

4. Record accessibility and loading behavior

Decide whether the motion is decorative or communicates essential product information. A decorative flourish can often be omitted from an assistive-technology reading sequence. A success or error message needs an understandable equivalent in the interface. Do not leave the only explanation of a failed action inside an animation that a user might not see or might choose not to play.

Specify a reduced-motion treatment. It could be a static final state, a simplified visual or a shorter transition, depending on the task. The prefers-reduced-motion media feature exposes a user preference; the product still needs to define an appropriate response. Merely detecting the preference is not the same as designing a useful alternative.

Consider controls separately. W3C’s Pause, Stop, Hide guidance addresses qualifying automatically moving content that lasts more than five seconds alongside other content. The exact requirement depends on the context and exceptions. A reduced-motion option alone should not be treated as a blanket substitute for reviewing that criterion.

The handoff should also describe loading and offscreen behavior. For a decorative animation below the fold, it may be appropriate to delay loading until it is relevant. When the animation leaves the viewport or the page becomes hidden, the integration can avoid unnecessary playback. Intersection Observer provides a way to observe intersection changes; it does not pause a player automatically. The implementation must connect the observation to the agreed behavior.

Test the failure path as well as the ideal path. If an asset cannot load, does the surrounding product remain usable? Is the next action still available? Can someone using a keyboard reach the relevant controls? Keep the answer in the acceptance record. Accessibility and graceful failure are easier to review when they are named deliverables, not assumptions attached to the word “optimized.”

5. Sign off a versioned delivery manifest

A delivery manifest is a small document that makes the package understandable without asking the original designer to explain every filename. It can be a table or a text file. The important part is that it identifies a specific approved version and the relationship between files, product states and test results.

Use the following as a starting template. These are example fields, not a claim that every project needs the same tooling or directory structure. Fill the runtime and test entries with actual values from the delivered project; do not label a check “passed” simply because the field exists.

Project / delivery version:
Approved by / approval date:
Runtime file(s) and intended state:
Editable source files included:
Required external assets and relative paths:
Player / renderer / version:
Target platforms and tested environments:
Dimensions / background / scaling rules:
Duration / frame rate / loop behavior:
Triggers, segments and interruption behavior:
Static and reduced-motion alternatives:
Loading / offscreen / error behavior:
File size and measurement conditions:
Known limitations or excluded platforms:
Third-party licenses and ownership notes:
Implementation owner and acceptance status:

Keep a change record when a revision replaces an earlier file. A simple entry such as “v2: adjusted final state and renamed the success segment” helps the developer avoid testing an outdated asset. Where the build system fingerprints files, retain a human-readable version in the manifest so the product owner can still identify what was approved.

Complete sign-off against the written scope. Creative approval confirms the intended look and timing; technical acceptance confirms the named integration requirements. Depending on the project, those decisions may belong to different people. Record both rather than treating one informal message as approval of every concern.

If the package reveals a new requirement, describe it explicitly. Adding a native platform, a new state or a different visual direction can change the scope. A clear handoff makes those changes discussable instead of hiding them inside a claim that the original delivery should work everywhere. See the animation process for the review sequence, or discuss a scoped project through web animation design services.

Frequently asked questions

Sources and related reading

• lottie-web: loadAnimation options
• Official dotLottie specification
• MDN: prefers-reduced-motion
• MDN: Intersection Observer API
• W3C: Pause, Stop, Hide
• Sergey Designer: dotLottie vs JSON
• Sergey Designer: Lottie performance best practices