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.
We’ve just uploaded a free video guide on Getting Customers to Answer Their Own Support Questions.
The guide is free. You just need to register and log into our elearning platform.
See: Getting Customers to Answer Their Own Support Questions.
Agile Authoring methodology: Learning from Lean
You’ll find the other recordings on the Agile The Docs webpage.
Listeners to BBC Radio Four this morning heard a report that a new study by researchers at Sheffield Hallam University (SHU) discovered comics are a better educational resource than traditional textbooks.
In a related article, called How the humble comic book could become the next classroom superhero, SHU’s Paul Aleixo explained:
“We found that the use of comic books actually enables students to better remember information. Our research showed that the students that read a comic book version got more memory questions correct compared to when the same information was presented in text format alone – or in a combination of random images and text.
This shows that the way comic books are structured – to include a special combination of words and pictures in a certain sequence – increases students’ ability to remember information.”
The key word in the section above is “remember”. The purpose of a user guide is not necessarily to get the reader to remember, but to solve their problem. We want them back working as quickly as possible. Indeed, one of the key principles of Minimalism is “Support reading to do, study, and locate”.
Having said that, there are some interesting findings in the study:
“There are good theoretical reasons why comics might be better at imparting information to students. A lot of which has to do with what the influential cognitive psychologist, Allan Paivio, called “dual-coding theory”. This is the idea that we deal better with material which is presented in both a verbal and a visual manner.”
This means good layout and using graphics will help the readers of user guides.
Certainly for learning materials, comics can be very useful. Indeed, we’ve created a number ourselves.
What has been your experience of using this medium?
Adobe has officially released the Adobe Technical Communication Suite (2017 release) including the new 2017 releases for Adobe FrameMaker, FrameMaker Publishing Server (2017 release) and RoboHelp. It has also released the 2.0 Release of XML Documentation Add-On for Adobe Experience Manager.
There have been a lot of improvements to the usability of the applications, reducing the number clicks required to carry out tasks.
For both FrameMaker and RoboHelp, Adobe has continued its developments in publishing HTML 5 output and personalised Help content. RoboHelp has a new, frameless Responsive HTML5 layouts that offer more intuitive navigation, and the ability to filter content dynamically. There is also a significantly improved search, which now has autocomplete.
It’s good that Adobe has focused on improving the usability this time – for Technical Authors and for the end users. It must be tempting to keep adding more to an application, when the best gains can be from improving what already exists.
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.
Advanced technical writing & new trends in technical communication training
Adrian Warman has started a series of posts on his blog about the future of technical writing. In today’s post, Farewell to the technical writer, he argues the traditional role of a technical writer is no more:
“Marketing and sales specialists, designers, developers, developer advocates, support and operational people – indeed almost anyone associated with the overall creation and delivery of a service or product – are all perfectly capable of creating content that might not be perfect, but is good enough.”
There are many good points in Adrian’s post, and we look forward to the rest in this series. However, there is a counter argument to be made:
- Why do organisations still buy Flare or RoboHelp, when they could use Markdown? We would suggest it’s because projects often become more complex over time. You start to need support more than one version of a product (the professional and the standard version, for example); you need to support more than release version; you end up developing bespoke versions for your biggest customer; you need to localise the content for international markets. As the products become more complex, so can the documentation, and it can be a struggle to manage this complexity in an efficient way with Markdown.
- While the writing can be straightforward, the publishing process for Markdown content can be complex.
- If people have two responsibilities (code and write user content), one of those tasks may be not given the time and attention it needs. It might be better to have one person focusing on a single task.
- Only half the time in a documentation project is actually spent on writing. There’s a lot of planning and research that should go on before that into what users need from the content. Programmers may struggle with that aspect (although UX developers less so).
- A Technical Author might be cheaper than a programmer or a UX developer. If you can free their time, by delegating the writing activity to a Technical Author, you might enable them to focus on more productive activities.
The traditional role of a Technical Author is certainly changing, and there is likely to be a more collaborative authoring process. However, the Technical Author can still add value.