“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.

Advertisements

Tech comm MOOC by STC not happening apparently

The STC’s MOOC which I announced last month is apparently not happening. It was supposed to let participants explore the field of technical communications, and I was scheduled to teach the introductory module starting 30 September.

My assumption that the MOOC is not happening is based on the facts I have at this point:

  • There has been no announcement by the STC beyond an introductory one-page article in the July/August issue of the STC’s intercom magazine.
  • There is no place to sign up for the MOOC and to get specific information.
  • There is no content in the MOOC’s staging area.

I’m really sorry that it’s not happening.

I think we’ve lost a great opportunity to let people know what a varied and vibrant profession technical communication is. That we are mainly about improving relationships with customers and users where people meet products and services – not about spelling and serial commas.

At a time when professions and job requirements develop rapidly around us, it is important to prove that technical communicators do add value and play important roles in defining and implementing content strategies and user experiences – and this MOOC would have been a great chance to do just that.

Top 5 reasons I look forward to TCUK13

TCUK13 kicks off in Bristol next week, and here are my reasons why I’m very excited about it!

Intimate, professional conference

Of all the conferences I know, TCUK is the most intimate, almost cozy conference, attended by professional, engaged tech comm’ers. There’s none of the stimulation overload or anonymity that can mar larger events. This will be my fourth year in a row, and in past years, I’ve loved every minute – and cursed my travel schedule which made me miss the occasional closing session…

Versatile programme of presentations

For “only” three streams of presentations I think TCUK managed to schedule very versatile sessions. The conference website lists all subject areas, but these are my personal favorites:

… and I’m proud to contribute to the versatility with my own presentation “Addicted to meaning: Mental models for technical communicators“! 🙂

Practical, applicable advice

Nothing impresses my managers and colleagues more than bringing back directly applicable advice from a conference! TCUK has several sessions dedicated to specific Tools & Techniques. Also, for you Flare folks out there, TCUK will see the launch of the youngest ISTC special interest group: The MadCap UK & Europe user group, will hold its inaugural meeting as a TCUK fringe event on Wednesday, September 25 at 5 pm in the Terrace Bar of the conference hotel.

A fully booked workshop!

Chris Atherton from TCUK10 and TCUK11 fame and I will run a workshop “Bake your own taxonomy” about developing a documentation structure, with the emphasis on doing justice to existing, unstructured content – and with a week to go, the workshop is already fully booked. Chris and I are wowed by the overwhelming interest – not to mention spending an extra hour or two to make it worth everybody’s while! (If you had planned on attending, but didn’t register with the good folks at ISTC yet, we might have a couple of seats in case of no-shows, but we can’t promise you a spot at this time…)

Bristol!

One of my regrets at last year’s TCUK was that I spent no time at all visiting Newcastle – and envying those who did. So this year, I’m hoping to take some time to visit Bristol. The conference website has some initial tips for those of us who do.

If you’re a European tech comm’er, especially if you’re a European MadCap Flare user, I hope to see you in Bristol next week!

UK MadCap user group launches with two events

MadSIG, the MadCap UK & Europe user group, launches with two events in the UK in September. We are a handful of MadCap users who network to share expertise and support. Most of us are based in the UK, though I’m the Europe outlier who’s based in Germany (and sometimes Denmark).

MadSIG offers occasional meet-ups and also a LinkedIn group for feedback, ideas and resources. If you are a sole technical author, become part of a more personal group – in your own virtual home town rather than in the big city of the online forums!

MadSIG is a special interest group under the ISTC‘s umbrella – while you don’t need to be an ISTC member to join and participate, it’s certainly a good idea to take advantage of the society’s many benefits.

Meet with MadCap’s Mike Hamilton in Staines on 19 Sep

Mike Hamilton from MadCap is going to be at the Swan Hotel and Pub, The Hythe, Staines TW18 3JB, on Thursday 19th September from 7pm onwards. He’s generously offered to spend the evening talking MadCap with anyone who uses Flare and the other MadCap products, or is interested in finding out more about them.

If you would like to come, please let us know by email to MadSIG@ISTC.org.uk with your contact details, so we can update you if anything changes last minute. If you’ve got any specific topics you’d like to talk about, feel free to let us know, too.

Mike Hamilton has an encyclopaedic knowledge of the MadCap products, so bring your questions and, if you like, your projects, and get to know some other Flare fanatics from the South of England at the same time.

Inaugural MadSIG meeting at TCUK on 25 Sep

MadSIG holds its inaugural meeting at TCUK 2013. If you’re at TCUK anyway, this is your easiest chance to meet other MadCap users. We’ll meet at the Terrace Bar of the Marriott conference hotel on Wednesday, 25 Sep at 5 pm.

This meeting is a TCUK fringe event – that is, it is organised by us delegates, not by the conference itself. We are grateful that TCUK provides space and publicity.

The best KPIs support your tech comm strategy

The best Key Performance Indicators (KPIs) in tech comm are aligned to measure the success of your documentation strategy.

That’s some advance insight I got from Rachel Potts who will run a workshop about “Developing KPIs” for tech comm at TCUK in Bristol in a few weeks.

Measuring performance

KPIs are “a type of performance measurement to evaluate success… often success is simply the repeated, periodic achievement of some level of operational goal (e.g. zero defects, 10/10 customer satisfaction, etc.). Accordingly, choosing the right KPIs relies upon a good understanding of what is important to the organization.” (Wikipedia, “Performance indicator“)

But KPIs can be tricky! Says Business Administration professor H. Thomas Johnson: “Perhaps what you measure is what you get. More likely, what you measure is all you get. What you don’t (or can’t) measure is lost.” (Quoted and explained in a Lean Thinker blog post)

