Technical Communication UK 2011 (Day 2)

I know there’s been a bit of a gap between Day 1 and this post – but I’ve been playing catch-up for a while. Writing down what I did and what I learnt is useful for me anyway, so I’m going to get on with it before I forget.

There was so much choice that I struggled to decide what to attend. I’m a lone technical author and although I could end up working in a very structured-authoring way, I haven’t been in that environment since going freelance nearly 7 years ago. (Maybe my contracting colleagues who work full-time on projects for a number of months have more exposure, but my work tends to be shorter, more discrete pieces of work.) Based on this – and as I am extremely interested in the layout and appearance of documentation to help understanding – I found myself concentrating on the the specialist stream: ‘Anything But Text’.

The day started with a thought-provoking keynote from Patrick Hofmann, entitled Make icons make sense: solving symbols for global audineces. I’d attended his workshop the day before, and so did wonder if it would be ‘more of the same’. It was and it wasn’t. The day before we had looked at providing visual information for a very defined group of people, who shared a lot of characteristics (culture, language, previous exposure to the subject). Today we looked at how people you might on the surface consider to be fairly homogenous could actually be wildly different. This fitted in nicely with a lot of things I’ve been thinking and reading about lately. As technical communicators, we often have strong ideas of how different ‘cultures’ view different things. These ideas may even be based on research – which is great. But do we take into account how those ‘cultures’ are evolving? Is the culture of young people in a country the same as that of the older people? What about city dwellers compared to those in a rural environment? It seems to me sometimes that there’s a lot of guesswork going on... and that in trying to accommodate, we sometimes (unintentionally) confuse. For example, I know that Chinese family names are traditionally first, then the personal name. I’m not familiar with all Chinese names, though, so don’t recognise from the sound which is which – and have before been told a name that has been reversed because the speaker knows that in my culture we put the personal name first.

Next, I went to the colour workshop with Greg Urban (Rules of thumb for using color in your content). That was absolutely fascinating, and Greg handed out colour wheels that we could use to follow the theory. Unfortunately, I took mine out of my bag to show to someone and lost it... I will have to see if I can get another, as it was extremely useful.

Forms are another of my pet annoyances (see a much earlier posting in this blog). Perversely, I quite enjoy filling out forms – well-designed ones, that is. I hate forms that don’t have enough room. I hate forms where I don’t know what they want me to do ("Do they mean have I ever done this before, or are they only interested if this is the reason I’m contacting them?"). I hate forms that look as if they’ve been designed by someone on their first day of a ‘Let’s learn Word’ course. So, with this baggage, I decided that Robert Hempsall and Caroline Jarrett may have some insights I could use in their session: Who enjoys filling out an application for a driving licence. One of the most interactive sessions of the conference, we all got the opportunity to start filling in an application form for a UK driving licence – and critique it. One of the big things I took away was from a stupid mistake I made... one of the questions asked for my address when the previous licence was issued. As soon as I saw the blank look on Caroline’s face, I realised I’d interpreted the question wrongly – or at least, got my terminology wrong. A licence is ‘issued’ every time you change address – it isn’t when you move from one category of driving level to another (provisional to car to car + motorbike) which is what my brain had decided it was. I had interpreted the first time I got my full licence as that being an ‘issue’, and subsequent ones being ‘copies’ or ‘replacements’. Hmm.... daft mistake, yes. But maybe I’m not the only one to misread a form?

After lunch I went to see Andrew Lightheart. Andrew had been sat by me for dinner the previous evening, and I’d already decided he was someone I must go to listen to. Easy to talk to, and to listen to, I just had a good feeling about it. Nothing ground-breaking for me, but a few good hints and tips that I have since used – mainly around not letting the audience’s questions side-track me away from the main point of the presentation I’m giving. Kai Weber has written a great summary on his blog.

I switched streams mid-afternoon and went to see what I could learn about eBooks, as I have a client who is considering moving their publications in that direction. In fairness, the title did include the words ‘in technical communication’, and my client’s publications aren’t in that field, but even so I came away feeling disappointed that I hadn’t learnt anything I could apply.

Finally we closed with another keynote, this time from Ikea. Love or hate the instructions, you have to admire how much they have achieved when you realise just how many languages they have to deal with, and how many different national regulations on the inclusion of instructions they have to comply with. Of particular interest was an instance where a national regulation – designed to help – actually hindered. The documentation people at Ikea had what I thought was a very good idea. They recognised that many countries have large communities that speak other languages to that country’s national language. They thought it would be a good idea to be able to ask the individual customer which language they would like the instructions in, and to print a copy there and then. Fantastic! But it couldn’t be done. Why? Because the regulations stated that the instructions had to be IN the box with everything else... and although printing in anyone of 50+ languages (can’t remember the number – may be more, may be less) on demand is one thing, printing 50+ copies per box is something else.

Customer service? When will they ever learn...

