I build a lot of motion for product interfaces and marketing sites, and one recurring challenge is keeping animations consistent across platforms. I want the little moments—the loading icons, the onboarding illustrations, the micro-interactions—to feel like they belong to the same design system whether they appear in a mobile app or on a marketing page. For me, Lottie + After Effects is the best combo for that job: it lets you design rich vector animations and ship them as lightweight, scalable JSON that works on web and native apps.

Why I choose Lottie + After Effects

There are a few reasons I keep returning to this stack:

  • Precision: After Effects gives you vector animation control I can’t get in code alone.
  • Scalability: Lottie renders vector shapes at any resolution, so the same asset can serve retina phones and large desktops.
  • Performance: Properly exported Lottie files are tiny and GPU-friendly compared to video or GIFs.
  • Cross-platform parity: With Lottie players for web, iOS, Android, and React Native, I can ship the same animation across products.

    • That said, getting consistent results takes intentional choices during design and export. Here’s the workflow I follow to avoid surprises.

    Design with constraints—set up a system in After Effects

    I treat each Lottie animation as a component in a design system. Before animating, I create an After Effects template that enforces the constraints my front-end will expect.

  • Artboard sizes: I create compositions for the primary aspect ratios I need (square 1:1, wide 16:9, and a mobile tall comp like 9:16). That helps me think responsively from the start.
  • Use vectors: I either import SVGs or use shapes in After Effects. Avoid raster layers unless absolutely necessary—Lottie’s strengths are with vectors and shape layers.
  • Limit unsupported features: Lottie (via Bodymovin exporter) doesn’t support everything AE can do. Avoid expressions that access external comps, 3D cameras (unless using experimental support), layer styles (like bevel), and certain effects. I keep a reference list of supported features from LottieFiles handy while working.
  • Animation primitives: Favor position, scale, rotation, opacity, trim paths, and path shape animations. These map reliably into the exported JSON.

    • Pro tip: make a “responsive bounds” guide layer in AE—an invisible shape that marks the safe area and maximum bounding box. It helps ensure the animation will lay out consistently when scaled by different players.

    Naming, structure, and modularity

    When you export many animations over time, messy layer names become a maintenance nightmare. I name groups and layers semantically (e.g., btn_primary_icon, spin_layer) and keep components modular. If multiple animations reuse the same illustration, I keep a separate comp for the illustration and nest it—so updates propagate cleanly across exported files.

    Exporting with Bodymovin / LottieFiles

    I use the Bodymovin plugin (or the LottieFiles plugin integrated into After Effects) to export. Here are the steps and settings I rely on:

  • Install the LottieFiles extension for AE (it bundles Bodymovin and provides a previewer).
  • Open the Bodymovin panel and pick the composition(s) you want to export.
  • Set the renderer to “SVG” (or “Canvas” selectively) — SVG is best for crisp vector scaling in most cases.
  • Enable “Include assets” for external images or fonts, or better: inline vectors and avoid images altogether.
  • Export and preview in the LottieFiles web preview to catch rendering differences before handing it to engineers.

    • Some After Effects features force the plugin to rasterize a layer into a PNG sequence, which defeats scalability and increases file size. If Bodymovin flags any layers as incompatible, I either rework the animation or accept a smaller rasterized section (and keep it minimal).

    Optimizing for file size and performance

    Performance is a core part of consistency—an animation that stutters on mobile looks different than on desktop. I optimize both visually and technically.

  • Reduce keyframes: use easing and hold keys rather than thousands of redundant frames. Keyframe-heavy animations bloat the JSON.
  • Simplify paths: complex paths with many anchor points inflate file size. I simplify SVGs and reduce point counts in shape layers.
  • Limit frame rate: 30fps is usually plenty for UI motion. Exporting at 60fps doubles complexity without much perceptible gain for many micro-interactions.
  • Split long animations into smaller segments: smaller files load faster and are easier to cache and reuse.
  • Compress JSON: some pipelines gzip or brotli assets on the server. But even before compression, keep the JSON lean by avoiding embedded raster assets.

    • Making animations responsive and device-aware

    The trick to consistent behavior across screens is separating visual scale from timing and constraints. I do this in two ways:

  • Design for constraints: ensure animations sit inside a bounding box and animate relative values (percentages) where possible. For example, animate shape trim paths or relative scales instead of absolute pixel shifts.
  • Control via player props: Lottie players accept props like speed, loop, autoplay, and rendererSettings with preserveAspectRatio. I use preserveAspectRatio='xMidYMid meet' for central scaling on web and tweak as needed on mobile.

    • For responsive UI components (e.g., a button with an animated icon), I export a logical-size Lottie and let the app scale the container. In React / web, I’ll render the Lottie inside an element styled with width: 100%; height: auto; and let CSS control its final size. That keeps the animation geometry consistent and avoids re-exporting for multiple breakpoints.

    Platform-specific issues and fixes

    Even with careful export, different Lottie runtimes can render slightly differently. I keep a checklist for each platform:

  • Web (lottie-web): preview in major browsers, check SVG vs Canvas renderer differences, and test on low-power devices. Use requestAnimationFrame-friendly integration (avoid heavy DOM updates alongside the animation).
  • iOS (Lottie-iOS): test in device simulator and minutes on actual devices. iOS handles text and fonts differently—embedding text as shapes in AE removes font dependency.
  • Android (Lottie-Android): older Android versions may have limitations. Keep animations simpler or provide fallback assets for legacy devices.

    • If I spot differences, I usually fix them by simplifying the offending effect or replacing it with a Lottie-friendly approach (for example, using shape path animation instead of a blobby filter effect).

    Accessibility, fallbacks, and progressive enhancement

    Animations should never break accessibility or performance budgets. I build fallbacks and make animations optional:

  • Respect prefers-reduced-motion: on the web, wrap your Lottie initialization with a check for window.matchMedia('(prefers-reduced-motion: reduce)').matches and either disable or replace animations with a static SVG.
  • Provide a static poster: include a PNG/SVG snapshot for very old environments, or as an initial paint while the Lottie loads.
  • Expose control: micro-interactions should be interruptible. If the animation runs on hover or focus, ensure keyboard users can trigger/skip it.

    • Versioning and maintenance

    I store Lottie JSONs in a versioned assets folder and keep a small manifest with metadata (source AE comp name, AE file version, exported date, primary colors, and usage notes). This makes it easy to update an animation across multiple products—find the JSON in the manifest, update the AE comp, export, and swap the files in a single PR.

    Tools that speed up my workflow

    Over time I’ve collected a set of tools that smooth the pipeline:

  • LottieFiles plugin for quick previews and hosting.
  • SVGO for optimizing SVGs before importing to AE.
  • Shape Layer Cleaner scripts in AE to reduce anchor points.
  • Design tokens in Figma/Sketch synced to AE via plugins or manual export—this keeps colors and spacing consistent across static and animated assets.

    • When everything clicks—clear constraints in AE, small and semantic JSON exports, and coordinated player settings—the same animation can feel identical in a native app and on a marketing site. That consistency is powerful: it reinforces brand identity, reduces cognitive load for users, and speeds up development because engineers don’t need multiple assets or complex rewrites.

    If you want, I can share a lightweight AE starter template I use for Lottie exports and a short checklist you can drop into your handoff docs for engineers. I’ve found those two small files remove a lot of friction when shipping animations at scale.