We’ve been experimenting with another spreadsheet for calculating the Return on Investment (ROI) on User Assistance.
We wanted to look at: how many support calls an organisation needs to have resolved by users reading the Help content instead of calling Support, before it starts to see a return on the cost of creating the Help.
Using typical costs for an average sized software application, the figures suggest you could break even if you avoided 3 support calls per week.
Contact us if you’d like a copy of the spreadsheet, so you can make your own calculations.
You also find a related Support call cost reduction spreadsheet on the main Cherryleaf website.
We’re planning to have some new laptop stickers printed. We’ll give them away to anyone we meet, or post them to anyone in the UK who’d like a sheet.
Here is the draft design:
What do you think of the designs? How could they be improved?
Here is an interview we carried out with Mark Baker, author of Every Page is Page One. The interview is interspersed with audio snippets from Day 1 of the UAEurope 2017 conference.
- Caroline Loverage (Thermo Fisher Scientific). Teaching by Example: Worked Examples in the Documentation of Complex Systems
- Kelly O’Brien (Kayako). Practical Information Architecture: Building Templates For Better Content.
- Helena Pichler (Nominet). AsciiDoc to Responsive Webhelp: Agile documentation for small teams/
With thanks to Matthew Ellison and Mark Baker.
The content management and single sourcing challenges for the UK Parliament:
However, all is not quite what it seems:
“Just when you thought Goatgate had been cleared up, along comes the official line: It is not on vellum anymore. It is on “goatskin parchment paper” but confusingly it’s not actually goatskin. However it is very high quality, thick paper, which is why the ink takes several days to dry, and it then needs to be bound into a booklet, before being sent on to Her Majesty for signing. So it did have to go to the printers last week. And the paper does have the watermark of a goat”
See: How the Queen’s Speech got my goat.
Prospective customers today know more about products than they have ever done. Many people tend to search for the solution to their problem on the Web and through Social Media before they buy a product or service, and many of them never even touch the product before buying it. This means the “marketing funnel” has changed into a loop. At different points in that customer journey loop, User Assistance can help people move from being prospects to be customers and advocates:
Bri Hillmer has written two articles on Just-In-Time documentation (https://www.knowledgeowl.com/home/just-in-time-documentation-a-practical-guide and https://www.knowledgeowl.com/home/just-in-time-documentation). This is an alternative to what she called Just-In-Case documentation. The idea is you write topics that answer real world queries users ask the Support team. This rather than writing a comprehensive user guide, just in case someone wants to know about topic X or topic Y.
This approach focuses on user needs, answering the questions user have. It also provides users with worked examples, each one aimed at solving a particular scenario. In a complex environment, users may need to combine a set of functions or features in order to solve their problems. Sometimes a topic-based approach doesn’t provide that type of information. Just-In-Time documentation could help users understand individual features and how to combine them. And it may be that 80% of the queries relate to 20% of the product’s functionality.
However, this approach does require the technical authoring team to be able to turn around these articles quickly enough. It’s likely that similar topics will come up a regular basis, so there also needs to be a way to reuse some passages of text, in order for the Technical Authors to work in an efficient manner. Also, there might be a legal requirement to provide a comprehensive guide.
Is this an approach you have used? If so, please share your experiences, using the comments box below.
Earlier this month, we started the Cherryleaf podcast, and we’re currently publishing a new episode each week. I thought it might be useful to explain why we’ve done this, instead of publishing videos.
For the audience members, they are able to do something else at the same time as listening to a podcast. For example, you can listen to it in the car, while walking the dog, or lying in bed. I’ve found them to be a godsend when I’ve been waiting around at airports. Video demands more attention from the audience. This means podcasts generally make it easier for people to listen for longer periods of time.
As a result, podcasts are very popular. Although there are some very good podcasts on technical communication (such as Ryan Weber’s “10-Minute Tech Comm”), we felt there was room for at least one more.
For us, it opens up the opportunity to record outside the office. We don’t need to worry about lighting, framing, and the other issues that can come with recording video. It’s also easier to interview guests (something we hope to do in future episodes), when you all you need is a decent audio connection. This means it requires less time and effort to produce the content.
The frequency and the topics we cover will partly depend on you, the audience. We’ll stick with the weekly schedule for the next month or so, and then probably move to a monthly release cycle. We’ll be able to look at which episodes have been downloaded more than others, and gain an idea of the most popular topics. It will, of course, also depend on whether we run out of things to say.
We’d love to interview documentation managers and technical communicators, and include their opinions in future podcasts. So if you like to discuss taking part in a future podcast, do please contact us.
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.