KPIs in tech comm

Some KPIs in tech comm are also deceptive. To pick a glaring example, measuring grammatical and spelling errors per page is comparatively easy and will probably help to reduce that figure. But one very fast way to improve this KPI is by changing the page layout, so there’s less text per page. Fewer words and more pages lead to fewer mistakes per page – without correcting a single word. Also, the measure won’t improve documentation that’s out of date or incomplete or incomprehensible.

Rachel advised me: “It depends on strategy and purpose: What’s right for one team is completely wrong for another. Measuring errors on the page is only a valuable KPI if the number of errors on a page relates closely to the purpose of your documentation. If there is a close relationship, then that’s a useful KPI!”

Strategic KPIs

So what would be alternative KPIs, depending on particular tech comm strategies?

If your strategy is to make customer support more cost-effective, you can measure (expensive) support calls against (cheaper, self-service) documentation traffic, while trying to align your documentation topics, so they can effectively answer support questions.

If your strategy is to improve your net promoter score and customer retention, you can measure users’ search terms for documentation, number of clicks and visit time per page, while trying to optimize content for findability and relevance to users’ search terms.

If your strategy is to improve content reuse and topic maintenance, you can measure redundant content to drive down the number of topics that have mixed topic-type content:

  • As long as you still have abundant conceptual information in task topics, you probably have redundant content. (Though a couple of sentences for context can be acceptable and helpful!)
  • As long as you have window and field help reference information in task or concept topics, you propbably have redundant content.

What do you think? What KPIS are helpful? Which are you using, if any?

Join us for a tech comm intro MOOC by STC

This fall, the STC will run a free 5-week MOOC to allow everybody online to explore the field of technical communications – and I’m excited to be teaching the introductory module!

The full syllabus

The MOOC will highlight the roles and responsibilities of technical communication professionals through 5 specializations in 5 weekly modules, starting on 30 September:

  1. Introduction to technical communication, by myself
  2. Content development and delivery, by Bernard Aschwanden
  3. Content strategy and lifecycle, by Mollye Barrett
  4. Instructional design, by Dana West and Phylise Banner
  5. Usability and user assistance, by Ray Gallon and David Farbey

The introductory module

My module in the first week will serve as a general introduction to the field of technical communication.

What will you learn?

After the module, you should be able to

  • Define purpose, benefits and tasks of technical communication
  • Argue the value of technical communication for companies and clients
  • Describe the daily job and career of a technical communicator
  • Identify the elements of effective technical communication
  • Describe and develop basic core skills of a technical communicator

What do you do?

Your week will start with some assigned texts and videos to introduce the topics.

You will see how all the pieces fit together in an online lesson on Wednesday afternoon (US time). The outline will be the same as for the readings; it looks something like this:

  1. What is technical communication? – Definitions and trends
    • A changing definition, from technical writing to business problem-solving
    • Recent trends (mobile and embedded help, social media and user-generated content)
  2. Why have technical communication? – Benefits and business cases
    • How technical communication benefits users and companies and products
    • What only technical communication can do (USPs)
  3. Who is a technical communicator? – Tasks and career
    • A day in the life
    • Personality and aptitudes
    • A versatile career path
  4. How does a technical communicator work? – Skills and expertise
    • Know your audience through audience analysis and personas
    • Learn from subject-matter experts by research and collaboration
    • Write task-oriented topics using task analysis and modular topic types
    • Edit modular documentation for content and language

You will have a chance to try your hand on technical communications in a couple of learning activities (a/k/a assignments) around creating and editing documentation.

Oof, that’s a lot, no?

Well, yes and no. Yes, it is a wide area, but the purpose is to give you a taste of our versatile profession! I’ll start with the larger picture to illustrate the value of tech comm and how it can be cool and profitable, before diving into a few core skills in depth. The four later modules can afford to be a little more focused.

More information

More information will be available shortly on the web sites of STC which is sponsoring this MOOC and on CourseSites which is furnishing the platform for it.

In the meantime, check out Mollye Barrett talking about the MOOC and her module in a 1:30 video.

What do you think?

Would this be interesting to participate in? What other topics would you expect to see covered in the intro module? Let me know in the comments, and I’ll see if I can address your opints, either in the comments or in the MOOC module itself!

English articles for non-native speakers

A few simple rules can help non-native speakers get English articles such as the, a, and an right.

Some documentation I get to edit is written by tech writers whose native language doesn’t have articles. Their grasp on the subject at hand is as good as any colleagues’, and most of their grammar and spelling is fine, but articles the and a and an give them a hard time.

So I’ve put together a few rules which are easy to memorize and help writers get articles right most of the time. Judging from my colleagues’ writing, they work… 🙂

The definite article the

Use the to refer to one or several specific, individual things. For example:

  • “Open the package by pulling on the lid.”
  • “To close the windows, click the Close button.”
  • “To save the changes, select the File > Save option.”
  • “‘Automatic’ is the only valid setting in this situation.”

The indefinite articles a and an

Use a or an to refer to one unspecific, countable thing. For example:

  • “You need a router and a network cable before you can connect your computer to the Internet.”
  • “To visit web sites, use a web browser, such as Mozilla Firefox, Chrome or Internet Explorer.”

Use a or an to refer to one particular example of something, often with a descriptive adjective. For example:

  • “C# is an object-oriented programming language.”
  • “PGP is a safe way to encrypt e-mails.”

No article

Use no article when the number of things cannot be counted or does not matter. For example:

  • “Many users worry about privacy and online security.”
  • Computers and netbooks are often equipped with WLAN cards.”

Additional advice

These rules are not 100% complete or error-proof, but they cover most of the scenarios you will encounter.

For additional rules and examples, I recommend these websites: