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.
Subject:RE: Questions for usability surveys From:Susan Harkus <Susan -dot- Harkus -at- xt3 -dot- com -dot- au> To:TECHWR-L <techwr-l -at- lists -dot- raycomm -dot- com> Date:Wed, 4 Oct 2000 13:39:35 +1100
Hi Emily,
One key element of any usability survey should be a section that asks the user to list instances where they went to Help or documentation and failed to find an answer.
For each instance, you need to know
1. What task were you doing when you referred to the documentation?
2. What problem were you trying to solve? What questions did you have in your mind?
3. How did you try to find the answers you needed? Using the table of contents? the index? a full text search? Using more than one information source? For example, both Help and the User Guide?
4. If you used the index or a full text search, what keywords did you try?
I once saw a user survey for the software product of a large computer company. The user complained that the documentation index was very poor. This is exactly the type of response that is NOT helpful when you are trying to improve the user experience. Why is it not helpful? Well, it may very well be that the index is a failure but you cannot tell how you can make useful changes because you have no idea where the user is coming from.
As it turned out, the documentation for the computer software was so atomic and fragmented that answers to user problems had to be pulled together from different chapters. The problem was primarily the document structure.
The approach I have proposed above attempts to identify the user, in the problem situation, trying to resolve an issue. You need that information to ensure that your survey outcome is the identification of ways to improve your documentation, not just statistics.
