The team over at Pivotal Labs, a NYC & SF Dev shop, are big proponents of Pair Programming. This is a programming methodology where two developers sit next to each other at two computers that are showing the same screen so they can work on the same code together at the same time.
This has many benefits. Neither becomes distracted checking email or updating Facebook so their time is used on actual code, each encourages the other to work through problems, the less experienced member learns high level skills rapidly, and problems are solved through a consideration for the best solution through dialogue.
This means that a company who has their product built with Pivotal is getting some solid programming behind it. Pivotal developers are going to give you a healthy, long term solution for your technology – no slash and hack. It also means the client is paying for 2x the developers per hour. That’s about $500/ hour, and you’ll receive some of the best dev work this fine city has to offer.
For that same reason, this model doesn’t work for agencies who need to push a Doritos game app out quickly for a short term promo, or rapidly react to a market environment like Oreo’s and the Superbowl blackout. The client, Doritos, doesn’t need solid programming for a quick two month event. They need something that works and looks amazing, but doesn’t need to last. The same can often be said for startups building an MVP – they really believe in the idea – but know that the most effective way to validate is to get it out into the market. It doesn’t need to stand the test of time, it needs to prove itself to a customer base or investors.
I learned about Pivotal’s model ages ago and as designer, decided to adapt it to my own way of working as well as see if I couldn’t make it work for both types of clients. There are a few approaches to it.
One approach is to team a designer with a front-end developer to build out a site together. The designer has a pre-created layout that guides the developer, but the designer suggests which parts to focus on and helps with the CSS as they intended. The effect is a much quicker solution for the front end than the developer working alone. At the same time, the two can talk out issues for areas when the design might not translate as well. It also means the two can decide on a healthy and apt solution for the interactive elements together. This saves a lot of time from the back and forth that would have occurred every time the developer needed to change something, or the designer felt the design wasn’t implemented correctly.
The other paired design I actively engage in is with two designers (or designer and client) sitting side by side. The two discuss the goals, review research, and one starts working. While the design is being created, the team of two discuss the solutions and each suggests alternatives. When one gets stuck the other is there to make suggestions. Again, no one checks email or gets distracted, but more-so the team is focused, deeply, on creating an exciting solution. I’ve found that designing this way can create unexpected results and is a significantly quicker path to a final product than one person stressing out over it on their own.
When does this not work? When a team is ill fit for working together. This is frequently the case when one party is adamant on pursuing their interests over the clients or isn’t willing to compromise over aesthetic decisions. The result in this case is a lack of results – literally. Fortunately, this becomes apparent quickly and little time is wasted. I’ve found it is important to set aside your own “experience” and listen to why people make the design decisions they do. When a designer isn’t willing to do that, they probably shouldn’t be paired.
At SWARM, we handle a lot of our projects through a collaborative paired design model. We’re social animals and we like it, and it also creates a better result with significant time/cost savings for the client. This isn’t design by committee, where the final product is so diluted it has no impact, this is a strong team working in pairs of 2 to create the best possible result from the exponential experience of the minds together.
I encourage everyone to try paired design. There is a learning curve, and you need to be a team player (ie, you’re not always right), but once you pass those hurdles the rewards are a kick-ass campaign you couldn’t have done on your own.