“Bake your taxonomy” workshop at #tcuk13

Knowing your audience, their needs and use cases is key, not only when writing documentation, but also when designing its topic structure, navigation structure and taxonomies. That’s the insight  around 50 participants came to at the end of the “Bake your taxonomy” workshop which Chris Atherton and I facilitated at the first day of TCUK13 in Bristol.

The insight itself is not revolutionary, of course, but it gave attendees a chance to try out content modelling and card sorting first-hand and consider alternative designs and difficult decisions that go into structuring documentation just right.

Explaining taxonomies and content models

Chris and I started the 3-hour workshop with a 30-minute presentation:

Organically grown content often develops into a mess of good, bad and ugly content with little or no discernible structure. An information architecture that was designed by central oversight and with a guiding higher principle might resemble a cathedral – but the organically grown reality more often resembles a bazaar.

Both models have their drawbacks: The cathedral might be out of touch with what users need to do and know in their daily lives. The bazaar supplies that better – but it’s much harder to navigate, unless you know it really well.

Chris and I presenting (photo by @JK1440)

Chris and I presenting (photo by @JK1440)

Enter taxonomies, which are hierarchical classification systems. Just as children and veterinarians use different systems to distinguish and classify animals, so users and we who write for them can distinguish different topic types and structures and different ways to navigate topics according to their needs and use cases.

Exercises: “Bring out the scissors!”

Then we formed 12 groups of approx. 4 and set off on a couple of exercises:

  • Content modelling. Take a documentation set (in our example a user manual for a handheld audio recorder) and develop topic types and content models for users, their needs and use cases. Then re-chunk the manual into new topics according to topics types and users.
  • Card sorting. Take the topics and find the best sequence and hierarchy for them.  Also consider the documentation format such as print, online, etc., and topic re-use opportunities between different formats and use cases.
Workshoppers baking their own taxonomy (photo by @jk1440)

Workshoppers baking their own taxonomy (photo by @JK1440)

After the first exercise, we had a short roundup of the different approaches and results of the groups and a short break, before we embarked on the second exercise.

As it turns out, it’s really difficult to separate between content modelling (structuring within topics) and card sorting (structuring of topics). And in many cases there might be few benefits to separate those tasks. However, if you do the content model first and in isolation, you might have a more stable content model that lends itself to more than the structure you’ve used to pour it into.

To sum up, it was a very lively workshop with many good discussions – mostly within the groups of four, but also in the roundups when we collected approaches and insights. Chris and I thoroughly enjoyed it and learned a lot about what a diverse bunch not only tech comm audiences, but also we as practitioners can be.

If you’ve attended the sessions or want if to know more about what happened and how, feel free to leave a comment.

Shape the hype cycle with tech comm

You can use technical communication to accompany and even nudge technologies and products along the hype cycle.

The hype cycle

The hype cycle was invented by Gartner Research in 1995 and has since been underlying dozens of their reports. Here’s a schematic example:

image from http://newsletter.stc-carolina.org/

You can see how it tracks visibility and expectations of a technology across time in 5 stages, from the Technology Trigger up to the Peak of Inflated Expectations and down into the Trough of Disillusionment, then slowly up the Slope of Enlightenment, until it reaches the final Plateau of Productivity.

I think there a few remarkable things about the hype cycle:

  • Let’s get the obvious out of the way: It’s not a cycle at all, but a curve… 🙂
  • Different types of companies may engage in the cycle in different stages. That means the hype cycle is not some fate to be endured, but something that can shape corporate strategy – and by extension content strategy.
  • The hype cycle is not just for managers and marketeers. It speaks to our industries as well: Tech comm consultant Sarah O’Keefe started an article on “The Hidden Cost of DITA” with it in 2008 (that’s where I got the example above). And UX designer Ron George put one up on his blog last year.

Enter technical communication

So what does technical communications have to do with it?

