Prepare for hand-off! How to nail that development support?
The Design hand-off can be one of the most critical and yet frustrating stages in the product development process. It’s that time when the long hours of research, designing, and iterating are over, and your design and high-fidelity prototype are ready for the engineers to implement. Sure, a big chunk of work is behind your back, but don’t get too excited yet!
Like any other process, the design workflow has its flaws. Designers can sometimes work in a bubble between the discovery phase and the development. Because of this, the context and intent behind the pixel-perfect mock-ups often stay vague for the development team when the design hand-off happens.
To make sure ideas and creative vision are translated accurately into a feature or product, it’s good for designers to collaborate closely with the cross-functional team throughout the project. Communication and collaboration with all team verticals are key to minimizing risk and mistakes. Every team member must be on the same page about what the feature or product should look, feel and work like. It’s easier said than done. The design hand-off is a partnership throughout the design process. It requires a lot of time, resources, and iterations to get it right in order to establish a culture of cross-functional collaboration within your team.
Now, let’s dive into some of the most common pitfalls during the designer-developer hand-off and review some strategies you could adopt to nail that development support through this phase.
It’s not a hand-off. It’s collaboration.
Hand-off is a tricky word. It implies one-way communication. It’s often misused as “getting rid of” in project teams, which in our case is critical because it connotates with stripping down of responsibility. The perception that when a design is handed over to a developer and now it’s their responsibility to bring the product to life is wrong. As designers, we need to invest in product development and ensure the context and design intent are not lost or misinterpreted after the handoff phase. Such neglect could result in a feature or product that doesn’t fully serve its intended purpose, which is every designer’s nightmare.
The best-case scenario is for design and engineering teams to work closely together and collaborate at every step of the development process. Sometimes this means frequent ideation meetings and an engineer sitting at the design desk providing guidance and feedback on design ideas. No matter what approach you pick, this two-sided collaboration will benefit both teams. Designers will better understand the product technicalities and evaluate which aspects of their design could be possibly implemented. On the other hand, the development teams will get an idea of what is in the works and what preparation will be needed in order for tasks to be executed properly.
Although design and engineering teams are different, they can be viewed as two sides of the same coin. Both departments share the same end goal: to create a product that serves the user as best as possible. In the end, the look and feel of a product are equally important as its functionality and performance.
Developing a product is a team sport. It requires the competence of all experts in the multidisciplinary team to bounce off ideas and move forward. The design-development collaboration goes both ways and should continue after the hand-off. The two departments need to understand the internal mechanics of one another, in order to establish a healthy working dynamic. After all, many heads work better than one.
Tips:
● Have Design Review meetings in the ideation phase. Decide with your team upon frequency. Usually 1–2 times a week is enough.
● Encourage idea sharing and open communication when collaborating with your fellow teammates.
● Decide on tools and software you and your teammates will use while collaborating. Everybody needs to be on the same page and feel comfortable with the tools they will work with.
● Have an open mind. Things might not always happen according to plan, and constraints await at the corner. Be ready to work with what you have and make the best out of it.
● Be ready to compromise — and I don’t mean it in a negative sense. In product development, every team member may have a valid point during a conversation so being protective of your ideas won’t do the product any good. In case of disagreement make sure you advocate for your users and make sure their experience is not being neglected.
● When it comes to the work and collaboration process — trial and error is the way to go. Try and experiment with different approaches and frameworks until you find what works best for you and your team.
● You can’t change things on your own — you need someone to help you.
What do engineers want to see? Deliverables that make sense
When it comes to deliverables and their presentation, a good practice to adopt is to think about your audience in advance. Think about who will be using the deliverables you are creating and what could be important for them. A common problem for designers is investing a lot of time and effort in deliverables that nobody in the cross-functional team uses. If you ask yourself “why” the most straightforward answer you would get is — because it’s not useful. How do you make it useful then?
Let’s take a step back and think about how a design hand-off meeting goes like. Usually, the designer presents the final version of the designs/prototype followed by an explanation of the overall vision, features, and design choices. After that, it’s the development team’s turn to ask clarifying questions and sometimes the questions turn into a whole list of uncertainties like:
● Where will this back button go?
● What happens if a user doesn’t have Admin rights? Will they be able to see this option?
● What happens if we introduce more menu options in the future? How can we accommodate that in the UI?
And then you have it, the key to useful design deliverables is covering the entire user/customer experience. But how do we make sure that the design covers everything? In all honesty, you probably won’t cover every use case out there, especially the edge ones, and that’s ok as long as you have the main flows figured out.
The development teams are analytical structures. They rely on information and facts and it’s crucial for them to have deliverables that leave not much to interpretation. In order for the design ideas and rationale behind the design deliverables to be clearly understood it needs to be specific and to the point.
End-to-End User Story
The first thing you need to figure out is the End-to-End User Story or Design Initiative. The End-to-End User Story is broader in scope than a development story in Jira which is often targeted at a specific feature or small task in the larger flow. It provides a view of the entire user experience by bringing light to use cases, edge cases, and step-by-step scenarios that specific user personas follow. This means that UX is included in the early product concept definition stage and ensures the feature/product in the works will enable users to achieve their goals.
Happy and Unhappy paths
Another thing that engineers are looking for is the Happy and Unhappy paths. It’s good to plan for this deliverable at the beginning of the project — as part of requirements gathering and IA phases. The Happy paths could be used as a checklist to see if all use cases are being covered in the design. Whereas the Unhappy paths help to develop your product’s error handling strategy by providing error states and alternative or recovery journeys. Don’t worry. This doesn’t mean you need to map every single error state in your designs. Just make sure you pinpoint the key paths that affect user task completion.
Assets and Components
Another important part of the design handoff is the assets and component specifications. This one could be easily managed nowadays by end-to-end design platforms like Figma. Allowing you to use one tool for both asset delivery, wireframing, and prototyping. Components and assets are easily managed, and engineers are able to download them directly from the design file/library. Don’t forget to list your component measurements, padding, sizes, states, and usage rules, so that the development team would have clear instructions on how to develop them. A useful plugin would be FigmaTokens. It can host your border radii, colors, spacing units, etc. and it can dynamically update your designs.
Prototypes and Animations
Last but not least don’t forget about the prototype and animations (if you have any). Prototypes are great when it comes to simulating how a feature or a product would behave once developed. And it’s a great way to test your assumptions and design hypotheses too. A good approach is to make your prototypes functionality-based by making a dynamic flow for each functionality. You can also provide some context about the users and their roles, assumptions, and scenarios. In that way, you’ll ensure you’ll cover all user use cases and you’ve answered most of the engineer’s questions in advance.
Tips:
● Try leaving nothing to interpretation — provide enough context and clear guidance tailored for your audience which is going to use the design deliverables.
● You can ask your team for feedback on deliverables and find out which deliverables would be most useful. Concentrate your effort in providing those.
● Be aware of your product. As a product designer, you sometimes need to wear multiple hats and juggle responsibilities. The more context you have for the cross-functional departments, the better and more informed decisions you can make.
● Have a checklist of design deliverables you need to provide to your team. Make some templates too. In that way, you can reuse and be consistent.
● Make a clear distinguishment between your ready for development designs and your work in progress. Putting some statuses and informative thumbnails in the design tool you’re using would do the trick.
Summary
Design hand-off is not just a one-time ceremony in the agile workflow. It’s a collaborative process. Good communication practices should be established between design and engineering to limit misunderstandings and mistakes. Even though the two teams are different, they have the same goal in common- and that’s having a working and meaningful product. Product goals are achieved through the collaborative effort of all team verticals. Remember, a working team is a working product.
To achieve that, engineers should be included in the design process, and designers should track the evolvement of their designs and assist the engineering teams with creating meaningful solutions to problems that may arise during development.
