A Guide to Accomplishing an Efficient Developer Handoff
Handoffs shouldn’t be a single meeting.
The main reason that handoffs fail is because of bad communication between designers and developers. We detail how to improve communication in our last post. We explain that it is a good idea to involve developers early on in the design process to break down team barriers. So, we cannot stress enough that handoffs will not consist of a single instance. Instead, they will consist of multiple back-and-forths. In this new post, we share a few specific pointers you can follow to ease the handoff process.
Here at LoopStudio, we came up with these simple guidelines to improve our handoffs.
Agree on a single language
Keeping files organized is crucial for handoffs. A big part of this is naming every single thing designers make, such as frames, artboards, assets, components, etc. Sometimes we can get lazy and forget to keep records of these, making it very hard for developers to follow. It is convenient to collectively determine the style guide before writing the first line of code for further alignment.
Creating a glossary following specific guidelines to name components and assets can prove very beneficial. Not every developer will know what the designer means when they talk in design terms. The same goes the other way when developers talk about their code. Minimizing the language barrier between us can make the design-to-code process easier.
One of them could be the use of Semantic Naming. This consists of conveying meaning, by naming components such as colors, fonts, assets, and views, after their purpose instead of their appearance. Every visual component can be named semantically. This reinforces design and development consistency, therefore making everyone’s job easier and quicker.
Anyone should be able to read your asset’s name and know what it is instantly. Let’s say, for example, that you are working on a login screen and have different kinds of buttons. It’s much easier looking for the one that it’s named “login button” than guessing if the “red large button” is appropriate for said screen.
Be consistent on the casing, spacing, and the use of (_) or (-) in naming your components. This makes it easier to learn the glossary terms. For example, for naming buttons, you could always use lowercase (_) for spacing and (-) to define status: login_btn, login_btn-hover.
Animations
Regarding animations, there are two ways we can hand them off to developers. First and most reliable: prototyping. Our design team is familiar with Figma. Figma allows you to connect elements and choose your animations in the same file you are designing, in a fun and easy way. Subsequently, Invision or similar apps are not needed.
Show how elements should grow, bounce, and move as the user is interacting with them. The cons of prototyping are that it’s usually a long, arduous process and will consume a lot of valuable time. The other way we can do this is just by talking it through. You can specify in the documentation how things should work. Maybe even add references from other websites. Take your time as a designer to learn the usual standard animations. Having a sense of the system defaults that developers understand can prove to be much more efficient.
We are not saying you should learn how to code, but even having basic knowledge is a really valuable skill set. In our previous blog, we mentioned the importance of having developers early on in our process so they can have a deeper understanding of the design system. The same works the other way round. Knowing how to code can relieve some of the usual communication issues. For instance, if the project will be built on React, it would be worth looking up how its animations work. You can even come to like it and start working your way through code first when designing them.
Icon Padding
When we came up with the question “how could designers make developers’ jobs easier?”, we received all kinds of answers, but there was one thing that kept coming up: Icons. When you have a set of icons, they usually all have different proportions and sizes. When handing them off to developers, how they change in size according to the different viewports or windows isn’t the most obvious thing.
There’s a simple fixing that will help developers enormously that will help build consistency between them as well as helping with responsiveness: Icon padding. Icon padding consists of, as simple as it sounds, adding the same padding to each icon. We can achieve this by placing icons in frames. Each icon may differ in size, but the frame padding will be the same. This way, icon sets look cohesive. (e.g. in Figma).
Pixels to REM
Using EM and REM units gives us flexibility in our layouts and the ability to scale items up and down rather than being stuck at fixed sizes. We can use this flexibility to make our designs easier to adjust during development, be more responsive, and allow browser users to control the overall scale of sites for maximum readability. Zeplin can be a great tool for this. The other option is using a Figma plugin called: Hand››over, which automatically converts px to REM.
Because REM units refer to element sizing compared to the root element, they are best used for element size and spacing. On the other hand, EM units refer to when the computed pixel value is derived from the font size of the styled element while putting the inherited (parent and grandparent) values into consideration, so they are best used for media queries.
Closing thought
It is undeniable that having these items in consideration will influence the development team and make it easier for them to implement the design. This comes in handy for teamwork and results in less back and forth between teams. That being said, this blog is not the definitive guide for everyone. Even at Loop, we might not always address handoffs in the same way. They may sometimes vary depending on the client or each team.
Addressing the core of the situation and discussing between teammates about what makes their job easier might help find new paths to make a better development handoff, or even finding new ones that work best for both developers and designers.
If you want to know more about how we work at LoopStudio, please visit our Playbook or contact us to talk to our team!
Special thanks to Magdalena Invernizzi for her collaboration in this blog post.
