Today, we’ve released our latest training course – Writing skills for developers. The course teaches developers the key skills of technical writing for software user documentation.
Although it would be better for a professional technical communicator to write the end user documentation, for some organisations, this isn’t always possible.
It is for developers who:
- Need a solid understanding of the fundamentals of technical writing
- Want to communicate more clearly and effectively
- What to know how little, or how much, they should write
- Want people to answer their own Support questions
The course comprises 14 modules in total, which delegates can complete at your own pace. The course modules are delivered over the Web in small, manageable video presentations. The course handouts and exercises are downloadable as Word or PDF files.
We can also deliver this course as a classroom course for development teams.
For more information, see: Writing skills for developers training course.
In researching what developers wanted to learn about writing documentation for users, the most common issue related to how much, or how little, they should write. One developer said:
“I would want to know what is the minimum I should write. If you can persuade me what is the necessity of each thing I’m capturing, and the voice I should use to make it most acceptable, I think I’d tune in.”
We’ll look at this question in the Writing Skills for Developers course, which we will be releasing soon. In general, you need to:
- Meet the legal requirements (which differ depending on the product, and the country).
- Provide enough information so that users don’t give up using your product, if they get stuck. For example, how to install the software, and how to get started.
- Consider the support calls, and whether you could avoid any of those by having good user documentation.
That might appear a bit too vague, so let me go back to one of the sentences above:
“If you can persuade me what is the necessity of each thing I’m capturing”
Before you start writing, you should define the purpose and audience for each deliverable you create. There should be a use case:
- Without documentation, is it clear what the user should be doing? is it clear what the user should be doing first?
- Is it clear how they should be doing the task?
- When they have to choose between options, do they have enough information to make the right decision?
- When they have completed a task, do they know what to do next?
- Are there any concepts or terms the user might not understand?
You can assess what topics to cover by doing some basic usability analysis. However, if you think about the tasks, the process (workflow), and any unfamiliar concepts, you will be on the right track.
In his newsletter last week, internet psychologist Graham Jones mentioned research that had looked into what makes some web content more shareable than others.
The researchers had analysed articles on Medium, and found there were several key factors.
One was the length of the content – around 1,800 words ( approximately 7 minutes reading time).
Another was the the “reading age”.
“The study on Medium shows that the content that gains the most engagement has a reading age of 11.”
In terms of their reading age, how old are your readers?
Graham also said:
“Typically for most business websites that I examine the reading age averages around 17 years…The Times newspaper has a reading age of 12; the Daily Mail has a reading age of 10. The reading age of the script on the 10 o’clock news is about ten as well. It is no coincidence that the world’s most popular media have low reading ages. Whatever you might think of the BBC or the Times or CNN or your favourite magazine, one thing unites them all – low reading ages. Most websites have language which is far too complicated.”
Of course, it’s not always easy to describe complicated things using simple language. We may need to describe tiny differences and modalities. However, we should aim for clear and simple language as often as possible.
A related factor was the number of words in a sentence. Graham reported the study found that the most shared content was that which had sentences that were between 12 and 15 words. This matches with best practice at places such as the Government Digital Service, where the aim is to write 11 words per sentence.
Even if your readers are much, much older than eleven, it may be a good idea to pretend they are.
Discover the advanced new writing styles emerging in technical communication by attending Cherryleaf’s popular training course. Don’t get left behind: past clients include technical communicators from Citrix, GE, IBM UK, Lloyds Banking Group, Sage plc, Schlumberger, Tekla and Visa International.
The next public classroom course will be held on Wednesday 29th March 2017 at our training centre in central London (WC2R).
For overseas clients, we will hold a class live over the web (on 22nd and 23rd March), if there sufficient interest.
Please complete our single question survey:
[colorvote id=”4″ style=”wpcvp-poll”]
— Lee LeFever (@leelefever) October 30, 2016
In the olden days, every family had a record player (also known as a “turntable”), and pretty much everyone knew how to use it. However, if you look at the Customer Questions & Answers section for a turntable currently on sale on Amazon, it’s clear that many people today don’t know how a turntable works, or what it does. Common knowledge sometimes isn’t as common as people think.
Last month, we were asked by a client to deliver our API documentation course to their team as a classroom course. Following on from that, we are now able to offer this one-day course to other companies, in this manner. The course currently varies from our online API documentation course. It includes more content on information design, and research into the different types of users and their needs.
Contact us to find out more.