Building Motion for the Web: Recipes for Design Success

By admin
Stealing Borrowing from Friends

At this point, we can assume that we’ve agreed to incorporate motion in the project. We may have determined what tier of motion we’re aiming for, but what does that process look like? How do we decide HOW something moves? What tools can we use for planning and communicating motion?

We can learn a lot from our friends in the animation industry; after all, they’ve been doing this for a long time! But we can’t just repeat what they’ve done and hope for success (unless we are, in fact, making an animated film). In the web industry, we have a few different challenges to face:

Form: The final medium for motion on the web (code) is wholly separate from its concept mediums (sketches, 2D renderings, video). Time: We measure project timelines in

weeks
DATE

and

months
DATE

, not years. Control: We’re not always in control of the flow—the user has input on where they go and what they want to see.

This leads to an additional set of goals when looking at creating our process for building motion on the web:

Form: We must, at some point, convert motion into code. Time: We need to be as efficient as possible to hit our deadlines. Control: We need to build systems and series of interactions rather than linear flows.

Why don’t we just start with code then? Well, we could… but that’s slow. Especially if we have to change direction. Solving our

1st
ORDINAL

problem (form) right away hurts our

2nd
ORDINAL

problem (time). We want to wait to convert to code until we have everyone’s buy-in on the motion concept.

So how do we get buy-in as quickly as we can? We do it by fine-tuning our motion design deliverables to target the minimum feasible fidelity for concept buy-in. Then we move to a tight feedback loop between designers and developers that allow for system-level integration of the project’s motion concepts.

We could sum it up like this:

Start as loose (low-fidelity) as feasible. Stop at the minimal level of

fidelity
ORG

needed to achieve buy-in with all stakeholders. Move into code as soon as we can.

And if you have a soft spot for diagrams, as we do, it might look like this: