Elements of good design-dev collaboration

With the prevalence of product companies in India, close collaboration between Design and Development functions has become the norm. In this article, I’d like to share a few ingredients which I believe are imperative to foster design-dev collaboration. Some of them could be useful for young designers who are starting their journey and want to get the best out of those sessions with developers. While other elements are more relevant to the organizations that are struggling on this front.

I can remember when I was doing my first internship in a software consulting company in 2012 or when I started working in a large corporate in 2014, my interaction with developers used to be close to zero. I got the first-hand experience of closely working with developers in a small product startup. The opportunity brought a new set of challenges as well. In design presentations, I used to get defensive when developers gave any feedback. At times, it would get difficult to convince them about the design decisions and why should it be developed as per my design recommendations. Also, that was the first time, I could closely see the mismatch between developers’ expectations from the speed and nature of design deliverables and reality. I had a hard time managing these expectations.

After that, when I joined my current company, I was better prepared for the challenges while collaborating with devs. In the last 4 years in my last 2 companies, I’ve learned a few things about how to get the best from design-dev collaboration. Let me share them with you.

Team structure and accessibility

In MindTickle, there was a time when we were discussing whether designers should be mapped to a particular product area like developers were, or should their engagement be on a project basis. Eventually, we went with the former and it turned out to be the right decision. Due to the long term mapping with a particular product area, designers have a more focussed mission now and they have deeper knowledge about the product segment relevant to them. From the collaboration perspective, it has brought a lot more clarity for designers and developers about whom to reach out to for a particular query. This has made communication and decision making much faster for us.

Along with the right team structure, it is important to have the right culture and tools for easy accessibility to each other. In MindTickle, great camaraderie among teams, open office infrastructure, and extensive use of Slack and Zoom have enabled us to move fast towards execution. I can reach out to anyone on their desk or Slack for ad-hoc discussion, get alignment, and move forward.

Co-design

Not involving developers from the start of the process can result in a lot of rework because they are aware of existing behaviors, cases, and constraints which we might not be aware of. Hence along with the ad-hoc discussions, designers should also keep regular design review sessions with developers as part of their design process.

In MindTickle, PRD is shared with both developers and designers so that they can share their concerns on the requirements. Once task-flows or wireframes are done, we have a design review session(s) with backend and frontend devs. The objectives of these sessions are to identify any constraints, roadblocks, getting a fresh perspective from developers, and also help them plan their tasks by showing what the solution might look like. Then, after visual design, we have another round of review with devs including the UI development team. Here, we intend to capture any missing state or behavior along with any inconsistency from the dev’s component library. Both types of sessions have helped us to quickly bring alignment between the designer and the devs.

Here are a few ways you can be better prepared for the design reviews/demos with devs:

1. Before explaining your design choices to them, ask multiple whys to yourself to understand why you yourself believe in that choice. Even though, lot of those choices would be based on intuition, try to see where this intuition is coming from and put it in words.
2. When designing new interactions or UI elements, do the research to find similar things in any other product. If you give those examples to devs, they’ll feel more confident that this can be built. Sometimes, they can also reverse engineer that example to create the interaction. Recently, we were working on a transition where the card becomes bigger with more details on hover. While showing it to dev, we also showed examples of Netflix, Amazon Prime, and Linkedin Learning which turned out to be helpful in gaining confidence from devs.
3. Be prepared with the next 1–2 best options of the design elements which you know might be difficult to implement. That way, you can balance experience, dev constraints, and in-time execution. Coming back to the example of card hover transition, we also thought of a particular animation for that transition. But we came to know that the animation would make it difficult to reuse the transition for other types of cards in the future. Hence, we simplified the animation to keep the reusability intact.

Before convincing others, convince yourself first.

Retros

When the design quality check for a feature is conducted only after the development has been completed, it brings a couple of problems.

• For large projects, it becomes a huge task for the designer to go through each of the flows and edge cases to identify any gaps and it increases the likelihood of the designer missing an issue.
• If the designer is coming across a gap that would require major effort, it is possible that it is too late to fix the issue.

Early last year, all the product teams moved to the agile product development process. We adopted development cycles or sprints of two weeks each. Although this is mostly followed by the development team, it has been helpful for the design team as well. After each sprint, we have a retro meeting where devs demo their work from the last sprint. The designer in the project also attends these retro sessions and gets to know about any major misalignment from the intended design. Hence, these sessions ensure that we course-correct ourselves on an ongoing basis rather than towards the end of the project.

Documentation

A little while back, we were working on a feature that was in the testing stage and I was also reviewing it from the design perspective. I clicked on a dropdown which was supposed to show the list of all users but to my surprise, it showed only 4 names. When I checked with the developer, he said I kept 4 values because there were only 4 in the design you shared. This reinforced an important tenet in design for me: What is obvious to you might not be obvious to someone else. Also, in this case, dev didn’t ask us before developing because he didn’t know there is an unknown. This instance solidified the value of design documentation for me.

There is an underlying conflict that we mostly design static screens but users experience the dynamic flows in the product.

We can bridge this gap to a certain extent if we provide the documentation of different user flows, UI component states, and change in behavior in different cases as well to devs. To save effort, in a lot of scenarios, you can even communicate these behaviors verbally in design review sessions. That would leave very little room for assumptions and devs will be able to develop much closer to what we intended. As a result, there would be lesser last-minute changes.

Mindset

In the early stage of my career, I used to get defensive towards the dev feedback on my design. The problem was that I wasn’t going with the right mindset in those discussions. Somehow, I used to treat any comments on the designs created by me as comments on me. I used to be afraid of being judged as a novice designer.

Later, I got the chance to work and learn from some really good developers. I started to look at feedback from developers as great inputs to further improve my designs rather than comment on me as a designer.

Now, my default mode is that they also want to solve user problems by building great products together.

Due to this small but fundamental shift in the mindset, I now have much smoother and fruitful interactions with developers.

Relationship

I am not the most extroverted guy in the room and when I joined MindTickle, I had a hard time building rapport with developers. There were times when this hampered in convincing devs to explore something for me. With time, my camaraderie with developers improved. Although that happened for me unintentionally, I’d encourage others to put conscious effort to talk with devs outside of work context as well. Knowing them personally helps you empathize with them and see their side of the world. It also helps to convince them easily to try out a few things. They will be ready to go the extra mile for you. Sometimes, those negotiations become fun as well.

That’s all, folks. I hope you find some value in this article and it helps you improve design-dev collaboration practices in your organization.

Btw, those who are curious about the illustrations I have used, I was lucky to come across this beautiful collection called Absurd illustrations and found them apt for this article.