A client wanted an animated intro sequence on their homepage, logo pieces sliding in, tagline fading up. Normally we'd build that directly in the browser through trial and error with jQuery timing, but that means every timing tweak is a full reload, change a number, save, refresh, watch, repeat, which turns a simple animation into an afternoon of small iterations.
Why we brought in a different tool for this
Instead we roughed it out in After Effects first, using it purely as a storyboard, not for final export, since we still needed the actual result to be HTML, CSS and jQuery running in a browser, not a video file or an animated GIF sitting on top of the page. After Effects just happens to be a much faster environment for iterating on timing and easing than a code editor and a browser refresh cycle.
It let the client sign off on timing and easing in an afternoon instead of a week of round trips, and gave us exact frame counts to translate into millisecond delays once we moved it into actual HTML, CSS and jQuery. A twelve-frame delay at 24 frames per second is a known, exact number, five hundred milliseconds, rather than something we're eyeballing and adjusting live against a stakeholder's "a little faster, no wait, slower" feedback on a call.
Translating frames into code
The conversion itself is simple arithmetic once you have exact frame numbers, frame count divided by frame rate gives seconds, multiplied by a thousand gives milliseconds for a setTimeout or a CSS transition-delay. The harder part was matching easing curves, After Effects' easing controls are visual and continuous, while our CSS toolkit at this point is mostly linear transitions or jQuery's built-in easing functions, swing and linear, neither of which maps cleanly onto a custom bezier curve from a motion tool.
We ended up approximating rather than matching exactly, picking the closest built-in easing option and adjusting duration slightly until the client agreed it felt close enough. Not a perfect translation, but a reasonable middle ground given the tools available to us on the actual page.
What the client actually cared about
Interestingly, the client's actual sign-off criteria weren't about pixel-perfect timing matching some platonic ideal, they were about the intro feeling "snappy" rather than "sluggish," and about the tagline being readable before it started fading, rather than flashing past. Those are subjective, feel-based judgments that are much easier to iterate on quickly in a dedicated animation tool than in a browser where every adjustment costs a full page reload.
This changed how we think about client sign-off generally, getting agreement on the feel of something before investing in the exact implementation has saved us from building something technically correct that still needed reworking because it didn't feel right once seen in motion.
Where this approach falls down
It won't work for every project, and we're clear-eyed about the limits. For anything with more than two or three animated elements, prototyping the timing outside the browser first has been a real time saver, but for a genuinely simple single-element fade or slide, setting up an After Effects composition is more overhead than it's worth, we can iterate that directly in the browser about as fast.
It also adds a tool to the workflow that not everyone on a small team is equally comfortable with, After Effects has its own learning curve, and for a two-person shop that's a real cost, one of us spending time in a tool the other doesn't touch daily. We're treating it as a specialized tool for a specific kind of problem, complex multi-element homepage intros mostly, rather than a default step in every project.
A note on scope, and where this could have gone wrong
Storyboarding tools like this carry a temptation to over-invest in polish before any of it exists in code, since it's genuinely fun and fast to add "just one more detail" inside After Effects, a subtle bounce, an extra element, a secondary motion layer, when none of those changes cost anything close to what they'd cost once you're actually implementing them in the browser. We caught ourselves doing exactly this partway through, adding a small rotation to the logo mark that looked nice in the preview but that we knew, even as we were adding it, would take disproportionately longer to implement in CSS than it took to add in the storyboard.
We ended up cutting that detail before showing the client, specifically because we know from experience that a client who sees something in a preview tends to expect it in the final result, and we didn't want to either build something disproportionately fiddly to implement for a small visual flourish, or disappoint a client by cutting something they'd already approved. The lesson there is to storyboard with the actual implementation constraints in mind, not just what looks good in the tool you're prototyping in.
Getting comfortable enough with a new tool to use it well
Neither of us came into this project as an experienced After Effects user, most of our exposure had been watching motion designers work rather than driving the tool ourselves. We spent an evening beforehand working through a couple of short tutorials focused specifically on timing and keyframes, deliberately skipping the much larger universe of visual effects, particle systems, that After Effects supports but that has nothing to do with what we actually needed for a homepage intro.
That narrow, task-focused approach to learning a new tool, rather than trying to become broadly competent in it, meant we were productive with it inside a couple of hours rather than treating the learning curve as a multi-week investment. We'd recommend the same approach to anyone reaching for a new tool for a single, specific purpose, learn the narrow slice you actually need rather than the whole tool.
Whether this changes our estimating
One open question we haven't fully resolved is how to quote a project that includes this kind of storyboarding step. It's genuinely faster overall, since it prevents multiple rounds of expensive in-browser iteration, but it adds an explicit line item, and time, that wasn't previously visible in our estimates, since it used to be folded invisibly into "building the animation" as a single lump task. For now we're quoting it separately as a small, capped line item, "motion storyboard and sign-off," which has actually made clients more comfortable approving it, since they can see specifically what that time buys them rather than it being an invisible part of a larger animation estimate.
What we'd do differently next time
We'd export the After Effects timing as an actual reference document, a simple table of element, delay, duration, rather than relying on memory and eyeballing the composition again mid-build, which we did on this project and which cost us a few minutes of rewatching the same three-second animation over and over to re-extract numbers we should have written down the first time. Small process gap, easy fix, one we're already applying to the next project that calls for this approach.
Whether the client noticed any of this process
Worth saying plainly, none of the tooling detail above was visible to the client at all, and that's the point. What they experienced was a fast turnaround on approving something subjective, and a finished result that matched what they'd already agreed felt right. The After Effects step is entirely a production decision on our side, invisible in the deliverable, which is exactly the kind of process change we're most interested in making, ones that improve our own speed and confidence without asking the client to understand or care about the mechanism behind it. We'd rather spend an evening learning a new tool than spend a week justifying a slower process to someone who just wants their homepage to feel right when it loads, and honestly that's most of what good process discipline amounts to on a small team: invisible on the outside, and only worth the trouble if it actually buys speed or confidence somewhere behind the scenes. We're keeping a short internal note about which project types justify the extra step, so the next time this decision comes up neither of us has to re-derive the reasoning from scratch, which has already saved one slightly awkward internal disagreement about whether a smaller project warranted the overhead.