I bring this article to you courtesy of Ellis Pratt, as I think it adds relevance to what I am setting out to achieve with my documentation framework.
Technology has changed enormously over the last 70 years. But have technical communication standards kept up sufficiently to reflect these changes? It appears that some of the most successful software companies are breaking generally accepted best practice in technical writing – a trend that clearly should get us thinking.
If you were going back in time twenty or twenty five years and found yourself in a classroom learning about technical writing, you’d probably find it was almost identical to classes on this subject offered today. Technical communicators tend to assume that technical communication best practices, which have been taught for the past 25 years, and even further back in time, are still appropriate today.
Yet, there are developments that are prompting the question if the commonly accepted approaches are still the best way to go in all situations.
Let me list a few examples:
- Mozilla, the developer of Firefox, reported that a change to a more conversational and friendly style of writing Help topics resulted in a 13.1 percent increase in page hits. The re-written pages were helpful to 800,000 more people per year, providing a significant reduction in support calls.
- Other leading web-based companies, such as Twitter and MailChimp, have Help topics that are breaking the rules of traditional technical communication best practice.
- At the tekom 2013 conference, Melanie Huxhold and Dr Axel Luther of SAP reported that more users were viewing SAP’s screencasts than reading the Help pages. In other words, a medium that is more verbose and harder to use for searching specific information, was more popular than the online Help.
- User documentation is often criticized for being boring and old-fashioned, and there is a commonly held belief outside of the technical writing community that “no-one reads the manuals”, that we create something of uncertain value.
How we got to where we are today
If you look at the timeline of technical communication standards, you’ll see that most of these standards emerged from the aerospace and mainframe computer industry sectors between 1960 and 1990. According to the xml.org website even DITA is based on standards from this period.
These standards were written when technology could be described as big and scary for many users. When things went wrong, the consequences were usually expensive and sometimes even dangerous.
A focus on efficiency rather than quality
In recent years, the focus in technical communication has mainly been on improving the efficiency in producing content. You’ll hear conference speakers using the Ford Model T motor car as a metaphor for how technical communicators should take a more engineering approach.
Unfortunately, there’s been less focus on improving the value of the outputs we create. Here, we can also learn lessons from the Model T. By 1926, Ford had been overtaken by General Motor as the leading car manufacturer in the USA. They had ended up with an efficient way of creating a car that fewer and fewer people wanted to buy. There’s a danger we’re making the same mistakes as Ford did with the Model T.
Our changing relationship with technology
Technology is evolving
In his presentation, “Technology’s epic story”, Kevin Kelly argues that technology is following an evolutionary path over time, similar to humanity’s biological evolution. We can use the five key forces in evolution to create a simple radar chart.
We can describe the shape of technology in the second half of the 20th century as looking roughly like this:
Figure 1: Radar chart measuring traditional technology by the five major attributes in evolution.
Products tended to specialize in one function, and work under different operating systems.
Today, a great deal of consumer technology is ubiquitous, even mundane. The shape of the diagram for these products would resemble this:
Figure 2: Radar chart measuring recent technology by the five major attributes in evolution.
Users are changing
As technology has become part of everyone’s daily lives (particularly web and mobile applications), most people’s relationship regarding technology has changed.
Many people now regard technology as something that should just work. When it fails, with many products being so much cheaper than ever before, they’re more likely to stop using it, even throw it away, instead of trying to fix the problem.
Today we also see more tech-savvy users. These users want to do more than to be functionally competent; they want to master a product. They might also be inclined to tinker and make it do things the manufacturer never intended.
How products are sold is changing
Research shows a large number of people tend to search for the solution to their problem before they buy a product or service. This means that we’re seeing a new marketing funnel emerge. Google calls this the “The Zero Moment of Truth”.tcworld magazine recently reported on this trend in the article “A business case for technical communication – facts & figures”.
Technical content is now seen as the start of the customer journey, because it’s providing information that’s important to the prospect. This means the content that technical communicators produce must serve an additional function: provide the answers to people’s problems in a way that also promotes products and services.
Towards a new model of technical communication
When products no longer fit the “big, scary and expensive” description, and when users are more competent, a new model of technical communication may be more appropriate.
Design-led documentation
Some organizations are taking a more design-led approach to user documentation. Citrix, for example, has been one of the first documentation teams to adopt this approach. Citrix’s Senior Information Experience Manager, Mathew Varghese, describes how its technical documentation team is becoming an “Information Experience” department. For Citrix, Information Experience is a way of empathizing with users to understand their needs and assisting them through the whole customer journey.
The company’s goal is to provide the right content to the right user, at a time of the user’s choosing. This means a more immersive user experience, moving away from confining user assistance to a traditional user manual or Help file. It includes looking at how content can be delivered in the User Interface, in forums, through videos and blogs.
Affective design models
Other organizations are changing the tone of voice and are adopting a more conversational approach in certain places in their user guides. For example, the writers at Mailchimp.com first identify the likely emotional state of the reader of a page, and then use a tone of voice best suited to that state.
A nuanced approach
Does this mean you need to abandon DITA or Minimalism? Not necessarily. The new approaches mainly lead to a change in the way introductory and conceptual sections are written. Task information and the procedural steps usually remain unchanged.
The traditional approach is probably still the best approach if your users are anxious or frustrated when they start to read your content, or if you are documenting products where mistakes can be expensive or even dangerous.
Challenges for technical communicators
These new approaches can create some challenges for technical communicators, particularly in an international context.
Unless it is managed carefully, a more conversational tone is likely to lead to a greater use of idioms in the content. This can create further challenges for localization. For example, on the “Getting started with Twitter” Help page, you’ll find a section called “GET FANCY: Explore advanced features”. “Get Fancy” is a phrase that, I suspect, would tear many translators’ hair out.
Users in some cultures might take offence at content being written in the second person, informal voice (for example, using the “Du” form of “you” instead of the more formal “Sie” in German). Even in English, the levels of formality accepted by users in different countries can vary.
This means, clear guidelines need to be given to writers on how to write these more informal topics in a culturally acceptable way.
Conclusion
Technical writing, and the nature of the content we provide, is changing, as users’ relationship with technology evolves. This means that what we teach as best practice in technical communication needs to reflect these changes.
With web analytics, user feedback and usability testing, we have the ability to analyze user behavior and gain a more detailed understanding of users. We have the opportunity to identify the situations where the nature of the content we provide – the tone of voice and how content is delivered – should change so that it better meets the users’ needs.
