Working Together Design and Developers
“Coming together is a beginning, staying together is progress, and working together is success.” — Henry Ford
Designers often talk about the the design process in great detail — the research, ideation, problem definition, testing, style guides etc, the last stage is the implementation and that is a topic that is not talked about enough.
As a designer working in product teams it is key for me to collaborate with the rest of the team project managers, business stakeholders and naturally developers too. Developers/engineers construct the all important product that makes it function for a user. If as a designer I design a product or feature and then just hand it off to a developer and tell them to ‘make it so’ then I as a designer am not doing my job fully and on top of that being told exactly what to do for the developer is extremely demotivating. That type of approach will lead to a bad product.
Get the whole team aligned early
I prefer the approach of working with developers early on in the project. That way they know what they are doing and why they are doing it. Design thinking workshops are a perfect example of that, it can really align a team and motivate them. Discussions can be had with developers at early stages on certain tech limitations and ease of implementation. While the design team prioritise the user they also need to know what can be realistically achieved.
Get to know your team and their strengths
Working with each developer individually is also a good way to get work done above and beyond what was expected. Each developer have their own skills, past experiences and areas of interest. Working and chatting with them individually means you might find out that a certain developer loves creating animations. So working with that developer you can create animations together and end up with a delightful product with nice micro animations that will delight both the product team and the user.
Bring the developers in on the design process
Have a new design suggest? Then pass it by the dev team, not just the design and product teams. If any of the devs have some free time then bring them in on user testing session. I remember having a developer not being happy with a feature flow and I suggested for her to come to the user test sessions to gain a better understanding of our users. She came out of the sessions with a new perspective, understanding and motivation and would always try to come to user test sessions if time allowed for it.
Prototypes
Prototypes are vital for a smooth handover. Chances are you have made a prototype for user testing and for various stakeholders to see the flow and interactions of the product/feature you have been working on. Now it is time to make sure you have all the feedback and to update the prototype and make a final version for the developers. Most prototype tools allow you to add notes so that you can emphasise certain details of the interactions.
Things to remember
Zeplin/Figma/Invision are great for handing over pixel perfect designs. They are not so great at handing over responsive sites. Colour, type and component styles. Make sure you create rules to how type and components break down at various screen size. Is your product is global and in different languages? Then you have to test the languages on your design, some languages such as Russian can have super long words and sentences and may not fit in your design. Are you supporting a dark mode version? Overall having a checklist for what has to be done before handoff is a great way to make sure you have not forgotten anything.
Checkpoints
Have frequent checkpoints. The project kickoff, research conclusions, design progression , dev estimations and of course a dev demo before sending to production which ideally the team should factor in some changes along all these checkpoints.
Every team is different
Every team will always work slightly differently. When a new team comes together it is worth doing a few workshops on how you want to work together. Think of each other from a user research point of view. Everybody will have their own pain points when working and if the whole teams know each other pain points and how to solve them.
The end result of working so closely as a team is a product with less bugs, better design and saves time and money with less fixes to be made. Oh, and also of course it makes for a happier team.
