7 January 2019
Why Can’t We Be Friends? 4 Benefits of Pairing Designers and Developers
Pairing at Gaslight
Writing code, fixing bugs, and naming things is hard - true story! At Gaslight, one way we deal with these challenges is by practicing one of our core principles: better together. One of the more practical ways we see this philosophy used is through pairing: two developers or two designers screen sharing, talking through solutions, and implementing code. This is a common practice in our office and we use it to continually deliver value on our projects.
However, it is less common to see a designer and a developer pair to complete a task. The work is usually outlined in three ways - soloed off to an individual, sandwiched between the dev and designer, or a little of both. But could there be value in designers and developers teaming up to tackled some functionality side by side?
The Benefits of Developer and Designer Pairing
During my first job working with an agile team, there was one developer who insisted he slowly talk me through every task that required his help. It felt like someone running their nails down a chalkboard - oof. Showing my amazing maturity, I would usually cut him short with comments like, “We have to go faster to keep up our progress!” or “I don’t need to understand the back end.” Though it was a struggle at times, it didn’t take me long to realize the value in coding a solution together.
Recently, I had the opportunity to pair with one of Gaslight’s senior developers to create multiple features on a new project. This experience helped me analyze how this rarely-utilized team dynamic could greatly add value to a project.
- Shared Vocabulary
We all know naming things is hard. Deciphering what the client calls a feature, how a developer refers to it, and the “creative” twist a designer adds to it can cause nausea and even induce vomiting. Talking through a feature together while we were building it ensured that shared terms made sense from several different perspectives.
- Rapid Support and Solutions
Writing more complicated front-end code or fixing a tough bug is usually expedited with the guidance of an experienced developer. Talking through a problem with both eyes on the same code can eliminate much of the back and forth that comes with developer/designer communication. Even better, I had the opportunity to watch and learn while a problem was solved right in front of my eyes!
- Validate Shared Understanding
On multiple occasions, while pairing with developers, I would have to provide rationale for the user experience or even explain why we needed a feature in the first place. We could then go back and forth on what frameworks or plugins were necessary for the desired functionality. The two of us were able to talk through different ideas and then implement them. These discussions would strengthen my reasoning before I presented the work to a client and I was able to help the team be intentional about the technical debt brought to the project.
- Exposing Disconnects and Conflicts
While this process often helped validate solutions, it also put a spotlight on significant conflicts that may not be as clear when working separately. One example was the desire to add javascript functionality or a javascript framework. I would advocate for the client’s desired functionality on the page and the developer would try to hold off on adding complexity as long as possible. Working through these conflicts as they came up, enabled us to avoid a painful refactor later on in the project.
Delivering Value, Building Trust, Growing Empathy
Each one of these benefits can bring greater value to a project, build trust between the team, and increase empathy for each other. All three of these values are keys to Gaslight’s success and I encourage all designers to give developer/designer pairing a try.
