5 steps to maintain strong design-dev bonds
Product teams that aim to grow in design maturity and dev output need to create a strong bond between designers and developers besides simply design to dev handovers on Zeplin.
When well done, this process takes a lot of disciplined and involved effort to get the teams on each other’s planes to consequently better outcomes in design and tech.
We discuss five key points to keep design-developer relationships thriving:
1. Consistent inter-team communication:
Intermingling conversations help with knowledge transfer at a spoken level and building a good rapport between the teams.
At the early stages of a project, the design team would be the first to create an actionable item that the end-consumer will see at a concept level.
Therefore, the design team, from early on, must have formalised discussions with the development
Even at the early stages, proper communication and cadence building between the teams is crucial when there is no formal documentation.
Good product teams make sure that design and dev teams are virtually indistinguishable, work with each other seamlessly, and take ownership collectively.
It’s all about having a shared language.
2. Clear documentation between teams:
A Product Requirement Document (PRD) is prepared to define the product requirements, personas, scope, user journey, and user outcomes.
Formal documentation, for example, the one mentioned above, helps keep everyone on the same page and track what needs to be prioritized. It, of course, can be misused as a bureaucratic layer of nonsense, but in the best of cases, it leads to very well informed teams.
It can help in avoiding conflicts between developers’ intentions from that of designers’. When details get more intricate during the project duration, documentation helps everyone stay aligned on decisions. It helps keep a record of changes made.
When iterating between the teams, the developers must inform designers about specific technicalities of what is feasible and what isn’t. Documentation should also be created in a way that a non-technical team member can easily digest it and deliver in terms of their tasks.
Formal documentation is important also because it assists new developers to get on board and get aligned with everyone quicker.
Context is crucial.
3. Plan out a fixed and disciplined structure for design to dev handover:
Whatever software you are using, make sure a specific file discipline is maintained, even for minor tasks. For instance, the naming structure, the sectioning of the handover is properly named and maintained.
Zeplin is used for handovers. You want to make sure it is clearly set up for the developers.
Designers, in particular, should not make the grave mistake of assuming everyone knows how your design will work just by looking at it.
You want every paradigm and flow to be explained out in a well-structured and straightforward manner. During handover, you need to make sure these critical hygiene points are set in place.
4. Providing clear guidelines for better and more structured UI testing:
When design teams are tasked with UI testing (which happens far more often than we’d like to believe), it becomes crucial that the developer team provide clear guidelines on how the testing procedure should work. It is crucial that the design team are given a certain context of what functionalities and elements they need to test.
For instance: if the frontend development team is a little unsure of how a picture will scale up and down, they should mention it to the designers to test that specific component for different screen sizes.
On the other hand, designers should themselves have an understanding of the basic tools that could make testing an easier process.
5. Creating shareable knowledge bites regularly across teams:
This one’s primarily for rapidly growing product teams.
Teams can significantly benefit by initiating the practice of producing one piece of shareable content regarding some technical details about the respective teams’ line of work. This can ideally work as a bridge of knowledge from one team to the next that isn’t related to simply the work they are currently in, to create a stronger environment of learning. The aforementioned content piece could be a full-blown presentation or something brief, like a 500-word document.
Let’s say you have a junior SDE; she could write a short article about a useful topic like flexbox and present this information to the design team. The designer team will then be informed of a tool that the dev team possibly uses, which creates a design environment that keeps the considerations of flexbox in mind.
This learning can go the other way as well. For instance, the designers can talk about scanning patterns and their application in their product to give devs a more clear view of how eye movement across a page would work.
Some thoughts to leave you with
Decoupled relationships between the designers and developers can create pain points for the product team and its output.
Both the teams should account for each other problems as well as the solutions because its lack will feel like a very disjoint effort.
Being immersed in each other’s strategy and structure, at every step of the product development journey, instead of working in silos, positively impacts the product outcomes and overall team capabilities.
The Canvs Editorial team comprises of: Editorial Writer and Researcher- Paridhi Agrawal, the Editor’s Desk- Aalhad Joshi and Debprotim Roy, and Content Operations- Abin Rajan
Follow Canvs on Instagram and LinkedIn. Don’t forget to follow us here on Medium as well for more design-related content.
