The first TechCommNZ Christchurch branch event of 2018 was held on Wednesday 14th March. The speaker was Synlait Applications Support Analyst, and current TechCommNZ president, Meredith Evans, who returned to the topic of her Collaborate 2017 presentation, “Real users, and what to do about them.” Anna Millow reports that the presentation was, as good technical communication should be, educational, instructive, and entertaining.
Meredith began the talk by setting the scene, describing Synlait and her work there. Unlike some technical communication roles, which involve little or no direct contact with users, Meredith interacts with her users on a daily basis, providing training and support as well as creating and testing documentation for the ERP (Enterprise Resource Planning) System.
ERP systems in general are not known for their usability, as a survey of the audience confirmed. Meredith used the example of fictional Synlait worker Murray to illustrate why it is important to consider one’s audience when creating technical documentation.
Users in general:
- occupy a range of different roles.
- have varying levels of experience and technical competency.
- only use a few of the system’s functions each.
- are under time pressure.
- are untrained in using ERP systems.
Based on her experience at Synlait, Meredith presented a summary of 6 Habits of Real Users (and what you can about them):
1. They print things.
This can be problematic because:
- documentation goes out of date.
- users come to rely on print material and are unaware of additional resources available online.
- the context of the documentation is lost.
- Focus on documentation in training.
- Don’t provide printed guides.
- Improve print stylesheet.
- Assume online content will be printed.
2. They create their own documentation (“shadow documentation”).
And, more problematically, they then share it. This leads to inconsistencies and errors in the system, and, like print material, shadow documentation goes out of date.
- Be proactive and talk to users.
- Be responsive and efficient so that the need for individual documentation won’t arise – accuracy is important, perfection may not be.
- If you can, reinforce hard limits, or acquire advocates to do this for you.
- Develop your own specific style so that you’ll be able to tell if the documentation is yours.
3. They focus on graphics over text.
Although images, e.g. screenshots, can be very useful, they can also cause problems if they distract users from the text and cause them to miss something.
- Pay as much attention to graphics as you do to text.
- Ensure that screenshots look like what the user will see.
- Size graphics to print properly.
- Use callouts (text connected to a graphic, or enlarged in order to draw attention).
- Prefer graphics that are easy to maintain.
- Be aware that text around graphics will be ignored.
4. They get lost.
- Just because the navigation system makes sense to you, don’t assume that it will make sense to all users.
- Include multiple methods of navigation, e.g. menu, search, links.
- Develop the help section, and provide training on how to use it.
- Include context on every page.
- Conduct testing or use analytics to see how users behave.
5. They want to know the big picture – where they fit into the overall process.
- helps them understand the system.
- improves their understanding of detailed content.
- motivates them to follow the correct process.
- adds interest for users.
- adds value to your work as technical communicator.
6. They will find your mistakes… and this is a good thing.
It is important to be responsive to user feedback. Fix the problem, quickly, and tell the user that you’ve done so.
So, what were the take-home messages?
- Avoid assumptions.
- Get to know your users if you can.
- Training is a great opportunity.
- Find ways to collaborate with other groups within the company (e.g. IT support).
- Find the right mix of getting it right and getting it done, for your project, role, or company.
- and learn from your users.