We at UX studio have a long history of working with developers during our projects, and fortunately, we get better and better at it every time. In fact, we now have our own developers and are opening up a Dev Studio so we can offer our clients complete service.
Below, you will find some of our most important conclusions when it comes to design handoffs. Keep these anchor points in mind, for designers and developers equally, as well as product team leads and other managers.
What does “design handoff” mean?
First of all, I must state that a “finished design” of a digital product does not exist. We can always do something more. So, in this article, “design handoff / handover” refers to the point when designers need to transfer their ideas for development.
Since design handoff refers to the end of a phase, the mistake of concentrating on only the best-practices about uploading, exporting and specifying designs comes easy (which I will mostly do).
Speaking the same language
The technicalities of the design handoff also matter, but however nice and neat the specification, it makes little difference if you haven’t actually talked to developers until the design handoff. Even if several dedicated people are standing ready to take over the mediator role, designers should find their way to the developers’ tables.
The preparation for the design handoff should begin at the very beginning of the entire process. (Read more about this approach in Intercom’s great article.) The checkpoint of designer-developer discussions should recur repeatedly, all of which using the right tools in your most preferred workflow makes easier.
From screen designs to screen-flow
Your screen designs serve not only as reference points to developers. Back in the bad old days, designers had difficulties exporting png’s for different members of their product team, organizing their assets and .psd files for dev, and the discussions and version control needed top organization.
Thank God for the relatively painless present! Zeplin (and similar solutions like Avocode) dramatically improved the entire designer-developer workflow. Upload your design, enter commit messages for version control, comment and discuss or simply use this feature to specify the details. It contains all the assets, made exportable. Could they make it handier?
You must have a basic prototype (in Invision, Marvel or Sketch, and links in Zeplin), but developers often request it to provide a static map of all the essential screens and their relations in a more didactic visual form. (Full disclosure: Zeplin does not pay us; we simply love the product <3)
Not only does the design handoff itself make it just useful, but it also reveals missing steps and edge cases, and forces designers to rethink illogical steps in the flow, etc. Win-win.
Start the discussion early in the sketching phase like we did on Stylelike. The point remains the same: Think it through, make it descriptive and start the discussion! The refined version will make a great checklist!
1. Edge cases and empty states
Consider their existence of empty states right from the beginning of the project so not to face unexpected questions long after the design handoff.
Edge cases include stuff like designing the longest German-language version of a label, but that doesn’t cover it all. Atypical use-cases might come up. Collecting edge cases in a spreadsheet and providing some written specification might help simplify things for developers.
2. Assets: Icons and pics
The need to design all the image assets manually and then hand them over to development used to cause designers pain. Zeplin solves the this problem very well: just group and slice layers correctly.
Exporting icons has never caused less hassle for developers, except for Android. Most designers use color masked icons (the most convenient way to recolor icons in Sketch to date) that Android Studio renders impossible to import.
The complex icon designs for the web also often comes up while handing over pixel-perfect design to developers. Designers, check out the icons you export from Zeplin in Illustrator: In some cases the layers get messed up, resulting in a bigger file size but also a distorted mutation of your icon design.
(Sketch seems to be busy working to solve these issues, but until then, just try simplifying the questionable icon in Illustrator and share it with the developers separately.)
We could view animating the user interface as the cherry on the top of the design, but we shouldn’t underestimate this phase of the design process. Animations and micro-interactions don’t only work as nice-to-have final touches personalizing our product. If done well, they also serve as descriptive additional features improving the user experience.
The animation handover proves slightly problematic since the frequently used tools (eg, the popular Principle) only provide visuals. For the developer to understand all the little, almost invisible things that happen in the animation (such as easing curves), we need either:
- a well-written specification and a long conversation with your frontend angel 👌
- a super good frontend angel who figures out each and every detail of your well-designed interaction 🙏
Since Airbnb launched the open-source Lottie animation tool, we have taken a few steps toward the perfect perfect design handover. Designers can work on animations in AfterEffects, then when exporting the .json file, developers don’t need to guess about any of the strings and timings used. Best of all, you can also test it before you hand it over.
We cannot cover animations and interactions without mentioning Framer. The challenging learning curve designers need to make because of coding will not only result in developers’ ultimate gratitude but it provides a great opportunity to put together complex prototyped flows (making usability tests and iterations way quicker).
To see an example, take a look at my first personal Framer experiment on a hobby project.
Consistency during design handoff
Consistency is the designer’s best friend, right? As well it should be. Building a style guide for developers and turning it into a design system will make your designer-developer collaboration way easier, and your product more consistent.
To repeat: find common points between designers and front-end people in this topic as well. Also, check out the platform-specific guidelines and exceed conventions with full awareness and reason :).
Among many aspects and principles, design system deals not only with the design elements but also handling naming conventions in all phases of the process, in both design and coding.
Don’t isolate design, or development!
In an ideal world, everything would come out of production as designers intend. In this scenario, we hand over the pixel-perfect design with a few sentences of goodbye, and tadaaa, the developers just put that into code without a word.
But don’t forget that this would also leave out the most creative and fun part of designer-developer collaboration.
The more you isolate the design process, the less of your design will go to production with accuracy. The above mentioned suggestions can bring the two closer.
So, we advise the following:
- Designers: Involve developers in the interaction design process.
- Developers: Get involved from the first moment.
- Product managers: Encourage designer-developer collaboration wholeheartedly.
To frame my train of thought, I’ll close advising what I started with: You cannot substitute collaboration (and thus communication) from the very beginning of the design process with simply improving the technicalities of the design handoff. Leverage the advantages of designer-developer teamwork!
Do you have any tips or tricks your team applies to make the design handoff even more fluid? Share it with us in the comments!
In need of UX design or development services? Reach out to us!
Want to read some more?
Also interested in Product Design processes? Check out our free e-book, the Product Manager’s Guide to UX Design.
For additional reading, check out our Product Design book by our CEO, David Pasztor. We ship worldwide – for free!