We technical communicators provide the words around stuff on the curve. So we can put a spin on them, to a certain extent. I don’t think we can move a technology or a product into a totally different stage with documentation. But I believe we can mitigate adverse effects and nudge our subject along the curve a little.

There are two reasons why this works:

  • Technical communication is part of the hype cycle. Whether we take it into account or not, our documentation contributes to the item’s visibility, and it certainly shapes expectations on it.
  • Technical communication can be dynamic and agile. It is usually quite easy and fast to change the technical communication in contents, tone and spin to address a new use case, an additional persona or a different audience.

And there are several ways how you can use technical communication to influence the hype cycle:

  • It’s all about context. You know this already, if you’ve ever thought about personas, your audience and their situation when they are using your product. So take into account the hype cycle, especially that difficult phase into and out of the Trough of Disillusionment. “First contact” documentation such as quick starts are particularly suited to address inflated expectations and to offer a shortcut to the Plateau of Productivity.
  • Position yourself as the users’ advocate who accompanies them along the curve. Who is better suited to guide them up the Slope of Enlightenment than us technical communicators? Keep visibility of the product and its benefits up (to the limited extent that you can), and keep users’ expectations realistic.
  • Engage with the users. Hiking up a slope in silence is no fun. Find out what interests your users, what they try to do and where they want to go with the product, whether by soliciting feedback or user-generated contents. (But don’t forget to check back with your diligent product manager about the general direction…)

Your turn

What do you think? Should you, can you write with the hype cycle in mind? How can it affect the relationship between technical communications and marketing?

Top 10 things that users want to do in a help system

Truly helpful help systems are more than a set of instructions and information. They offer a constructive, pleasant user experience that make users happy and efficient. Which makes help systems comparable to libraries or department stores…

David Weinberger has an interesting analogy how information systems in general are like – and unlike – retail stores in the beginning of his book Everything is Miscellaneous. You can read the prologue and chapter 1 online.

Here are 10 things that users want to do in a help system – or a library or a department store… Some of them are kind of obvious, but I think it helps to consider all of them and how they relate to functions and options in a help system. Which ones you want to offer depends on your users, your product and your tech writing resources.

1. Search

I know exactly what I’m looking for.

Offer useful search results. Duh…

2. Find (and find again)

I know it should be here somewhere. I swear I’ve seen it last time!

Offer filter options to narrow down search results by topic type, task type, persona, etc., so users don’t have to guess how your topics are structured or how to rephrase their search. Allow users to save search result lists and to bookmark favorite topics.

A good discussion how users search and find in different ways is in Morville’s and Rosenfeld’s book Information Architecture for the World Wide Web, chapter 3 “User Needs and Behaviors”.

3. Know their way

I know where it is… – Now how did I get here? How do I get back?

Offer navigation aids such as a table of contents, browsing sequences and breadcrumb trails, so users can

  • Explore topics in context,
  • Look up their current location in the system,
  • Backtrack their steps.

4. Browse (as in “shopping”)

I’ll know what I want when I see it.

Offer tags that describe and group topics, so users can quickly get to the right section and dive in.

5. Get advice

I don’t know what I need. This is all new to me.

Recommend tutorials, best practices, what’s new, tips & tricks to guide novice users – and visitors who wonder about the learning curve of your product.

6. Recognize items

What is this thing? What does it do? The box doesn’t say.

Offer clear and, if possible, unique topic headings so users are confident they’re looking at the appropriate item.

7. Compare

This isn’t quite what I’m looking for… Do you have something similar?

Offer a selection of related topics.

8. Ask a human

What does this mean? I don’t understand this. This doesn’t seem to work!?

Offer options to send an e-mail, or a request for service, callback or chat to your company.

9. Share

This is cool! Here’s my comment. My friend/colleague should see this!

Offer ways for users to submit feedback, comments, ratings. Allow users to e-mail or tweet a topic.

10. Take stuff home

I’ll take this!

Allow users to print or make a PDF of one or several topics.

Your turn

Which use cases do you find essential? Have I missed any? Or could you do without most of them as long as your search rocks?