But first, what is pair writing? It’s the practice of writing a piece of content together with someone else. You meet up in real time, likely to be remotely at the moment, and both have the draft document open. The content designer would have created the draft document, which may at the initial stage only have section headings, based on and prioritised by user needs.

Unless you are pair writing with a content designer, you would only discuss factual information to answer the user needs, and whether your content development and iterative edits are factually accurate.

Pair writing with subject matter experts

Step 1: Involve subject matter experts (SME) in regular content show and tells – so that they know about and understand content design, and know the schedule of upcoming topics far in advance.

Step 2: Meet with them at the start of writing a piece of content on a topic in their knowledge area. Tell them what the user needs are for the content. Ask about any information gaps you’ve identified in the factual source material you have access to.

Step 3: Draft your piece of content and book in a meeting with the SME, for them to review it with you.

Step 4: At the SME review meeting, explain what the content decisions were and remind them of, or share, learnings on content design best practice.

It's more effective to refer to external references on usability and readability than to present the best practice as your professional opinion or what the organisation style guide says, as they may well argue against internal advice! I'd recommend the Readability Guidelines wiki. Not because I worked on it for a year and a half, but because it has over 200 usability evidence sources to back up the guidance.

If you know something is best practice but haven't got a reference to hand, let the SME know that you will do some research and follow up with them.

Case study example: I had to put job profile descriptions into plain English. SMEs argued for more nuanced terms. I explained that clear language is more user-friendly for their national audience of 17 year olds, career changers and returners to work, who may not know much about the job yet or may have a low literacy or fluency level. Also explained that although being concise is generally good for web content, a clear language definition may end up making the copy longer but that's OK as it is better for content to be understood by all than to be brief.

Step 5: Edit the draft for any feedback you agree needs to be actioned. Your steer on what to change should be:

1) factual corrections where meaning may have been obscured in your draft
2) extra information, if it meets a user need

For this step, if you are comfortable doing the edits "live" you can edit the draft during your Step 4 discussion. If not, thank the stakeholder for their contribution and say you will be in touch with them about the next review session.

Step 6: Get another content designer or content person on your team to peer review the draft, that is read through it and give any style, readability or layout suggestions they may have. This is sometimes called a 2i, standing for having a second eye on the content.

Amend if you agree with their suggestions or leave it to user testing to decide. A/B testing, where you user test 2 different versions of content, can often solve differences of professional opinion between designers.

Step 7: Test the content with users. This may be within a clickable prototype. Testing with 5 users is said to uncover 85% of user issues, but remember that leaves 15% undiscovered.

Iterate the content from analysis of their feedback. When you analyse user feedback, look for themes. Usually if only 1 person has a minor problem you can discard it. However, if that is because the person has access needs that the others do not, and the problem relates to access, then you should not discard the feedback.

Repeat as many times as necessary for a good understanding of the content, and smooth interaction with it, by a variety of users, or as far as budget allows.

Step 8: Meet the SME to run through the final draft, or email it to them. Be clear that at this stage you can only accept factual amend suggestions. If you email it, set the permission to comment only, not track changes. If they make a lot of comments, arrange another in person meeting. If you make significant changes as a result of their feedback, ask another content designer to 2i the final draft.

Step 9: Make sure that the SME understands that they are responsible for the factual accuracy and appropriacy of the content. They should get in touch if for example regulations referenced in the piece change or are removed. You would also involve them in regular 3, 6 or 12 month reviews of the content piece.

Whenever you talk to SMEs, make sure they understand and largely agree with your content design changes. Keep explaining things patiently. If they refuse to acknowledge user centred-design content principles, escalate the discussion to your content lead, head of content or UX lead.

Pair writing with service designers

You might have a service designer working with you on a digital product or service. You'd work closely with them throughout the build, but in terms of drafting initial content you’d meet with them at:

Step 2, to understand fully the intricacies of the service
Step 7, to iterate the content to reflect service or product changes made as a result of user testing feedback (you would also apply content design changes that you believe will fix user issues and observe any difference made at the next round of testing)
Possibly at Step 8, if the SME had significant changes
Step 9 for the "life after live" reviews, testing and iteration

Pair writing with technical architects

Technical architects might ask you to work with them to write up technical reports in language that non-technical project members can understand. You would pair write with them by getting them to explain clearly what they mean by technical jargon.

Keep asking them “What does that actually mean?” until you reach a point where a non-technical specialist can understand the content. Encourage them to explain abstract concepts to you as though they were explaining it to a friend. This can be a good way to get a simple take on it.

Another good way to translate technical concepts into clear language is to write a phrase or definition out on a white board and analyse parts of the sentence in turn to find clearer alternative wording.

Pair writing with another content designer

As well as the at 2i stages at Step 6 and Step 8, you could share your draft with a second content designer every time you make revisions, and invite them to the SME meetings. You would also get peer content designer feedback at content crits.

Alternatively you may be working together with a second content designer to co-create a piece of content. If you’re pair writing 50/50 like that, to create the initial draft you’d both sketch out how to word and prioritise headings to answer needs, then discuss your sketches to agree on the best of both to write up into a draft document.

You could then take it in turns to meet the SME, and agree edits together afterwards. That can help prevent it becoming or being perceived by the SME as a person-to-person opinion exchange. Or you could both meet the SME to back each other up on content best practice, but be very careful with this as it could come across as bullying them into it.

Or you may have a senior content designer working with a more junior one to mentor them and pass on skills.

Both content designers should attend, or remotely observe, all user testing on the piece of content. And you’ll still benefit from large group content crits, where content designers who are not as involved in the piece of content can give objective feedback on how understandable it is.

More resources around pair writing

I've seen pair writing done well and done badly. This article suggests some steps and advice for achieving the former.