Tag Archives: Content Operations

Pair writing with stakeholders, subject experts, designers and other team members

Read Time:7 Minute, 18 Second

Originally published on the GatherContent blog, 17 August, 2020.

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

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.

Resources

Why most design systems are broken, and how to fix them

Read Time:9 Minute, 21 Second

Originally published on the GatherContent blog, 4 May 2020.

I’m going to get straight to the point. A lot of design systems leave content out. That’s why they are broken. They might include a bit of microcopy, but apart from that they largely ignore content design considerations. This is detrimental to product design – and ultimately the user experience.

A design system without content guidance is missing vital parts. It’s an engine without a carburettor. A football team with half its players on the bench. An underground system with no escalators. A balloon without air. 

You can’t complete any product design puzzle with pieces missing. You need to use all available tools to work it out: research, guidance, knowledge, skills, user testing. The design system, your how-to manual, your point of reference, falls under guidance and knowledge. It is something you can lean on to make the best possible first attempt at designing a new product or improving an existing one. 

If you leave content out of the system, you’re drastically reducing its efficacy. Without content, can it really even be called a design system? 

Possible explanations for why content gets left out

It’s puzzling why design systems so often don’t consider content, but it might be down to one of these things:

1) design and content teams working, workshopping and meeting up separately
2) a backdated view or misunderstanding of content as being “just words” 
3) feeling of threat about content design encroaching on traditional design territory

Taking these in reverse, hopefully it’s not often the third reason: which is not only counter-intuitive, it also breaks many elements of “design thinking”, like:

  • be radical – question status quo
  • be fluid, flexible and adaptable
  • try unusual approaches to see what works

Moving on to the second reason, many content professionals now have painstakingly described:

There’s not a lot I can add here, that I and others have not already said several times!

But looking more closely at the issue from the perspective of siloed teams could highlight a cause that comes with its own, very simple solution. I’ll delve further into that shortly.

What a design system that includes content looks like

A 360 degree design system could include:

  • Design principles
  • Design components
  • Content design patterns and modules
  • Content style guide
  • Brand guidelines: logo and artwork usage, typography
  • Brand guidelines: tone of voice
  • Best practice resources

How content boosts your design system

Content patterns

Established patterns allow content formations that work well: clear, usable, accessible wording and presentation, to be reused. You can create a library of modular content with:

  • small elements: for example how to write date ranges, 
  • presentation styles: for example how to present examples and quotes, how to style bullet point lists
  • longer form reusable content: for example paragraphs on an organisation’s stance on a particular issue

Content patterns can also offer a blueprint for multiple content items of the same type. They reuse the same word structures, so they highlight unique content, allowing easy comparison of similar items, like course details, or museum object particulars.

Read my article about content patterns, with practical examples.

Content style guide

Content patterns and modules can be demonstrated contextually and sewn in with design components. 

However, it’s also worth also including an indexed, quick reference content style guide where people can easily look something up. Such as, if it’s OK to use “eg” or better to write out “for example” in full. It’s the second by the way, as “eg” is an abbreviation of a Latin term, which is a double no in terms of readability! What’s more, some screenreading software may read it out to sound like “egg”. 

Similarly, you might wonder whether to put “10%” or “10 per cent”. The second is always better for accessibility, but again it’s Latin and could exclude low literacy and non-fluent users. So your style guide might recommend using “a tenth”, “10 out of every 100” or to state the exact stats. 

Watch Rob Mills’ webinar on creating a content style guide.

Brand guidelines

While we’re putting everything together in one handy place, let’s not forget branding. Brand guidelines will cover use of logo and brand artwork, plus tone of voice. 

Tone of voice, for any brand, is not usually monotone. There’s likely to be a range of tones for different circumstances. You might have an overall tone which is friendly but informative, or, say, fun and helpful. Some brands seem to have a tone which is “eager to please”, some are purposefully silly. But if a customer has not paid a bill, or you are talking to someone about a problem they’re having with your product or service, many general brand tones of voice would need to be dialled down. Or you may want to use a different, separate tone for serious communications. 

By including tone of voice in your design system, with examples of when to dial different tones up or down, you’ll make the design system not just more whole but more useful.

The beauty of including style and brand guidelines in your system is that:

1) you take away the requirement for the user, say a staff designer, to look in 3 different places before they can create an online form, ad or social media post

2) the whole, now complete, design system can be styled consistently, following the advice and expertise of all 3 teams: design, content, marketing

Watch Lauren Pope’s webinar on building a brilliant brand tone of voice.

Best practice resources

No matter how comprehensive your design system is, there will always be scenarios you don’t cover. Including a few design endorsed further resources to reference will stop your users finding and using something you wouldn’t recommend.

So for example you could reference Nielsen Norman Group’s usability research and Content Design London’s Readability Guidelines.

How to fix your design system: work together, content with design

Currently there’s a lot of usage by brands of the phrase “we’re all in this together”, referring to the pandemic we’re experiencing. Countless brand social media posts and emails to customers are deploying these words in an attempt to reach out to their customer base during a crisis.

It would do organisations well to remember this phrase, and turn it in on themselves. Design, stripped to the basics, is how things are presented to the outside world by an organisation. Yet this has been splintered into many disparate parts that often do not work together. You might have a design system, but the marketing team might not use it. They might right now be sending out centred-text jpegs to announce their operational changes in overly formal, complex language! Your organisation might have a style guide, and advocate for clear language in it, but the developers might not read it.

Co-create your design system

Work together. Design alongside content. Start by making a joint Design System. Sit everyone together in the same area of the same building, or book out the largest meeting room you have and work on it there for as long as it takes. Invite marketing to give input at joint workshops and to attend and give feedback at regular progress presentations. 

Have a proper, all-encompassing design system. Otherwise you’re just adding another thing to a design network. And even if you think you’ve clearly signposted the style guide or the brand artwork rules from your system, some users might not realise there’s essential design guidance to absorb and follow elsewhere.

Share knowledge through training and open feedback sessions

Give marketing teams design training and vice versa. Hold a cross-organisational quiz on the style guide. Make sure everyone understands why different teams advocate as they do. If someone understands the logic behind something they’re less likely to think their opinion is superior to expertise from another team that’s based on studies and known best practice. 

Invite other teams to question and feedback, so that they don’t simply assume they can override guidance and publish something that is not consistent with it just because of their own professional take. 

Keep it up

Then keep working together. You’ve made a product as a whole team. Apply that pattern to other work and ways of working. 

I’ve worked in Agile teams where members are from different design sub-disciplines, for example content design, service design, interaction design, graphic design. The organisation had great training programmes and regular sharing of learnings within design communities. But therein lay the problem. It was communities not community. The design sub-communities were very separate. Interaction designers didn’t come to content lunch and learns or in-house conferences. Content designers rarely attended service design meetups, unless they could slip in.

Mix it up. Space might be an issue. So you could hold a series of the same meeting or workshop, with the same proportion of different types of designer at each and then share what came out of each in a digital presentation.

With everyone moving to online working, meetings and webinars while we work from home, it’s the ideal time to invite other disciplines to your team’s shared learnings session.

You might like to read my related articles: Why multi-disciplinary teams are good and The myth of digital transformation.

Design with content

Although I’ve been saying this for a long time, thankfully I am not the only one saying it! Rachel McConnell at Clearleft and Sarah Richards at Content Design London have been banging this drum too. And Lou Downe, ex-GDS Head of Service Design, advocates for an end to end approach to service design. Find out more through the keep learning links at the bottom of this article.

A final word on design systems: test, test and test again

I feel like design systems should come with a warning. Something like:

Caution: you still need to do usability testing!

Good design is about communicating and collecting information clearly. Every piece of information is different. Every design situation is different. 

Having a design system isn’t an invitation to just peel and stick. You need to test your prototype in situ. What works in one context might not work in another. This was heavily stressed by Tim Paul, GDS Head of Interaction Design, at February’s open to the public Gov Design meetup #14: Design systems.

Takeaways

  • Without content, the system is broken.
  • Support a holistic design system, with everything in one place.
  • Work together with other design disciplines and production teams.
  • Test your designs.

Keep learning

🏷️ Tagged as:

, , , , , , ,