I recently tried a service, offered by someone who knocked on my door one day, that meant my wheelie bin was disinfected after it had been emptied. The basic job was OK, but the fact I had to up-end it to drain the fluid left inside meant I ended up with more work, not less. What has this got to do with technical communication, you say?

Well, the reply I got to my (if I say so myself) polite message expaining that I no longer needed their services was rude, to say the least. Not only rude, it was full of spelling and grammatical errors – not that a perfect command of written English is a required skill for wheelie bin cleaning, I admit. The errors I could ignore...but the tone I couldn’t.

I have no idea whether the man replying to me intended to be as offensive as he was – although a subsequent message leaves me to believe he did – but that was certainly his effect.

Does it matter? Maybe, maybe not. It depends how many people read the review I’ve posted on Yell before engaging his services. It depends on whether he decides to advertise on the local directory services, which also provide the facility to leave reviews. It depends on whether any of my neighbours who were also approached about the service but declined ask us how we found it.

He could have said the same things in a much more pleasant way. A way that would have encouraged me to refer him on to someone else – something I try to do, especially if I can’t use someone’s service myself.

It’s something my mother used to say to me when I was a child: “It’s not what you said, it’s how you said it.”

We all need to learn from this – the tone of your communication is every bit as important as the content. Although this is an extreme example, the concept affects every communicator, technical or not.

His parting shot was that he did not want customers like me (paraphrased here) – with a bit of luck, having annoyed me enough for me to put finger to keyboard and write said reviews, he won’t get too many!

Technical Communication UK 2011 (Day 1)

I thoroughly enjoyed my first day at Technical Communication UK 2011. Tuesday is ‘workshops day’, and I was spoilt for choice. After much deliberation, I finally settled on ‘Intuitive images: tips and techniques for creating and evaluating graphics in your products’ with Patrick Hofmann and ‘Can CAD destroy the art of technical illustration?’ with three (very patient) people from Altran Xype. (To see everything that was available, go to the Programme page on the website. Links to presentations and videos of some of the sessions will gradually be posted there, too.)

Patrick’s workshop managed to be entertaining and thought-provoking at the same time. We all puzzled over some of the symbols, and it dawned on some of us that something ‘obvious’ is not necessarily representative – and may not make sense to a large percentage of the global population. Depending on the work that we do, some technical communicators may have little involvement with icons and symbols in that sense, but Patrick’s workshop covered other image-based communication, including flowcharts. I’ve come away with a lot of ideas (and, I’m pleased to say, some nice warm feelings that I’m getting at least some of it right).

The afternoon session was very different. Altran Xype have a product (3DVia Composer) that – if I understood correctly – enables technical communicators to make use of available CAD data to create the types of illustrations and animations that are needed when trying to explain or instruct. Workshop attendees were given a copy of the software prior to the event, so we could load it onto our laptops, and we spent at least half of the session trying it out.

I’m not a technical illustrator, and primarily document software – but there are times when something like this would be invaluable. How much better to be able to create the step-by-step diagrams myself, showing exactly what I need to be able to show, instead of relying on a flat image exported from a CAD system that isn’t at the right angle or that doesn’t show the detail that I’m describing. I’m certainly going to share information about this product with my customers, as I can see many uses for it in engineering and manufacturing.

As always, a huge part of TCUK is the calibre of the delegates – so many people to talk to, and so little time! The conversations over lunch, dinner, in the exhibition area and any time you find yourself sitting or standing next to someone make it fantastic. The only three days in the year when I can have a professional conversation with someone without having to try to explain what I do first!

Getting started: step 1, what are you writing about?

I'm sometimes asked what the first steps are in writing ‘good’ documentation... where to start. My answer is usually that you need to have clear answers to four vital questions... what you are writing about, who is going to read it, why are you writing it and why are your readers reading it.

These are only a starting point, and I’m going to take each one in turn, although you need to combine the answers to them all and not act on one in isolation.

First, what you’re writing about. People often think this is the ‘obvious’ question. There’s the software/product/service – just write about it!

But I believe you need to dig a little deeper. Some topics are so huge that you need to narrow down the scope or you’ll drown in information. Others so diverse that you could be looking at it from a completely different perspective to the person who’s asked you to do the work.

Imagine that you are asked to write about the way a company documents its products(a common enough scenario). You could look at this in a number of different ways:

• The documents that accompany each product (user guides, reference manuals, tutorials, training materials, online help) and guidance on what goes in each.
• The applications and tools that are used for the various types of document - and possibly instructions on their use or the methods that have been adopted.
• Typographical, stylistic, naming and other conventions, helping writers to conform to the brand identity of the organization.
• The review process, and how updates are handled.
• Language guides to aid translation or understanding by non-native speakers.

And these are just a few that have occured to me while writing this!

So when someone asks me to ‘write about X’ something, one of my first questions is always to find out ‘What about X?’

Next, we'll look at step 2 – who is going to be reading it?