Experimenting with Pair Design
You might have heard of pair programming, where two developers work together at the same workstation on the same projects. In a typical pair setup, one developer actually writes the code on her sweet, lighted mechanical keyboard while the other sits back, observes and reviews the ideas and code being created.
While implementations vary, the goals of pair programming remain the same; consistent code, increase quality, build teamwork via collaboration, mentorship / learning, better decision making procedures and decrease in troubleshooting time.
Realizing that these goals directly match up to our design principles we wondered if pair designing would be beneficial to our products and team members. With specific goals in mind, we decided to pair up designers who were working on similar products to figure out what might work.
Some pairs were focused on mentorship, where a senior designer would be teaching a junior designer directly rather than working on projects together. Other pairs were matched based on skill level so they could focus more on working together and reviewing each other’s work.
After experimenting with different methods, times and techniques, most pairs were meeting a few days a week for an hour or two to discuss projects and progress, as well as communicating daily either in person or via Slack to ask and answer questions.
Discovered benefits
While the experimentation continues and the methods being used continue to evolve, the benefits have been pretty clear and even surprising.
Consistency - Pair designing has helped designers stay consistent to Canopy guidelines and styles through more frequent alignments.
Mentorship - Meeting frequently to practice and learn skills (while working through real problems) has elevated our junior designers at a rapid pace.
Collaboration - Initially, I was worried that pair design could potentially eliminate overall team collaboration because pairs would become dependent on each other rather. However, pairs are sharing more with the rest of the team than before and overall collaboration has improved.
Critiques - Critiques now happen within the pair itself and this removes the stress of presenting work to a crowd and group designer think. Critiques are now more useful and practical than ever before.
Speed - Understanding that I currently have limited data - I feel like designs are being created and moved into development faster. I think this is mostly because the designer has the need to have designs ready and doesn’t get isolated for long periods of time with little collaboration or alignment.
Iterative design - Canopy has a highly iterative and collaborative product and engineering environment and iterative design can be hard to maintain when designers are isolated. Design pairing has improved our iterative design process by allowing smaller designs to be reviewed more frequently. It has also helped designers prioritize their projects more efficiently, shadow other designers, improve communication and sharpen their own skills.
Iterate, iterate, iterate
As you can probably tell, implementing pair design has reaped some serious benefits for our team. But initial benefits aside, it is a drastic change in procedure and is still an experiment. Each pair is trying different methods and techniques, iterating quickly, discovering wins and uncovering problems.
This is an exciting time to be a designer at Canopy, and we will continue to share our pair design failures and wins with you as we evolve and grow!
