Without a solid understanding of how developers will build your designs, you can’t be sure they’ll be implemented properly. I’ve been a designer for over 12 years. I’m also a front developer who has built a lot of sites, but I’m not as good at coding as I am at designing. But in all that time I still make mistakes when handing off my work to developers. I thought it would be helpful to share some of the most common mistakes I’ve made and how you can avoid them as well.
Give developers a clear understanding of your design.
The goal of a good design is to communicate the information clearly and accurately. However, you can’t expect every developer out there to be an expert in design. The best way to give developers a clear understanding of your design is by creating simple, easy-to-read explanatory notes that are easy to understand and follow.
The most important thing to remember when designing for developers is that they’re not designers; they don’t always understand what makes an effective user experience or how to judge it. So instead of showing them your beautiful mockup, explain how you want the design laid out and what you want it to do — then let them figure out how they’re going to do it.
Before you send your design out, make sure you’re really clear on all the details. You should:
- Explain the purpose of this design to developers who may not be familiar with it.
- Show how it fits into the site or app as a whole.
- Explain what users need to do with it so they can accomplish their goals. (Remember, your job is to create user experiences that are intuitive and enjoyable.)
- Describe how well or poorly this design works in terms of performance (e.g., load time, speed of interaction). Make sure that everything works smoothly and quickly—this is especially important if users will be moving through several pages before they find what they’re looking for!
A good rule of thumb when working with developers is that if you don’t understand something they say or they don’t understand something you say, then it’s a good indication that further communication needs improvement. Before I hand off my design to developers, I make sure that I document the interactions so they know exactly what they’re building. If I fail to communicate clearly and effectively, the developer will not be able to do his/her job well. The best way to ensure a smooth transition is by being consistent in every conversation, using proper terminology and keeping it simple.
Let’s start with the basics. You are a human being, and your design interactions do not always come naturally to you. It’s easy to forget how you arrived at a certain conclusion or how exactly you made something work in Figma or Sketch (or whatever). The same is true for developers: they need an exact set of instructions so that they can replicate your designs exactly as they were intended by their creator. So what should you do? Write things down! If possible, record yourself on video (using screen recording software like QuickTime Player or Loom) while designing the interface and explain exactly what is happening in each step of your process. If this isn’t feasible for some reason, write out detailed instructions explaining each step—and keep these notes handy as well so that if anyone ever asks about them later on down the road (e.g., during QA testing), then everyone will be able to refer back to them easily without needing to spend time figuring out where everything came from originally.”
Next, make sure you know what is supposed to happen when someone interacts with the design. It’s easy to tell a developer how everything should look when a user loads up your shop on his or her mobile, but it’s not always obvious what should happen next (i.e., after they click something).
Document states, animations and interactions
States and animations are important because they can give users a sense that the design is alive. For example, if a button has an animation when it’s clicked, it should also have an animation when it’s hovered over by a user’s cursor. Similarly, if you’re using CSS animations or transitions, be sure to include them in your design documentation so developers know how they should work and when they should occur. Include screenshots of each transition so developers know what it should look like when finished. This can help developers better understand how you want your app to look, feel and function so they can create something that matches your vision.
Here’s some of the most common uses:
Describe the interactions: What happens when a user clicks a button? Does an animation occur? How do they interact with the product?
Describe the buttons: What text is on each of your buttons and call-to-action links? Do you have any conditional content (elements that change based on user input)?
Describe the animations: Does anything animate in or out of view as part of this interaction? Are there any animations triggered by other interactions (such as scrolling through content)?
Describe the transitions: How does one-page transition into another page? How does one section transition into another section within its own page? Do elements animate from one place to another or fade in and out like we see on websites today — or something else entirely!
Show interactivity (dropdowns/mobile navigation/popups)
Interactivity is a crucial part of making your website engaging and easy to use. However, it can be difficult to communicate interactivity to developers when you’re only looking at a wireframe.
It’s easy to get swept up, use a style guide
Style guides have been around for years, but they have become much more popular in recent times with the rise of flat design and Material Design. They help designers understand how to use elements like fonts, colors and spacing to achieve an overall look and feel for their website or app. They help you maintain consistency throughout your product. Consistency is important because it makes users feel at home on your platform and builds trust with them that they know where they are and what to expect next. This leads to higher engagement, lower bounce rates and ultimately more conversions for your business.
When you’re working on a project, it’s easy to get swept up in the creative process and lose sight of the bigger picture. A style guide helps you keep your eyes on the prize — or in this case, the big picture. For example, if you have an ecommerce website selling products in multiple categories, you may want to create separate style guidelines for each category so that it’s clear how each one should look and feel. The first step is figuring out what goes into your style guide. The goal is to create a document that includes all of the information needed for developers to implement each component of your app—from colors and fonts to button styles and animations. Your style guide should also include any custom components that you have created for this project (like new buttons or icons).
Handoff a style guide to a developer
It’s one thing to have a design that looks great, but it’s another thing entirely to have an interface that makes sense. When you hand off your style guide, you are making sure that the person who is building your site knows what kind of user experience you had in mind.
As a designer, you need to be able to handoff your style guide to a developer in order for them to build the site. This can be tricky because developers work differently than designers and may not understand what you mean by “subtle gradients” or “responsive design.”
Luckily, there are ways you can make this process easier for both. Here are some tips on making the process smooth:
1. Make sure it’s easy for developers to use and understand! Don’t expect them to read through your entire document; try creating an outline or table of contents so they can easily find what they need when they need it.
2. Start with an introduction that tells the developer what you were trying to achieve with this design and why it was important for them to know about it. Then go into detail about each element on the page and explain why you made certain decisions about colors, fonts, etc., so they can replicate those choices on their end.
3. Remember that there are going to be differences between how you wrote your style guide and how someone else will read it—so make sure that everything is clear! You might want to include screenshots if there’s something specific about an element that needs explaining. And don’t forget images! Screenshots are great for showing how elements look on screen; but having actual images will help developers
4. If at all possible, try not to use jargon or technical terms that might be confusing for non-designers (or designers who aren’t designers).
5. Be flexible! Don’t get upset if your developer doesn’t understand exactly how you imagined something would work—they may have their own ideas about how it should be done. Let them run with their ideas and see what happens!
6. And last:) don’t forget about accessibility—it’s important that all users can access and enjoy your website!
Organize and export all assets
Over the years, I have come to realise that it is important that I organize all of my assets before handing off the project to developers. This will make it easier for them to understand what they need to do with the design and how they need to do it. Organizing your assets will also allow you avoid any confusion on their part during development. You can use tools like Dropbox or Google Drive for this purpose. So they can easily access all of the images, fonts and other resources that you’ve used in the design. You can organize these files in any way that makes sense for your project: by layer or by page; in folders or subfolders; with or without Figma or Photoshop’s layers panel visible (or hidden). If there are any special instructions for how to use these assets (like naming conventions), make sure they’re included in your handoff too.
If you’re looking for a tool that will help you connect your designs with code, then Zeplin is a great choice. The team behind Zeplin has been working on it for years and they’ve got it down to a science.
“Your design is a living document. It will evolve over time, and you need to be able to keep track of that change.”
I hope you get a better understanding how to handoff your design project to a developer. We know that with all the work that goes into designing a website, it can be hard to let go at the end of a project. In the end, it’s all about communication. You can have the most beautiful design in the world, but if you don’t communicate it clearly and effectively, your developer may not be able to create what you want. To conclude, it’s important to remember that you are not designing for yourself. You’re designing for your users. If you work with a developer who knows their stuff, they’ll be able to work around whatever issues might arise. But it will always be easier if they know what they need to do before they start—and that means keeping them in the loop on all the little details along the way!
Thanks for reading! Hopefully you learned something new about the handoff process between designers and developers. If you have any questions, feel free to post them in the comments! I’d love to hear from you!