Anyone working in the software industry will know the term “usability” and have a reasonable idea of what it entails. As a technical writer, a user advocate within the development team, there is typically an overlap between how we think, and how usability specialists think.
For starters, anyone who is delivering information should know who their audience is and why they require the information. With a good understanding of your audience, you will know what information they require because you will understand how they use your product.
It seems obvious yet it’s something that many people struggle with, and I wonder if it is partly because, rightly, usability is a distinct field which has many experts and practitioners.
However, many software companies do not have resource dedicated to usability as, and I don’t get to say this often, it’s often seen as less of a priority than technical writing.
Why does any of this matter to you as a technical writer? Because it’s another string to your bow, another item to add to your CV, and something else that will convince your boss that it’s worthwhile keeping you in the team.
And hey, it’s interesting stuff, a little task analysis of the requirements, some creative thinking, and an even better understanding of the product and then, if you are really lucky, you get to talk directly to users of your product.
I’m part of the ad-hoc usability team in my company, and whilst it can be challenging it is part of my job I hugely enjoy and which makes me a better technical writer, and that’s never a bad thing.
Hi Gordon, am a technical writer and initially, my suggestions to improve usability was taken lightly and was often forced to write crazy work around and troubleshooting tips to cover up the usability issues.
Slowly, the team started to recognize the value of usability! Nowadays am actively involved in screen designs and wizards, and I’ve the satisfaction of improving the overall usability of our apps.
That’s quite a common scenario, and I’ve used the approach of documenting something I know doesn’t “work” for the user (is too complex usually) and then rewriting it by changing the task steps as I’d like them to be in the application.
It’s very easy to show which is easier for the user if you show them the steps written down.
Screen design and Wizard text is also a key area where we can provide a lot of benefit, and it’s a nice challenge to come up with creative uses of the space.
Hi Gordon,
I am interested in usability, generally because I have been involved in university websites where non-English speakers, computer geniuses, computer-phobes, the colour-blind, the Dyslexic etc etc all have to have access and so the user issues with software are huge.
That said, even though I might THINK I am aware of issues, until I took part in a review of the university library website and was one of the people conducting the user interviews I had no IDEA of some of the issues this could throw up. We knew the website was pants, but we had no idea that it could be interpreted to make it, unbelievably, even more pants.
If you are interested, the librarian in question did a wee article on how we did our testing, it isn’t long and it gets to the point. We did the testing in order to prove that what some folk thought was an ok site (fools) with just a glitch or two was a highway to madness.
The paper was in SCONUL Focus, link here:
http://www.sconul.ac.uk/publications/newsletter/36/10.pdf
Usability isn’t an optional extra – on account of disability issues if a piece of software cannot be accessed easily (or indeed at all) by people with specific issues then our uni would have to get another bit of software for them… and if that is the case, then why not just get the other bit for everyone and not buy the first one? Software at a university doesn’t get the students going to the software firm asking questions, they turn up at the helpdesk and that is the uni’s time and money. If the usability isn’t up to scratch it costs the uni – we have to do it and, uh, they aren’t into that. Usability is the difference between software being bought into the university or not even being considered.
Technical writing really cannot be dislocated from that at all, it is not simply a case of technical writers getting another string to their bow, I don’t think so at any rate. The documentation is part of the user experience – there are complicated bits of software at university and things are not always intuitively clear, and people are aware of that. When that is the case, you turn to the documentation and if that is not clear either you get a frustrated user. If the software is great and the documentation isn’t then you still have usability issues, because when a problem does occur (and it will) then the user gets frustrated, goes to the helpdesk and we log all the problems we get and a piece of software annoying too many users gets queried for viability.
And finally, sorry, on a rant but this is an issue close to my heart, if you are trying to sell your software then you might have to be selling it to universities, schools, local authorities, governments – for whom access is a legal requirement, not an optional extra, and if they are using the software it is generally networked and they deal with the issues it generates. And if it generates problems for certain users (and these folk do know their audiences too) then an accessibility issues is a usability issue: more calls to the helpdesk…You can bet your life they usability check it before they buy it, even if the firms don’t.
Sorry about the rant, but I’ve worked the university helpdesk and still have the nightmares…
All the best.
DB