Achieving human parity in conversational speech recognition has further to go

Microsoft is in the news for claiming its artificial intelligence (AI) technology can now recognize conversational speech slightly better than humans who do so professionally. Its technology now has an error rate of 5.9%, which it claims is the same as a trained transcriptionist. That equates to roughly one error every 20 words. So does this mean the typed word is going away?

We have our doubts:

  1. To be qualified as a stenographer, you must be able to transcribe with an error rate of 0.1% or lower. That’s a single mistake every four pages. Microsoft’s error rate of 5.9% isn’t acceptable for live transcription.
  2. Microsoft was working in a controlled environment, with relatively little background noise.
  3. Speaking for long periods of time is more tiring than writing or typing.

So it seems like there’s a lot of work still to be done.

Reviewing and Editing Technical Documents Course – Update

We’ve started work on the next course to be added to the WriteLessons bundle of online training courses – “Reviewing and Editing Technical Documents”. In this situation, we may try an experiment and release each module as it is completed, rather than publish all the modules in one go.

The modules will be: revising, editing, copy editing, proof-reading, getting documents edited, possibly measuring the effectiveness of documents, and managing updates. More news when we have it.



New classroom-based API documentation training course

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.

Have Amazon, Dropbox, Microsoft and Google got their information design wrong?

On an API documentation course we ran for a client yesterday, we showed a number of developer documentation websites, including ones from Amazon, DropboxGoogle and Microsoft. One common theme the delegates noticed was these sites contained a in-page table of contents, or a set of related links, on the right hand set of the screen.

Dropbox API documentation page

You will often hear Information Designers talk about F shaped reading, and that the right edge of the screen is ignored by users. If you put content there, they say, it probably won’t be seen by the readers.

So have Amazon, Dropbox, Google and Microsoft all got it wrong, by using the right edge of the screen to provide navigation? Have the improvements in screen technology and the introduction of tablets and smartphones changed which areas of the screen users notice?

What do you think?

Documentation as an API – the docsbot

In a recent presentation, Twilio’s Jarod Reyes and Andrew Baker mentioned their plans to make Twilio’s developer documentation available as an API. They plan to start with an API for code samples, stored in a github repository.

Making documentation available as an API means means users can create or remix their own versions of the documentation. For example, they could embed Twilio’s code samples. It also means those embedded code samples will be updated whenever Twilio updates those snippets of code.

Jarod and Andrew suggested something new that we’d not heard before – the API can also be used to create a “bot” in Slack, to help new users. The Twilio bot, currently in development, is called docsbot. If users type “lookup py” in the Slack command line, docsbot will reply with a message containing a code sample for the Python development environment.

Twilio's Slack docsbot

It relies on users knowing the relevant Slack commands, but it’s an interesting way of providing users with documentation when and where they need it.

See also: Advanced technical writing & new trends in technical communication training course 20th October

Customer Journey Mapping and technical communication

A technical communicator’s lot is usually to create content for helping users, and, if they are lucky, do some user testing of it in order to make future improvements. It is not that common for them to be able to look at the bigger picture and think about how the user gets to that information in the first place.

Customer Journey Mapping is an extremely useful way to understand and improve the customer experience. It involves creating a document (often a spreadsheet) that describes the user experience from their perspective. It can record each point at which interact with your service or product, the quality of that experience, and what happens next.

Customer Journey Mapping is something we carried out recently for a client, and it was a topic that came up at the TCUK 2016 conference, in the presentations by both Sarah Richards and Simon Anstey.

Our client is a start up Software as a Service company that is growing rapidly. They are creating new products, gaining new customers, and they are having to face all the challenges that brings. We mapped the journey of a user who wanted to install the product. We used a spreadsheet to record each stage and any issues or problems that users came across. The user began at the company’s website, where there were various links for installing the application, including instructions on how to do that. It revealed there was confusion between the product available on Amazon Web Services and the product clients install in-house. This was because the same, or similar, terms were used to describe the products themselves and the features contained within the products. On some pages, users were directed to the Support desk system and the articles contained there. On other pages, they were directed to PDFs, which described how to install the previous version of the product. There were also a few pages that took them to the online Help system. The Customer Journey map made it easy to change the website so it directs users to the single place for information, and to remove duplicate, and out of date, information.

In Sarah Richards’s presentation at TCUK 2016, she described the approach the Government Digital Service took when they developed the website. GDS removed content that didn’t address those needs, and consolidated hundreds of government websites into the single site. They kept 45,000 pages, and culled 92,000. This process started with user needs, and were designed around those customer journeys.

Sarah’s TCUK 2016 slides aren’t available yet, but here is a similar presentation she gave at another conference:


In Simon Anstey’s (of SAP) presentation, on eliminating Support tickets, he described how he looked at the customer journey for raising a Support ticket, and collaborated with SAP’s customer support team to improve the documentation, and links to useful information, for some critical products. This stemmed the flow of support tickets. They estimated the resultant cost savings and started gaining management’s interest. This activity meant they could show what value documentation was adding.

Customer Journey Mapping can be revelatory in revealing issues that may not be obvious at first glance.