How to better deliver a design project to your development team and avoid complications
Vinicius Ferreira Florencio
Designer de Produtos Digitais e Mentor de UI/UX @ ModalGR
In a fast-paced environment where we are constantly on the edge of multiple deadlines, we often tend to overlook one simple, yet extremely important, step of designing a digital product: delivering it to the team.
In most projects we are under so much pressure that at the end of it we just copy and paste the files to the team and that's it.
After some time we realize that many questions have been brought up by the development team or that the final design isn't quite like what we have previously built. And that is partially the designer's fault, after all we have rushed through a very important part of product designing, which is the handoff.
?? What is the 'handoff'?
In simple terms handoff (or handover) is defined by the Cambridge Dictionary as the act of 'giving control or responsibility of something to someone else'. In the context of design it refers to the process of documenting and presenting our designs to our stakeholders and development team.
As I said in the beginning of this article it is a really overlooked and sometimes forgotten step of a product's lifetime. And why is it?
There could be numerous reasons to why it happens, but most of the time one or more of the items below applies to the situation:
While these challenges make the whole process more difficult it doesn't have to be this way, after all we as designers have to be prepared to face those scenarios where we don't have much control over what is happening at all times. To make things easier there are some key elements we can include in our designing process that will help us navigate this turbulent sea, and all of them revolve around the same principle that drives the modern society: communication!
??? Communicate, communicate and communicate!
(and communicate a little bit more)
If you are to resolve any issues involving bad team coordination you have to improve your communication skills. I know it may sound a little cliché, but lack of communication is a real problem that many of us face every day.
To start, dealing with this problem might seem a little hard at first but with some patience and determination I can assure you that the problem will soften or, in the best case scenario, fade away completely.
?? Talking to your stakeholders:
To clear the first item in our list of bad things we can start by talking to our stakeholders and getting to know them better and their purpose with the project. Make a regular schedule to reach your main stakeholders - the most important ones, if not all of them.
After you have a clear image of what the stakeholders expect from your design you may take some time to build a persona around it. I guarantee that the outcome of your project will be more faithful to the team's expectations.
???????? Talking to your team:
Sometimes it is not entirely our fault though - some team leaders and managers can overlook the process as a whole if they themselves are overloaded and don't focus on the aspect of communication as well, resulting in bad team communication. To resolve this issue you can once again talk to your team with an open heart and tell them the importance of following ceremonies and providing feedback on everybody's workload.
If you are not already part of your team's ceremonies such as daily meetings, code reviews and plannings you have to get a way to be included as it is really important for you to get to know what is the current completion state of a project and how your designs are being translated in to code by the developers.
???? Talking to your manager:
Now, if your problem centers around your deadlines being unrealistic or you being overloaded you have to inform your manager as soon as possible. Don't wait until the last minute! By the time you receive a new project with an impossible deadline you have to explain why this is and try to negotiate a new target date.
If by doing this you are unsuccessful on getting a new date you can ask for an extra couple of hands to help you in your design process, ask to prioritize this project over another or even explain what will be the outcome of the project or the impact it will have on the others if the deadline can't be postponed, after all we are not machines. By the end of the project if the results are not satisfactory you can say: I warned you (just kidding, don't say that ??).
When a scenario like this happens you can encourage your manager to take note of what happened and try to be more reasonable with your work process in future projects so that it doesn't happen again.
?? Building our handoff
Ok now that you have successfully cleared your way of any problems (at least I hope you did) you can move on to the most exciting part of the job which is building the handoff itself.
So, where and when do you start then? The answer is quite simple: from the beginning! Yeah, you didn't read it wrong, you can start your handoff process and documentation from the very beginning of your projects. Of course you can leave it to the end but I strongly recommend not to do so.
领英推荐
Starting your handoff process at the beginning of a project can save you many hours in the end, when you are closer to reaching your deadline and, when you design a new component, screen or template and immediately start writing everything you need to translate your thoughts to the development team you are actively thinking about the usability of your design and the persona it is meant to serve. It truly is the best of both worlds! (Hannah Montana mentioned successfully).
Of course it is not as simple as it seems though: building multiple handoff pages for every component in our design can be a tough task, especially when we are working alone.
To deliver our handoffs with more agility we can use some Figma tools to help us with our burden:
?? Redlines & Annotations
It is by far my favorite plugin to build handoffs on Figma.
With it I can easily create redlines, annotations, flowcharts, connectors and margins, paddings and gaps markings only by selecting the frame I want to handoff and pressing my left mouse button 3 times!
For example I've done these simple markings and measurements in just under 3 minutes, so if I had to do it to all the components in my design file it would only take me about an hour. But, if I start to handoff each component as I create them I can mitigate this time and it won't even hurt!
?? Redlines
As the name suggests its main features revolve around creating redlines but it can also create connectors and measurements, pretty much like R&A does, although it lacks the possibility to create annotations, which is a great part of what makes a good handoff.
I used it for quite some time while building some of my components, but I retired it in favor of using R&A as it comes with annotations built in. You can still make your own annotations by hand, although it can be a little demanding. In the end it's all a matter of preference.
There are many more plugins and tools out there that help us create simple and agile handoffs for our components, but these two are more than sufficient to deliver what the developers need to be the most faithful to our designs.
After you have successfully created your designs and components take a moment to introduce your files to the development team. Schedule a meeting with them, share your screen and show them the way through your documentation. The duration of the meeting can vary depending on the length of your project, but try to keep it as short as possible so the team doesn't feel overwhelmed. You can also make sure to answer any further questions that your handoffs alone couldn't resolve. Besides that feel free to revisit and update your documents at any given time, but always warning the developers about the changes you've made.
? Validate your designs
Finally your project has been designed and contextualized. It is all over now, right? WRONG! [insert loud buzzer noise].
When you finish delivering a design project to your team you have to keep a frequent schedule on validating your designs with your developers, for the handoff alone doesn't make any miracles (at least not yet).
Questions and doubts will always exist in the context of developing a product, and it's part of the designer's job to make developers' lifes easier so they can better understand the product and be more agile on getting their work done.
By frequently validating your designs and explaining your documentation and userflows to your team you can guarantee that all of your ideas and hours spent on building a beautiful and cohesive design were worth it.
Sometimes though the developers are not used to design validations and can even feel a little pressured because of it. You can mitigate this feeling by explaining the importance of your validation, what mistakes it can resolve and how it will help them do better at their work.
Just remember to always remain calm, gentle and open on your meetings, nobody wants to be ordered around like a kid everytime an error is found. The more you practice your validations with your team the more it becomes a routine, and by becoming a routine it will flow more naturaly and with ease.
Also try to be as direct as possible with your validations. Focus on what is wrong, helping the team get things right and listening to their feedback. We can all learn a thing or two from our colleagues from time to time!
?? Fin
As this article has gone on too long I'd like to finish with a small conclusion: talk to your team members, stand up and have an active voice in all your meetings and try to be very precise with your handoffs so your developers are left with little to no doubts about your designs.
Don't be shy to document every step of the way: you can write notes, design userflows and even make your project fully interactive if you have the time. Use your imagination.
Also try to always create your redlines and specifications right after creating your components, as well as validating your desings with your developers every time you have the opportunity.
Remember, in the end it all revolves around good communication!
Back-end Developer | .NET | ASP.NET | C# | SQL | Node.js | TypeScript | GraphQL | Apollo Server
5 个月ótimo artigo, Vinicius! Obrigada pelo seu insight valioso!??
UI/UX Designer em Evolu??o para Product Designer | ModalGR
5 个月Incrível, Vi! Adorei o tema, com certeza será um divisor de águas para todos que tiverem a oportunidade de ler. Super recomendo!
Gerente de Negócios | Product Manager | Product Owner | Gerenciamento de projetos | Análise de negócios | SQL | NoSQL | Node | Python | BackEnd
5 个月Excelente, um tema muito importante de ser esclarecido para todos os stakeholders.