STC Summit day 1 – What is the role of a technical communicator when everything just works?

I’m attending STC 2012, the annual conference of the Society for Technical Communication. For the last session on Monday, I chose to attend “What is the role of a technical communicator when everything just works?” by Ellis Pratt of Cherryleaf.

For me, this was the crux of Ellis’s presentation: When we write documentation, we make the assumption that the thing we’re documenting is big, scary, and likely to break. Now there’s a new model, or a belief in this model: “It just works”. It’s not even technical these days, it’s just product. Whether this belief is right or wrong, we need to take it into account.

Ellis covered the following topics:

  • Is our profession in an existentialist crisis
  • Evolution of technology
  • Brief history of technical communication
  • Your organisation believes its products ‘just work’
  • Learning from other professions

Ellis mentioned that his presentation includes research from other speakers in recent conferences: Adrian Warman and Briana Wherry.

A crisis in tech comm?

Is the technical communication profession in an existential crisis, and are we still needed? Ellis showed a graph depicting the number of vacancies for technical writers, as a percentage of all IT jobs. The demand for technical writers has reduced to about half what it was 8 years ago. The graph was based on UK data, but Ellis thinks the situation is similar in the US too.

How is technology evolving? Ellis recommended the video by Kevin Kelly called “What does technology mean in our lives“, available on TED. The message is that technological changes can be compared to those in evolution. Technology too goes through spurts of specialisation, complexity, ubiquity, and so on.

A quick history of tech comm

As a profession recently, we’ve been trying to analyse what needs to change in technical communication. To help this, Ellis sped through the history of technical communication. In an attempt to document complexity we developed a number of standards such as STOP, Information Mapping. Then the big change happened: the move to PCs. We introduced minimalism, and tools for technical authors including F1 help, SGML, FrameMaker. With Windows, we got the first help authoring tools. Then with Internet Explorer, we got HTML Help (CHM files).

Now came Google. This heralded a new change such as user-generated content, software as a service. And DITA – this is all about what happens under the surface, not about presentation. Now we have YouTube. A client asked Cherryleaf to write documentation for a mobile phone app, that should look more like marketing content than technical documentation.

Google produced the comic as a user guide for Chrome – a significant experiment. Anne Gentle wrote her book about documentation, community and conversation. Siri came along. And Joe Welinske wrote his book about mobile content.

So now we have two models side by side:

  • It’s big and scary
  • It just works

Then there’s the “maker generation” – they glue things together that weren’t really designed to be used together.

It just works?

By “just works”, Ellis means a product that is intuitive to operate, and does the job effectively and efficiently.

Let’s say your organisation believes their product “just works”, and you can do away with the manual. What can you do when your employer says something like that? It depends whether they’re right or wrong.

If they’re right:

  • The traditional writing model may not work.
  • The way we justify our existence may not work.
  • We need to change our assumptions.
  • Customers don’t call support.
  • The product may become a commodity. If the product doesn’t work, people just throw it away. This can be dangerous commercially, as your product can be trapped in a downward commodity cycle.
  • Technical documentation becomes part of the brand. We need to contribute to the brand of the product. More, we may be part of the marketing team. Take a look at the Mozilla Help, which has a specifically marketing tone. You need to use more idiom in the language, be more engaging.
  • Marketing is perhaps not so different from tech comm as we may think. See the advert for Coca Cola Content 2020. The content of the video displays the same concerns as those of technical writers.
  • Apps that are “cool” provide plenty of help, but the help elements are part of the user interface (UI). And there are 2 extra factors: A social element (for example, share questions and answers with other users) and the fact that the help is provided in context. Technical writers may need to muscle in and “own” this sort of user assistance.
  • Technical documentation moves into the training arena. The consequence is that you explain only the concepts.

So if they’re right and it “just works”, we are still needed. Our functions:

  • Explain unfamiliar concepts.
  • Explain how to hook up and hack products that were not designed to be connected.
  • Help the product avoid being a commodity.
  • Differentiate our product from the competitor.

What if they’re wrong?

What if our employers or the developers tell us the product “just works”, but that’s not true? Not all products work simply. As technical communicators, we need to compensate for the lack of simplicity, explain how the additional features provide extra flexibility, and clarify the complexity.

