This topic is of utmost importance for all Technical Communicators in all sectors.
Even non-help system documentation is rarely in print anymore, but needs to be legible and useful from a computer screen of various dimensions and display capabilities. We must admit that it needs to be useful for reading on the fly at the particular time it is needed, often in an emergency.
We are the only ones who read manuals in advance of need, and we cannot win as professionals if we hold on to that ideal.
We need to make complex information easy to read onscreen, clear, compact, precise and easy to navigate.
To do that the main focus needs to be the audience and their vital needs. This focus is true for Software Architects, User Interface Designers, Document Publishers, Help Designers, and every person implementing their slice of the product.
The User Interface is the product. Features are not implemented, when they are obscured. The doers of the work are likely learning on the fly as they try to do their work with your new tool, as in a stressful economy, the training and education budget is one of the first to be axed. Even if the tool will do the job, if it is unknown, or difficult to operate, Users want to get a new tool, and often can.
The best thing that you can do is test your piece of the Technical Information on as many members of your audience as you can quickly grab (in with the developmental stages is even better). More people and more recording is better, but a half an hour with a basic screen mock-up on single office/personal volunteer is priceless in building the best.
Jeff Johnson has a wonderful section in “GUI Bloopers 2.0” on understanding the Users and the Tasks that should underpin every tool or document. Many people have also written well the topic of using surveys and interviews to learn about the audience. What shines is Jeff’s discussion on technical level, and his breakdown of the types of information to study:
- General Computer Knowledge
- Task Knowledge
- System Wide Knowledge
- Goals of using the tool.
Knowing users’ reasons to use the tool could impact how the user interface, help feature, and documentation is shaped at a very fundamental level. Knowing the architecture of the whole system should similarly help shape the conventions of presentation, and division of content. The level of security clearance required for certain tasks could result in the need for two separate documents, as an example. General Computer and Task knowledge might correlate along predicable lines, or not.
If this principle of the highest dedication to users, goals, and tasks is followed above all, we can and will prevent frustration, stress, and create client success.
The Bloopers associated with failing this principle are from all types, but the Management Bloopers in Chapter 8 are some of the worst offenders, which will be the next topic. That is bloopers made by Management (ie: The Man), not errors of writers’ or editors’ management.
I look forward to future
rants discussions on:
#64: Treating UI as a low priority.
#66: Discounting the value of testing and iterative design.
#67: Anarchic Development.
#68: No task expertise on the team.