Animation handoff: how to make sure what you design is what the developers build

Nazli Kaya

Photo by Pankaj Patel on Unsplash

Recently, I’ve been creating some animations for the project I am currently working on. Before I started with the main work, I wanted to make sure that I knew what deliverables I would need to provide to the developers for the handoff.

While figuring things out, my findings eventually led me to change the way I create animations and I wanted to share what I came up with.

The gap between design and development

There have been a ton of new design tools emerging recently. It is now easier than ever to create great looking animations and transitions with all the details you could ever want. Personally, I’ve spent quite a bit of time to discover and learn these tools to make creating animations easier for me.

I would easily import my designs from Sketch, work with the timeline, animate different properties with different easings, move things around to come up with the best screen transitions etc. I was able to express my creativity and create the animation in my head using these applications. Which is what a design tool should allow you to do right?

Design tools are improving in a great pace

The problem

Everything goes fine until the moment where you need to actually handover the animation to the developers for them to recreate it in the product. These applications are great to come up with different animation ideas, yet the only option to export is usually just a gif or a video.

Sending a gif to a developer and expecting them to recreate the same animation with code is simply unrealistic. Most of my time spent working on an animation is with adjusting tiny timing issues or subtle movements to make the animation fit to the user experience. In the end, I am not designing an animated movie, it is all about subtle changes in the way the interface elements move.

These tiny things that I work on are basically not possible to tell by just looking at a gif. I haven’t seen anyone gifted with the ability to distinguish a 0.2s transition from a 0.1s transition. Yet, when you put everything together that 0.1s difference in the transition can make or break the overall feeling you are aiming for.

To overcome this issue, the obvious way is to document the transitions for every single layer you touch. It turns out, it is not as easy as it sounds. First of all there are many moving parts in most animations and it takes a ton of time to write everything down.

Making this animation would require animating only the outer panel with HTML/CSS, yet with most animation application you would need to animate both the inner and the outer boxes

The second and more problematic thing is that the layers you have in your Sketch file do not match with the HTML blocks the developers use. So even though you write that this particular box needs to move 10 pixels to the right in 0.4s with ease-out, that box doesn’t exist in the code. So it adds another layer of annoyance where the developer needs to adapt your design blocks to their code. And as with every manual process, this is very much error prone and solely depends on how clear you were able to describe the animation with the documentation and how carefully the developer applied what’s written there. So before the task is finished you would also need to go over the animation very carefully after the developer is done and maybe even check the code sometimes to make sure the transition timings and easings are correct.

The last point that got me annoyed was the process for modifying existing animations. It is a well known fact that design and product development is an iterative process, which means you will need to come back and make changes to those animations based on the feedback you receive. Personally I find it very difficult when I get back to an animation file from 3 months ago, yet that could be just me working in a messy way. Though, no matter how clean you keep your files, you cannot avoid re-documenting the animation after your changes. And with the manual process in place, you either need to capture every change you make or simply redo all the work you did initially to create the documentation.

As you can see this is a lot of effort and time required to make a very tiny animation or transition. So I’ve decided to take another approach.

Writing the code

To make this process less painful for me and the developers, I realized I needed to give up on some of the comforts I had. Which meant that I won’t be using my fancy WYSIWYG (what you see is what you get) animation programs where I can just import my existing designs anymore. Instead I decided that it is time to polish my rusty HTML, CSS, JS skills and start creating my animations with code.

Yes, I know there is a huge discussion with whether designers should code or not. And I even consider myself on the side that thinks designers shouldn’t code. At least you shouldn’t be coding the same thing you did the design for, as I believe the two require completely different mindsets and doing the two at the same time greatly reduces the quality in both sides.

That discussion aside, I actually don’t think creating your animations in an isolated environment is the same thing as coding the thing yourself. I’ve found it closer to learning a new animation program, compared to learning to write code. Writing production code requires many different things than just creating a single component and the animation for it in HTML/CSS.

It took me some time to getting used to it but after a couple of animations, things started to click. And you don’t even need to know too much about coding to create animations for developer handoff.

The benefits were simply amazing. Now, I actually had the control over the tiny details of the animation and for the developers, the task was much easier adapting my code to work with their existing code base. At least we spoke the same language now and resolving issues got much simpler. I would just put the CodePen link in the Jira ticket and the developers could easily investigate what I did and could even copy paste some parts of my code to make things easier.

Of course, there are also some downsides to this approach. First of all, now I need to recreate my designs with HTML before I begin animating. This actually turned out to be much easier than I expected, as I was only worried about a certain part of the product, where the animation took place. In addition, I could just copy the CSS code from Zeplin and that would only require minimum adjustments to make things look right. I was even able to replace some parts with simple image backgrounds to cut from my time to create the animations, if that part wasn’t moving at all with the animation. You can even go for more of a low fidelity replication of the design for the animation, as most details would not affect the animation you are creating. Another option would be to copy some code snippets from the actual product, yet for my case, I found it more difficult than creating it on my own, as our development team uses React and I usually use simple HTML/CSS.

CodePen makes it easy to have an isolated environment to code

Keeping the inspiration

Though I mostly start my animation tasks directly on CodePen nowadays, in some occasions I still use the design programs for exploring ideas. Depending on what you do, experimenting with different ideas can take longer time with code. So if I am not very clear about what kind of an animation I would like to have, I use the design applications as a sketchbook where I put together different ideas. And when I decide on which one to go for, I simply create the polished animation with code and handover easily to developers from there. This has simplified our lives a lot and the quality of animations we use in our product is now much higher.

Conclusion

I do not want to be misunderstood, I totally appreciate the amount of effort people put into these animation products and I believe as designers we feel at home using those, which helps us come up with better ideas and get inspired. Though, I believe the developer handoff features of these products are not there yet. I am aware of some effort in trying to generate code etc. but from my experience, developers are not comfortable maintaining a code snippet generated out of a design tool no matter how clean or “production ready” these claim to be. Every team use different technologies, have different coding conventions or have different understandings of how to structure things and thus I think it is very difficult to generate code snippets that developers would love to copy paste.

So personally until things get more advanced and the tooling improves to make developer handoff easier, I will continue creating my animations with code. I found it to be very effective and it also helped me understand some technical limitations that the developers face and most importantly it gave me the power of adjusting every tiny detail of an animation that is replicated exactly in the actual product.

I encourage you to give it a try, even if you have never written a single line of code before. Learning these things have gotten much easier with more resources than you would ever want these days. There is a ton of quality material out there for you to learn from. And you don’t even need to learn everything there is about HTML/CSS/JS, with the basics you can create most of your animations and for the rest, you can just learn as you go and as you need different things.

Let me know what you think and share how you overcome the issues that come with handing over animations to developers in the comments.

Author: Nazli Kaya

Collect by: uxfree.com

Top