Limitations, empathy and accessibility

Yesterday I found myself curled in a ball on the floor of the gym surrounded by a pool of my own partially digested lunch. It wasn’t pretty, and was the result of trying to perform like a teenager whilst drastically under the weather. Through pushing myself, I’d found my limit, and upon making that discovery I didn’t want to do anything other than adopt the foetal position.

Why is a discussion of physical limitations important to technical communicators? Well, it comes down to how we prioritise and incorporate accessibility into documentation and therefore the products they support. By losing my lunch during physical training, I have some empathy for the individual whose mobility, stamina and coordination are at levels that mean they have to live in a bungalow, and find walking to the shops a herculean task… sure it’s a different thing they’re doing, but the end result of exhaustion, dizziness and curling into a ball on the floor are about the same. I’d suggest that a professional athlete is more likely to empathise with someone with a physical disability than a normal, unchallenged member of the public would.

We’re the pro-athletes of the communications world. We can produce copy, content and a whole gamut of useful and info-blurb on a variety of subjects. Worse, we often have these jobs because we have acquired various qualifications… proof that we’re super-sponges and masters at absorbing information. So how can we relate to the reader or end user who may be having to sound out each word, whilst repeatedly flicking between ‘the thing’ and the documentation about ‘the thing’ like a lost tourist? The answer is, most of us can’t innately empathise that way… we see the man in the mirror as ‘average’. We can’t ‘read till we’re sick’ to build the empathy, but there are things that we can do that may help:

Study something new

If you’re feeling smug and secure in your Engineering degree, go and learn poetry, or French, or even French poetry… if you’re more of a linguist, then why not try a course in mathematics or the physical sciences. The struggle you’ll have reprogramming your brain to ‘the new’ is what clients feel when the safety blanket of their old ways is yanked from them and that starting next week they’ll be using your firm’s solution.

Spend time in noisy places

I used to think I was good with noise… then we had a child, and I find that I now go to an artillery range to catch up on sleep. Turn the TV and radio on, grab yourself a copy of War and Peace and ask your partner to talk to you about shoes/football/North Korea. Imagine you’re going to have a quiz at the end of it all and you’ll have some idea of the pressure documentation and information can place on some people.

Wear sunglasses

Not when outside in the sunlight… but when inside reading a book, or using a screen. It’ll give you some insight into the importance of big, clear fonts with lots of white space on the page.

If you find your limits, you may have more empathy for those who are reaching theirs, and ultimately you’ll be willing to go the extra mile to make your work more accessible.

Andrew

Gathering evidence...

It’s easy to say that you’re good at something. The difficult part is getting some hard evidence to back it up – especially when ‘the proof of the pudding is in the eating’ (in other words, you don’t really know until you’ve tried).

It’s a problem we’ve always had – many of our existing clients are reluctant to publicly acknowledge that we’ve done work for them, let alone share whether we’ve done it well or not.

We’ve been giving this problem some serious thought over the last few weeks, especially as we’ve been trying to promote our writing skills training courses a little more. We’ve managed to gather a few testimonials on LinkedIn, and (with permission) have posted them on our website as well. But that still leaves a huge gap.

Our credentials speak for themselves in terms of our writing (and other communication skills) – we publish some of our own stuff on our website, and we keep ourselves up-to-date. After a bit of investigating, we decided that the courses we offer fit best under the umbrella of ‘business skills’ and the most obvious place to look for more information was ITOL (Institute of Learning and Occupational Training).

After a lot of hard work making sure everything was just as it should be, I joined the organisation as a member. (You need to be a member in order to have your courses accredited... but more than that, I felt I needed some validation of me as a trainer.) We then submitted samples of our materials, course overviews, details of course objectives and so on for scrutiny.

Success! All three of our core courses are now ITOL-accredited!

What does this mean? Well, we can point to an external source of verification that the methods we are using to teach are sound. It gives us a slight edge over some of our competitors. And if trainees want an official ITOL certificate, they can have one.

It also means that Andrew gets a few days in Slovenia. To become a member of ITOL himself, he needs to have completed an ITOL-accredited train-the-trainer course. I did the ‘How to Become a Brain Friendly Trainer’ myself a while ago, and that is an accredited course, so it seemed sensible to send Andrew to do the same... The next one is being run in Slovenia. (I can highly recommend this course – it helps you think of some creative ways of training that drive away the monotony.)

What’s next? Well, now we’re accredited (which should help with the in-house courses we have been running for some time), we are going to run our first public open course in Nottingham on 18 June 2014. It’s a scary proposition in many ways. When we are commissioned to deliver a course in-house, we know the course is going ahead before we have to invest anything beyond a little time. With a public course, there will be the nervous wait to see what the uptake is like. Watch this space!

Alison

Talking to users

