Better Together: Demystifying Designer-Developer Collaboration
In my experience, when a team is humming along with healthy designer-developer collaboration, they can do anything! Move mountains! Take on the world!
Perhaps you’ll be lucky enough to join a team where this is already the case. How nice! But what about those of us who join teams with lackluster designer-developer collaboration? Or worse, a team where there’s a deep disconnect or animosity between the disciplines? Or possibly even worse, a team where the disciplines simply coexist and ignore each other? More likely than not, you’ll encounter one of these less-than-ideal team situations at some point in your career. My hope is that, when faced with it, you’ll be compelled to help make a change for the better.
Admittedly, it’s hard to see the water that you’re swimming in. I’m a designer at IBM, and from the time I started, I’ve been fortunate to operate within a culture that assumes that collaboration between designers and developers is inevitable. There are certainly some individuals within each discipline who are grumpy about this, but no one is arguing for a future that doesn’t include healthy collaboration. This is a top-down and bottom-up effort. If your leaders are not advocating for this, start there.
But let’s say your executives are on board, you’re on board, and your team isn’t. What follows are some suggestions of how to begin to foster healthy designer-developer collaboration. Although they are arranged in an ordered list, each action can easily be done on its own or out of order.
1. Find out your and your teammates’ superpowers
Whether you are a designer, developer, or some other discipline, you bring some valuable superpowers to your team. If you’re not sure what these are, take some time to uncover them. You’ll want to be grounded with a good sense of the specific skills that you bring to the team. This will help you when advocating for your discipline to your team.
On the flip side, the other folks on your team also bring valuable superpowers, which are likely different than yours. Seek them out. Ask folks what they’re good at, what they like to do, and how their discipline brings value to the team’s work. By assuming that other folks are experts in their discipline and by taking interest in their superpowers, you take a step toward building a culture of mutual empathy and respect.
If it seems that no one really understands their superpowers, then do a quick team exercise to uncover them. Have other folks anonymously write out the superpowers they see in each team member, then let each person read the notes about themselves. From there, have each person add a few ideas about their own superpowers. In just a few minutes, you’ve given each person a chance to see how they make valuable, unique contributions to the team, and you’ll all be better equipped to appreciate each other’s expertise.
2. Level up on the other disciplines
Empathy is amazing and necessary, but it can’t get you all the way to healthy team collaboration. If you are a designer who knows very little about development, how can you expect to speak knowledgeably, ask good questions, and consider other perspectives? The exact same is true for developers who know very little about design; they’re not set up for successful collaboration with designers.
This is an opportunity to level up and learn some of the other discipline’s “language.” Rest assured that there is a learned language in each discipline, and will behoove you to know some of the key terms and concepts. Not convinced? Just ask a non-corporate friend if they know what you mean by “headspace,” “Q1,” or “stakeholder management.” These words will likely sound foreign to a teacher, nurse, or chef.
Luckily, information gaps are fairly easy to solve. You could interview some folks on your team about their discipline, read a few books, or go to an enablement workshop as a team. Ideally, this will go both ways, with designers learning a bit about development and technical constraints and developers learning a bit about user research and design. The goal is not to become an expert in the other discipline, just to be able to speak a bit more knowledgeably.
3. Track your work in a shared place
A common source of tension between developers and designers is disagreement or lack of visibility into the work to be done. This may be caused by backlogs that are non-existent, fragmented into multiple backlogs maintained by each discipline independently, and/or inaccessible to some team members. When this is the case, it’s too easy to get misaligned and to assume the worst about what other team members are working on (or not working on).
Although I’m not religiously devoted to all tenants of agile, I do believe in the ones that provide practical help to support healthy teams. A core tenant of the agile methodology is having a backlog of prioritized work items, and I’ve seen this practice be highly beneficial for good designer-developer collaboration. Having the whole team’s backlog in one shared place that the whole team can access is a dramatic equalizer on the team. Even better is to ensure that both design and development have a say in the prioritization of those work items. This type of visibility and agency contributes to empowered teams who are personally and collectively invested in the work to be done.
This requires a place to track the work items, which could be on a physical whiteboard if your whole team is in person, or virtually if you’ve got remote team members. Tools like ZenHub, Jira, and Aha! can help with this. It also requires a practice of adding items to the backlog and then prioritizing them as a team, commonly known as backlog refinement.
4. Give everyone access to the code base
At one point I was on a team that churned, got bottle-necked, and generally didn’t trust each other. After a series of failed attempts, we made a serious change: every team member got a working copy of the local code base, like it or not. Paired with a brief introduction to git and GitHub, the change was magical, dramatic, and almost instantaneous. There was transparency and shared knowledge. There was humility and helpfulness. There was trust.
“But our designers don’t code!” declare the naysayers. And besides, why would any self-respecting designer even want access to the code base? Many teams are convinced that only some members of the team need access to the production code. They believe that it’s possible to strategize, collaborate, and work nimbly without a shared understanding of the guts of the product. But the reality is that it is awfully hard to do those things when there is a giant, invisible, access-controlled wall between teammates (i.e. your code repository).
The suggestion here is that designers should have a working copy of the code base and a basic understanding of git and GitHub, not that they should necessarily write code. It will require the developers to help the designers, and it will require designers to get their hands dirty in a different way than they’re used to. At a minimum, designers will feel more empowered and empathetic. At best, you may find that designers can be valuable contributors who make changes to the code base right alongside the developers on your team.
5. Pair designers and developers to complete work
In software development, there’s a practice called pair programming, which advocates for pairing two developers to work on the same task. In its strictest interpretation, the two developers will share a single keyboard and monitor! The benefit is two minds, skillsets, and perspectives tackling one problem to get to a higher quality code.
The most intimate practice I have to suggest for healthy designer-developer collaboration is to actually work together. You can riff on the practice of pair programming, and simply pair a designer and developer to work together to complete a given work item. Have them physically sit next to each other if possible, or otherwise meet together on a screenshare. From there, have them sketch, prototype, and code the work together.
Done well, this results in getting to code more quickly, iterating more quickly, and higher quality deliverables. Possibly most importantly, it shows that your team values each other’s superpowers and leverages them. The empathy gains cannot be overstated! There’s nothing quite like rubbing shoulders while working together to develop mutual respect for each other’s disciplines.
In summary
Although there is no quick fix, these five suggestions should get you on the path to healthier designer-developer collaboration on your team. Once again, they need not be completed in order, or even in total. My recommendation is to choose one that sounds most do-able, and then go from there. If possible, find a few other people on your team or in your organization who are also championing healthier designer-developer collaboration. Team up with them to bounce ideas off each other about what’s working and not working. Take notes of your progress along the way, so that you’ll be able to look back and see growth.
And finally, take heart! Although it is not always easy, when these disciplines learn to work together, magic happens. We are better off for having worked well together.
Robyn is a designer at IBM based in Austin, Texas. The above article is personal and does not represent IBM’s positions, strategies, or opinions.
