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.
Craig Branham wonders: <<I'm currently trying to investigate methods of
audience analysis in instructional design and I was wondering if anyone
could lend me a hand. Specifically, I'm looking for heuristics that could
help us assess student knowledge, attitudes, and skill levels in the domains
in which we work. But I want to avoid at all costs having the activity turn
into a mad grasp for demographic info ("the average student is 36 years old,
eats Wheaties for breakfast. . ." etc.), which can become very
counter-productive.>>
Demographics can indeed become counterproductive, and I'm going to be
talking (as part of a "progression") at the upcoming STC conference on a
very similar subject. To me, the goal of audience analysis is not to collect
demographic information and see what it tells you, but rather to invert the
process and start by trying to figure out what the audience needs to know to
use a product. In effect, you're not actually collecting the demographics
until you know intimately which of those demographics are going to be
important to you. Silly example: If your user interface is written entirely
in Esperanto, you need to find out what proportion of your audience already
speaks this language and--for those who don't--how much Esperanto training
you need to include in your documentation so they can become functional with
the software. Finding out that 85% speak English and 15% speak Spanish isn't
going to provide that information.
The difference? By avoiding the whole "what language do you speak?"
demographics question, you focus on the important aspects: whether they
speak your language and what kind of training they'll need if they don't.
You can apply this to all other aspects of your audience analysis with a few
variations. But:
<<I realize that audience analysis is often a highly intuitive and informal
process>>
It shouldn't be, but yes, it often is. Heuristics are marvelous tools, but
the problem with them is twofold: First, they can only test things that
you've already decided to test (and thus included in the heuristic); as a
result, it's easy to miss important factors that significantly affect
usability. That's not a fatal flaw provided that you're prepared to consider
the heuristic as an evolving tool (a "work in progress"), not something
static. Second, many people incorrectly assume that a heuristic is
sufficient unto itself; it's not, and the only way to discover what's
missing from a heuristic is to periodically test it (usability testing or
the like) to confirm that the heuristic remains valid and that it relates
strongly to producing a usable product.
<<we need to be able to capture audience profiles in writing as a way to
make sure we all share an understanding of student needs and preconceptions
about the topics we have to teach.>>
One useful way to do this in a classroom environment is to find out where
the students are coming from in terms of background (e.g., what prerequisite
courses they've already taken) and where they'll be going next (e.g., what
followup courses you must prepare them to take). Hopefully the instructional
designers on the list can provide more details on this; I'm a trainer by
circumstance, not background, so I'll likely miss something. <g>
<<Most of the software engineering contingent do not understand the
rhetorical purposes of audience profiles and tend to write off that kind of
information as "marketing fluff.">>
The trick is to explain it to them as a functional spec, kind of like an
input/output diagram for a function or subroutine. _That_ they'll understand
and appreciate.
--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html
"The most likely way for the world to be destroyed, most experts agree, is
by accident. That's where we come in; we're computer professionals. We cause
accidents."-- Nathaniel Borenstein
IPCC 01, the IEEE International Professional Communication Conference,
October 24-27, 2001 at historic La Fonda in Santa Fe, New Mexico, USA.
CALL FOR PAPERS OPEN UNTIL MARCH 15. http://ieeepcs.org/2001/
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
