When it comes to the creation of a great website, how do you make sure both your website designers and developers are on the same page? Both are integral to the entire process and if not careful, a lack of communication or a knowledge gap can bring the process to a halt.
What is a designer to developer handover?
Simply put, it's something that takes place when a finished design (could be a web page, or an entire website), is ready to be passed to a development team to implement. However the handover happens though (more on this below), there are certain things that should happen throughout a project to ensure things go hassle-free.
First up: designer or developer - who's who?
Now it may seem obvious who's who - but clear responsibilities should be assigned to each side before the project starts. There are many debates out there as to whether one individual can take on the role of both designer and developer. We won't go into too much detail here, but in our experience - we find it better to be a master of one, than a jack of all trades. Having said that, we've also found HUGE benefits to each role having an understanding and appreciation for the other. For example, if a web designer has an understanding of responsive HTML and CSS, they can factor this in to their designs from the offset - avoiding a potentially unachievable interface.
![]()
Handover approach: what you should always include.
A handover from the design team to dev team can take on many forms. Whatever approach you take though, it should result in the dev team receiving all vital information around both the user interface (UI) and user experience (UX). The approach largely depends on 2 things: the amount of work and the complexity of the work. It may also vary depending on what tools you have available to you (we are huge fans of Adobe XD). Some things that should be included within every handover though:
A kick-off call or meeting for context.
Before a developer sees any visuals, always include an overview of the work that's been done, but more importantly, why it's been done. This will help the development team further relate to what they're doing and may help with decision making later on down the line.
Style guide.
Always include a style guide for the designs - a developer shouldn't have to spend time determining things like font-sizes and colours.
Tip: make sure your style guide includes commonly used HTML elements throughout the project (i.e. H1, H2, button styles etc). This will not only speed up the process for the development team, but also ensure more accuracy.
Assets.
Don't forget the assets that the dev team may need. Things such as:
- Header and footer logos
- Favicon
- OG images
- Font files
![]()
Throughout the design process:
Involve the dev team as early as possible.
When the project starts, you should have clearly identified the design and dev teams, and it's crucial that these teams are talking to each other throughout their own phases.
Sometimes a developer's insight into how something will be made could help the design stage massively. You don't want to let design and creativity completely take over, to then find you've created something that's a developers nightmare. You want to ensure that you're all on the same page with what can be achieved - both programatically and within the scope.
Include all viewports.
This may sound obvious in this day and age - but make sure each part of your interface is covered across all viewports. If not, it will likely result in the dev team coming back to the designer asking "how should this look on mobile?"
Document throughout.
For every part of the interface you're creating, think about the bigger picture. Is there an alternative state once the user interacts? Is there a hidden piece of functionality going on behind the scenes? These are all questions that a developer would (should!) be asking, so it's much more efficient if you've thought about these ahead of time. Make as many notes as you can, as you go along. Noting down UI / UX comments whilst it's fresh in your mind, is much more time efficient than waiting until the end of the design phase.
Tip: when commenting on part of an interface, include notes on the overall intention and potential scalability of that section. This again will help give the developer context.
Get client sign off!
You may question how this impacts a developer. But trust us when we say - developers don't like going back to redo something they've already done. And chances are - neither will your project manager or budget! It goes without saying that if something changes after development has been started, resource then has to be used to make that change. So make sure client sign-off is obtained before hand over.
Conclusion.
Whenever a developer receives a visual, they will inevitably have questions. The handover should look to answer as many of these questions as possible, so the dev team can spend time on developing, rather than fact finding. When the design and dev teams have a mutual appreciation for the other and collaborate throughout the project - the end result tends to be reached in a smoother fashion and includes the best of both.
