Design collaboration with engineering: 3 styles of effective communication
Every Designer and Developer in tech has to have an answer ready for this question: how do you collaborate with each other?
The answers run deep and wide, but usually stem from the ill-conceived construct that both disciplines want to see themselves as the ultimate builders of products. Each thinks the other one only makes their job harder, or is a supporting role.
So what’s the beef?
If enough hurdles are put in collaboration and communication between them, Design can make Engineering slower — and Engineering can hinder Design with technical constraints. But at the end of the day, everyone is working towards the same goal. So how do we navigate this in the real world?
Companies in more advanced stages of interdisciplinary collaboration will, simply put, build better products.
In 2006, Jakob Nielsen presented the UX Maturity Model that presents the stages of assimilation and adaptation of the user experience in the organisation. It exemplifies how intrinsic the relationship between Design and Development is to shipping great experiences. This article on defining maturity metrics by Caio Braga, designer at SurveyMonkey, expands on this idea.
Below are 3 ways I have seen Design and Engineering overcome this over the years.
Style one — each to their lane
The most basic way I’ve seen Design and Engineering working together is simple: people trust each other’s abilities, but there is no overlap in work streams.
People stay in their lanes of expertise and end up not cross pollinating and deepening their understanding and empathy for other disciplines (and each other).
This means that even if things are done to a good standard, deadlines and the overall quality of what is shipped suffers. Work is siloed and communication is staggered.
The usual way work gets done tends to be:
- PM gets business goals from leadership and decides what features/products to ship to hit targets
- PM assigns specific outcomes for product/feature both in Design and Engineering
- Design and Engineering don’t speak, and probably don’t have an existing relationship. They put their heads down and do the work separately
- And then there is a formal handover process of the work, possibly with some review sessions scheduled (many, because there are lots of problems in implementation)
This means that no one is truly taking advantage of the other’s expertise. I haven’t found this a very sustainable way of working, and if you have ever encountered designers that say they don’t like engineers or vice-versa, it’s probably because this is the work model they have been exposed to.
What are the possible problems here?
- Engineers weren’t involved early enough, so technical constraints are only brought up when Design is already advanced — which means a lot or rework
- The handover process becomes cumbersome — things that could be solved with a conversation become pages and pages of documentation
- Problems with implementation don’t get brought back to Design in time — worst case scenario, it only becomes apparent something is off on the day of the launch
…Which could become pointing fingers at whose fault it is, and the cycle of distrust restarts.
Style two — over-communication
I consider this the next stage in elevating the working relationship between Design and Engineering. Here, over-communication starts to become key.
The way of working at this stage tends to be:
- Decisions on what is a priority to do are taken as a team. This should be a joint effort from Product Managing, Engineering and Design organisations(ever heard of the triad?).
- As part of determining what to do, there is an analysis of overarching business goals and metrics, technical feasibility and customer needs
- After the goals are set, the focus is on action points: this could be for PM to identify overlaps with other ongoing projects and teams, for Engineering to figure out technical constraints and capabilities, or Design to benchmark existing solutions and where we could push on the problem itself.
An example of something I liked to do at this point was weekly chats with the Product and Engineering teams that I called Spoiler Sessions.
These were basically early dives into the Design process, demystifying the work and also opening the floor for early feedback and discussions.
This helped spread the sense of ownership with the whole team, getting everyone excited and engaged in how we were trying to solve the problem.
Things that really helped following up from these:
- Making sure that everyone got a chance to contribute, be they introverts or extroverts. While it was an open discussion, it was only a max of 30 mins. This means giving people as many ways to communicate as possible so everyone is comfortable. I incentivised writing on post-its, sending DMs, and most of all commenting directly on files: this way there were in-context threads that anyone could follow up on
- Making sure I managed expectations, being honest and open about the state of things and what was still needed.
Advantages of working like this were that people from the team were able to talk about the work we were doing in a holistic way, and that I didn’t need to be in the room to make sure design and user-centric principles would be discussed.
However, communicating does not necessarily mean collaborating.
What are possible problems here:
- Customer contact could be limited to just PMs, meaning no one else has the chance to do Primary research (directly from the source)
- Design could get in the habit of only communication outward rather than creating space for feedback — only relaying the current state of things and decisions that have already been made
- Engineering could feel like they only get to execute on decisions made before anything gets to them, as they have no clear idea of customer pains and needs
Style three — real time collaboration
The fastest and most effective way of working, the triad at its best, means collaborating in real-time and trusting each other’s capabilities.
How work usually happens at this stage:
- There are still business goals that need to be met, but the decision on what will be tackled is informed by data insights rather than data led — there is a strong understanding of customer needs across interdisciplinary teams.
- Before, each group would silo and try to tackle the problem from different perspectives, only getting back together to report on findings. Here, we have consistent working sessions where there is real time collaboration. This means there is no lag in communication, and instead of design presenting and engineering giving feedback, there is stuff being designed, built, and investigated in tandem.
The work shifts, pivots and flows organically through cross disciplinary team mates, with feedback sessions happening frequently. Course correction won’t take half as long.
Simply put, more brains think faster than one. This doesn’t mean extensive whole day sessions in a war room either: 30 min jam sessions on ideas, 20 min feedback sessions with customer support, 30 min critiques with teammates are easy to dot around the calendar to make sure to keep the ball rolling. What could take a week to do before, even with over communication, could take 2 days now — and with fewer surprises when it gets to development or deployment.
And guess what: this is completely feasible and entirely achievable in a remote culture. There is no need to worry about booking rooms often or big enough for everyone, and if you feel like you need someone else’s input mid-session you can always just invite them in with a click.
What other styles of collaborating have you experienced? Did you relate to any of these ways of working?
If you want to read more on the subject, there are lots of resources to check out here:
- Eye on Design article calling for the debacle to end
- It’s Nice That article outlining the false rivalry
- what it means to be both designer and developer
- defining maturity metrics by Caio Braga
- how large teams which make over-communication a standard thrive on this interview with Leslie Witt
- Difference between Primary and Secondary Research
- on incentivising collaboration between design and development, this article from Anna Lurchenko designer at Google Health on collaborative design processes for innovation;
- or this Invision article outlining 6 ways for designers and developers to collaborate better.