When talking to our employers, we can ask them to draw their evolutionary map from complexity to simplicity, and compare the product to the products that they admire. In that way, we can come to an understanding of the complexity/simplicity of the product.

In summary

We are in a world where things are shinier and simpler. We need to provide different, shinier outputs, and we need to fight to be the people who do this. We may need to acquire new skills.

Thank you Ellis for an amusing, enlightening, thought-provoking and heartening talk.

About Sarah Maddox

Technical writer, author and blogger in Sydney

Posted on 22 May 2012, in STC, technical writing and tagged , , , , , . Bookmark the permalink. 12 Comments.

  1. Thanks for these great updates, Sarah! I almost feel like I’m there 🙂

    • Hallo Nathalie
      I’m glad you’re enjoying them, Nathalie. This is my first time at an STC Summit. It’s a good conference, with great people.
      Cheers, Sarah

  2. I take the point but I always see this problem for mass market software. The traditional role is still there. I have always worked on large and scary products, with a small number of users, which just get more complicated and scarier.

  3. Hi Sarah, good review of Ellis research and insight. I have enjoyed his contributions.

    Just curious to ask from your point of view, while Ellis highlights changing needs with documentation, I wondered how documentation of this sort would work in a form of Computer Aided Education, in other words, the training material used by people to learn about “unfamiliar” concepts.


    • Hallo Peter

      I think that’s a very interesting point.

      On the one hand, I’m tempted to say that computer-aided education focuses on the “how” rather than the “what”. So it wouldn’t have much place in a world where everything just works, and all you need is the conceptual overview.

      On the other hand, there are some very innovative types of computer-led training that would work in teaching primarily concepts. Gamification may play a hand here.

      I’ll ping Ellis to see what he has to say too.


  4. Actually, part of what lead me down this path was the changes in the learning profession. People like Nick Shackleton-Jones at the BBC (and now BP) have been promoting the idea of Affective Learning. This suggests that you need to get learners emotionally involved in the learning, by using a friendly tone, being engaging. The key factors are emotion and engagement – your content should be written in a way that achieves this outcome.

  5. communicationcloud

    Hi Sarah,

    Firstly, thanks for taking the time to write this up – it’s really useful for those of us who couldn’t be there:)

    This topic has been on my mind for a while, and there are a couple of additional comments I’d add to Ellis’ thoughts on this are:
    1. There are organisations who can realistically aim for products that pretty much do “just work”. I see this as an opportunity for technical writers, though, rather than a threat – part of making the product easy-to-use is building in the learning and troubleshooting … and this is exactly what many technical writers are excellent at! Of course the official job title for our new role in this might not be “technical writer”…

    2. In many cases, making a product that “just works” is only a first step towards reducing the information that’s needed. Many software and technology products are designed to integrate with other systems or products, and most are designed to integrate with tasks in everyday life (e.g. appointment-booking software might need to integrate with external calendar software as well as working with the people-side of the processes involved in making appointments). And at these integration points people still need information to help them understand how the product interfaces or what range of functionality is possible.
    By the way, if you’re interested in this, I wrote a bit more about a while ago: “3 good reasons software will always need help” – (written in 2009, but still valid, I think).

    So, my take on this is that is that I agree with Ellis: although we are heading towards a world where products become more intuitive to use, I don’t think that means technical communication is done for as a valued profession:)

    • Hallo Rachel

      Thank you for the link to your post. It has a number of very good points, well worth a read for anyone interested in this thread.

      The point about documentation being part of the purchase decision is a particularly interesting one. People may need to read the documentation before they even have a chance to download and try out the application. It’s interesting, because it ties in with another theme in tech comm discussions at the moment: How our role relates that of the marketing writers.

      I’m finding more and more that part of what I write needs to sell the product: the release notes, the introductory pages to each product or feature, for example. Also, our technical writing team has an excellent relationship with the marketing team, and we often review each other’s work.


  1. Pingback: STC Summit 2012 wrapup – STC12 « ffeathers

  2. Pingback: Perspectives on Summit 2012, Wendy Ross - STC Rochester

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: