Are you making any of these 4 inclusivity mistakes with your docs?

By Catherine Heath on Writing docs from March 27, 2018

Did you know that your docs can be off-putting to certain demographics? Inclusivity in technical writing is discussed insofar as using gender-neutral language but encompasses many other aspects.

Much has already been made of inclusive language in job adverts. This relates to how our choice of words attracts a certain type of applicant, and deters certain people from applying. Applicants deterred are usually women. This understanding can be applied to technical writing.

Use of language is well-known as a persuasive technique. It should be no surprise that the words we choose shapes and defines audiences in ways they are not always conscious of.

Being inclusive means creating a welcome atmosphere in your docs for as many people as possible – regardless of race, age, gender, nationality, religion, political views, or any other kind of demographic.

It doesn’t mean diluting your language so it has no character, but empowering anyone and everyone to become a user of your product.

1. Too much assumed knowledge

Photo by Janko Ferlic from Pexels

First, your docs will be less effective if you assume too much prior knowledge before someone can find value in them.

Of course, some docs aimed at certain professions (such as highly trained professional engineers) should be pitched accordingly. But even these types of docs may be excluding many users for their use of excessive jargon and assuming too much knowledge.

It’s important to appraise the likely skill level and experience of your target users, whatever your field. Then you can pitch your docs correctly, minimising the chance that you provide too much information or too little. You can also take other precautions in case someone unexpected arrives at your docs. This is how you make your docs as inclusive as possible.

Solution: If there is prerequisite knowledge to using your docs, state this in your introduction of the content, and link to further information. Use interlinking throughout your knowledge base to reveal more of your Information Architecture and point to further reading. This way, your users are empowered to take initiative over their learning.

Surprisingly, some organisations intentionally make their docs difficult to access. This makes docs more of an initiation test for new users rather than a self-service resource, and success is defined by your determination to succeed.

Most companies want to avoid this approach since they place a premium on usability. Every user has the right to use your docs, and lowering the barrier to entry will make your knowledge base more inclusive.

2. The register you use is too high

Image source: Pixabay

Register refers to the formality level of your writing, and determines how easy your docs are to read. The higher the register, the harder your users’ brains have to work to decode the information.

Technical writing has a legacy from academic writing. It’s conventional to be as formal as possible since this is thought to establish more authority. While this may be suitable in some cases, if you write very formally you run the risk of sounding very old-fashioned, when all written publications followed a certain style.

Not only is this off-putting to many people and hindering for comprehension, expecting people to be educated to college level to decode your documentation is unwise.

Solution: Some people may resist and complain, but the style now is to write relatively informally. Go for an ‘informal’ tone rather than ‘familiar’, as this will keep your documentation professional whilst making it accessible. Writing clearly and simply is not dumbing down – it makes your language more accessible.

3. Not using inclusive language

Image source: Pixabay

Some people may feel that the concept of inclusive language is too difficult, interpreting this as pressure on them to be ‘politically correct’. The truth is, with patience and learning, you can make your language automatically inclusive. Eventually this will require no extra effort from you.

It’s possible to get away with not using inclusive language but you will be then placing the pressure on your reader to make the extra mental leap to imagine themselves as your intended audience.

Being inclusive in your documentation reflects how language evolves over time. Using outdated forms of language is misleading at best, and exclusionary at worst. Putting in the extra effort when creating your documentation relieves the burden on your user later down the line.

Solution: Focus on clarity for the reader rather than sticking to any arbitrary standard (unless that standard promotes clarity). Imagine that your audience could be from literally any demographic.

Lots of documentation refers to the masculine gender as default, but avoid relying on masculine pronoun. You may not think it matters much, but it reinforces persistent social stereotypes such as women being less competent than men, or uninterested in using technology. It means women may not think they are your intended audience, even if they are.

Many technical writers opt for ‘she or he’, ‘they’ (although this is technically grammatically incorrect) or refer to ‘the user’. It’s important to note that ‘he or she’ is also discouraged on the grounds that you are excluding non-binary people.

The use of the ‘they’ pronoun causes some people to react badly because they believe following the grammar rule book is more important than inclusion. The reality is that the rule book is limiting and exclusionary, and language changes over time anyway.

Avoid referring to gendered job roles such as policeman, fireman, mailman, matron or stewardess. Use the gender-neutral version such as police officer or firefighter. Avoid stating gender where it is not needed, such as ‘woman doctor’ or ‘male nurse’.

You can be inclusive in terms of gender but also for identity and sexual orientation. For example, using ‘husband’ or ‘wife’ instead of ‘partner’ or ‘spouse’ may assume your audience is heterosexual, or married rather than simply in a relationship or cohabiting.

To be inclusive of different nationalities, avoid using slang or pop cultural references unless you explain them or link to a reference. This otherwise excludes people with different cultural backgrounds, or who are non-native speakers of your language.

The University of Flinders has a great guide on how to use inclusive language, as does the University of North Carolina.

4. Not using inclusive imagery

Photo by Andrii Nikolaienko from Pexels

Imagery can be expensive to produce, while stock images may not showcase the most variety among individuals. You have an inclusivity issue when your technical imagery only reflects a narrow subset of your true audience. This can lead to entrenched habits that are hard to shake when your business matures.

Nevertheless, 60% of people are visual learners, and the pressure is on to create visual docs.

Solution: It’s hard to visually represent every possible person that might use your docs. If you have the budget for it, try to use imagery that showcases a variety of people. Slack and Airtasker both are shining examples of inclusivity in design.

Airtasker consciously came up with new set of diverse characters to illustrate their community. The team wanted these characters to be as representative and inclusive as possible of their users, including skin color, sexual orientation and body type.

This is the result:

Slack has showcased its conscious decision to use emojis with brown skin in its marketing. This was an impulsive decision by a single designer but Slack has an inclusive culture and strongly encouraged them.

Brown is not the default skin colour, and is usually chosen when specifically targeting a black audience. But this does not reflect the true diversity of users, who may be a huge variety of skin tones. Making the design choice to designate one color as ‘typical’ is a lot of pressure and the answer may be to go for a variety of ‘characters’ like Airtasker.

It’s important to remember that using imagery is in itself potentially exclusionary – it excludes certain groups of people from using your docs such as visually-impaired people relying on text-to-speech software.

Over to you!

Every time you use non-inclusive language or imagery, users that fall outside your pre-established definition need to do extra mental legwork to see themselves as your intended audience.

The only solution is to think very carefully about how you word anything in your technical writing. You should be doing this anyway. The key is to focus on your potential audience at all times.

At the same time, avoid making a point with your choice of inclusive language. Your inclusivity blend into the background, part of your overall values and culture.

This is because the way you style your technical writing reflects the values you hold as a company. Many people may not be consciously put off by un-inclusive docs – but there are also those who will be wildly excited by your inclusivity. These people become your most loyal customers and advocates.

Photo by Tirachard Kumtanom from Pexels. This work is licensed under a Creative Commons Attribution 2.0 Generic License.