TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Writing minimalist documentation requires a more sophisticated use of
audience and task analysis than tech writers usually employ.
Instructional designers are trained routinely to do critical task and
most used task analysis as part of training design. This same approach
is needed to make minimalist documentation successful.
Case Study
We had a client who had a 600-800 screen GUI system (no one new exactly
how many screens there were). The training guide/user manual was 2500
pages. They had documented everything. They also trained people in
everything. The system accommodated so many exceptions to its core
processes that the core processes got obscured. I'll call the name of
the system GUM (Grand, Unusable Mess). Users spent their own money to
produce "GUM Sucks!" buttons (true story), which they proudly wore to
training classes. Instructors began wearing "GUM Sucks!" buttons to
identify with their trainees.
To fix this mess, we worked with power users to determine what was the
Base Path, or best route through the core functions of the system. We
were able to reduce the core functionality to 23 tasks and describe them
in 125 pages. These became the backbone of an EPSS (electronic
performance support system) that sequenced screens for each task and
provided help for each task screen by screen. We developed other
strategies for building upon users core knowledge over time. The
2500-page manual is a door stop now.
