The Content Corner: Is Pair Writing Right for You?

Fresh from last week’s article about workflows and their importance in the content creation process, I stumbled upon a new twist in content production known as pair writing.

Many of you familiar with agile methodologies or software programming in general should know the term pair programming. Pair writing hopes to take some of the same efficiencies found in pair programming and apply them to content creation.

Two Heads Are Better Than One

Pair programming gained prominence in the early 2000s as a method to improve the quality of software by having two programmers work together while coding. One programmer would be the driver and be doing the actual coding while the second programmer would sit next to the “driver” and observe, ask questions and consider strategic and customer concerns. While similar to the team work provided by workflows, this second set of eyes operating in real-time allows the “driver” to focus solely on creating code.

Some of the empirical benefits of pair programming include:

• Pairs spend 15% more time on coding, but experience a 15% decrease in overall defects.
• Pairs have also been found to consider a wider range of solutions and develop simpler, easier-to-maintain code.
• As expected, pair programming is also known to improve communication and foster a greater sharing of knowledge. This is especially true when various pairs are formed on a regular basis.

As I was researching pair programming, I could definitely see some parallels and how the benefits of pair programming could be applied to the content creation process. But how to get started?

Pair Up

One thing to keep in mind is that any kind of pairing may not work for everyone or every agency. I’ve talked to programmers who loved pair programming and just as many who hated it. So, as you might expect, start slow and see how it goes.

One of the best ways to begin is either with one pair or with a small set of pairs. You should decide upon a fairly straightforward piece of content you need to develop such as a short news piece that everyone feels is important and can be fully engaged with.

Everyone involved should also be very clear on what the expectations are of both roles and what the end result should be for the limited exercise. I would spend no more than an hour initially, especially if you decide to just work with another person and form a single pair. The writer should understand that they are free to focus only on writing while the observer’s role is to play the advocate for the user, and the agency, in the process. It’s important for the writer to understand the flow of the process and not be upset or impatient at questions, observations or corrections the “antagonist” of the pair will raise. The end result is to develop the best content possible for the user.

It’s also important to switch roles regularly throughout the process so both sides are balanced in both actual content creation and in review. One of my strongest concerns about the practice comes from levels of potential irritation and conflict from the writer. Pair writing (or programming) is essentially legitimizing having someone look over your shoulder. Traditionally that is not something people enjoy, especially when that observer is also possibly reading aloud, making sounds and even interjecting questions or comments while you are writing. The frequent switching of roles seems to me to be the best correction for this; you could perhaps even have both persons monitor irritation levels and make it a rule to switch off when tempers are getting close to a simmer.

Once you have an initial draft completed (and hopefully are still speaking) you can then decide on your next steps:

• Do you feel comfortable going ahead and publishing this first effort?
• Should you swap with other pairs and repeat the process for another hour?
• Do you then have a few people outside the process do a quick informal usability test of your new content?

One of the next steps I do not feel should be optional relates to the irritation levels and the animosity that could develop during this process. You and your partner should take time once you have decided the fate of the actual content produced and also review the process itself. An honest assessment of what each of you felt worked or didn’t or suggestions for new things to try, if, and when there is a next session, is an important part of trying any new process.

In the end, you may find you love it or it isn’t for you. I think (where practical) the possible content improvements pair writing can provide deserve a serious test, at a minimum. Instead of a more traditional step-by-step process of gaining user feedback on content, pair writing can give you a real-time user sitting by your side helping to guide you or ask questions as you go. Will it be annoying? Most likely. Will it improve your chances of writing better content for the user? Very possible. Test it out and let me know what you find (or if you practice pair writing already, please share in the comments).You’ve just finished reading the latest article from our Monday column, The Content Corner. This column focuses on helping solve the main content issues facing federal digital professionals, including producing enough content and making that content engaging.