This week I’ve been preparing Captivate videos with voiceovers for a client. It’s a task I particularly enjoy, and wish that more clients would request this kind of service. I think adding sound to training materials is brilliant for accessibility reasons, as well as improving the customer engagement with what can otherwise be very dry texts. You may be thinking of producing something similar in your organisation, so here are a few tips:

Learn the tools

Preparing a good software simulation or e-learning experience is a very different task to writing a manual or online help file. I see a lot of adverts out there for technical communication roles where Captivate is thrown in on the same list as Word. Captivate is excellent software, but in terms of complexity it sits somewhere between PowerPoint and the high end production software used to make movies. It’s relatively easy to learn, but tricky to master, and the difference will show in your final products. Help is at hand with some very nice on-demand training from Adobe, but nothing beats a bit of practice.

Choose a voice - watch the Simpsons!

If you don’t know the show, listen to a few episodes of the Simpsons before voicing training material... it’s an excellent guide to the non-verbal qualities we hear when people speak. When doing voiceovers, I’m always tempted to channel Troy McClure; the character famous for introducing himself at the start of his segments with comments like “Hi, I'm Troy McClure, you may remember me from such instructional videos as Mothballing Your Battleship and Dig Your Own Grave and Save”. I’m not talking about dropping in my own name, or having some other semi-comedic catch phrase. However, choosing Troy’s confident, paced timbre over Crusty’s manic laugh, Homer’s grunts, or any of the accent-heavy, metaphor-rich, and confusing dialogue we find from Willie, Apu, Mo or Bart pays off. Accents are a wonderful sign of the breadth of the English language, but if you’re constantly frustrated by automated telephone systems failing to understand you, then you might want to consider finding a colleague to read your script. Back up your planned voice with a nice microphone and Audacity and you’re good to go.

Have a conversation, with pauses

If users were able to cope with a deluge of information, they wouldn’t have started the training video in the first place. The last thing they want is more self-loathing because they can’t execute the steps fast enough to keep up with you. The lazy solution to this is to put a loop into the video so that they see and hear everything twice, in the hope that you’ll catch them the second time round. What I prefer is to have a more natural conversation with the user that includes details from the user case I’ve generated... so when documenting a course management platform, I’ll include information that may not make it into the manual, like the reasons an experienced teacher would choose to set certain genres of reading assignments, to give the user time to catch up with the on-screen steps.

A good tutorial video has many uses, it becomes business-wide content that can be streamed to the TV in the reception area, used by the marketing team at client presentations and trade fairs... most importantly it gives a real alternative to the written manual for users with accessibility issues or a paucity of time. If you’ve had any experiences (good or bad) with training videos and e-learning content, feel free to share in the comments below.

Andrew

Intentionally bad

Have you ever encountered tasks or subjects that are are written about so badly or sparsely, you get the impression that it’s been done on purpose? I can think of two topic areas where the documentation fits this description together with some pretty good reasons why.

Gunpowder, treason and plot

Most people know the composition of gunpowder and the ratios of the mix aren’t too hard to come by. If you watch the news you probably have a reasonable idea of what goes into home-made high explosives... but that’s as far as it goes. Most descriptions of anything that goes “bang” are curiously short of a step by step guide to manufacture, whilst the literature that does exist seems subject to a campaign of nay-saying and warnings of disaster. The reason (of course) is that those of us who understand how these things are made would rather people who shouldn’t have explosives blew themselves up in their own garden shed when getting it wrong.

Hacking

Hacking is performed much like any advanced task on a computer. It’s not The Matrix, often it’s just a case of putting the right bits of SQL into a box on a webpage or working out that email addresses in a company follow a pattern (such as [firstname].[lastname]) and going through their login page one employee at a time to find the dude who’s been allowed to use 123456 or password for their login credentials. In a less than ideal world, admin@[company].com with an obvious password will exist with all the implied access. More advanced hacking (the kind that makes the newspapers) requires detailed knowledge of exploits and weaknesses in systems (that I don’t have) which are painstakingly researched and closely guarded secrets. Often tutorials on hacking stop just short of allowing the reader to do any damage, whilst most of what happens has no easily accessible knowledge base as it would allow software companies to conduct a bit of counter research and fix their products.

What are the implications for technical communicators from these two nefarious examples? Well, firstly, there is a rebuttal to the school of thought that says “share everything, and put it on the web“ – anything that gets released out the door should be vetted so that it doesn’t give away commercially sensitive details or allow harm to come to the organisation and its customers – this includes the habit that some software providers have of publishing their default admin account details and passwords in manuals available in soft-copy form without reminding (or forcing) their customers to change them. Somewhere, a customer will place these documents on an unsecured intranet, and that will open up a vulnerability for every client you have who hasn’t bothered removing or changing the default account settings.

Secondly, there’s the social proof provided by these well known examples... if products don’t have documentation, or if documentation is incomplete, there is a risk of damaging reputation because clients will identify the product with the dodgy, and one way or another they’ll trust you less than they should.

Andrew