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.
> So, your opinions... Is this audience analysis supposed to be
> something separate from requirements analysis, or is one of
> them just an aspect of the other, or are they separate things
> that have some degree of overlap?
I firmly believe that they're separate. A requirements analysis will give you a list of requirements that need to be satisfied, but the audience analysis helps "inform" both the product design and the documentation to make them usable.
Without audience analysis, the risk is that the product technically satisfies all the requirements (some in-house expert can get it to do all the things it's meant to do), but actual users fail to complete many tasks or succeed only with difficulty.
To give some simple examples of how this might apply to documentation:
- Maintenance procedures aimed at basic Army recruits might be designed with many pictures and little text.
- Products aimed at seniors might be designed with larger text labels and easily resizable text in online information.
- Video tutorials might be suitable for a SOHO environment but less so for a crowded or noisy workplace.
- A tool for backing up Oracle databases on UNIX should not necessarily assume that users are familiar with Oracle *and* backup strategies *and* UNIX.
- Which terminology to use out of rows, columns, fields, items, cells, observations, and so on, depends one whether users have a background in accounting, computing, statistics, etc.
An experienced TW on another list once told the story of when he updated a maintenance or inspection procedure for some military equipment. It was quite late in the piece when he found out that the person doing this procedure was typically upside-down in a missile tube with a buddy hanging on to his ankles, a flashlight between his teeth and a screwdriver in his hand. Presumably the spare hand was holding the instructions.
I wouldn't like to produce those instructions with only the requirements analysis and no user, task and environment analysis.
Stuart
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Free Software Documentation Project Web Cast: Covers developing Table of
Contents, Context IDs, and Index, as well as Doc-To-Help
2009 tips, tricks, and best practices. http://www.doctohelp.com/SuperPages/Webcasts/
Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
