Are you using personas?

["Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>]

Steven Brown wonders: <<One of the latest trends in our industry is the
"persona," which as most of you probably know is
similar to a user profile but is actually very different... Are you creating
personas before you create documentation?>>

I've been using something similar for years before I ever realized it was a
trend; I just called it "roles". <g> Cooper Design (a bunch of pretty bright
folks, by the way... like Neilsen without the ego or arrogance <g>) claims
to have invented the concept of personas, but in my opinion, all they've
done is take the Information Design route: neatly package stuff that has
already been out there in the public domain for years. More power to them if
they can get this idea spread through the industry; the fact that the
knowledge has always been out there doesn't do us much good as a profession
if we don't use it.

By calling "personas" a trend, you unintentionally do it a bit of an
injustice, because we techwhirlers instinctively think "trendy = short-term
fad". In fact, using personas provides a sound and logical approach to
figuring out how to design products and documentation. Think of it this way:
People take on different roles when they use a product. One day, I may be
the Manager Persona (I have to install and configure the software); the next
day I'm the user (now that it works, I have to use it); the following day
I'm technical support (why isn't it working anymore?).

Each of these roles entails certain tasks. To accomplish anything with a
product, you need to know two things: (i) what you're actually trying to
accomplish, which isn't necessarily what you thought you're trying to
accomplish. (ii) the most logical path to getting there, along with any
alternative paths that some users might prefer (e.g., keyboard shortcuts
rather than mousies).

I've been an outspoken critic of "demographic" audience analysis for most of
my career simply because I don't consider it relevant--at least not as the
first thing you do. If you want to print a document, for example, your
demographic characteristics are irrelevant: everyone who adopts the role of
"guy or gal who wants to print" needs to know the Control-P keyboard
shortcut or the "open the file menu and select print" mouse path. Provided
you speak English and know the difference between the mouse and the
keyboard, the remainder of your demographic characteristics (age, sex,
gender, income, computer experience) are essentially irrelevant

Okay, I did say the latter as a bit of a troll. Let me clarify: when I say
"irrelevant", I mean that providing a clear, direct, comprehensible,
foolproof explanation of how to accomplish something makes that something
possible for _all_ your audience. Understanding some of the demographics as
a _second step_ helps you do it better. But you can still do a good job if
you ignore demographics; you can't hope to succeed if you don't describe how
to perform the task right, no matter how demographically elegant and
appropriate your writing. (And fonts. <g> Andrew Plato routinely--and quite
appropriately--takes us to task for ignoring the meat of our work, which is
describing something accurately and well.)

<<If so, how have they made a difference in the documentation you deliver?>>

They don't much affect how I write. What they do pretty much guarantee is
that I cover all the important things people want to do with our products,
in a way that's logical to those people.

--Geoff Hart, geoff-h -at- mtl -dot- feric -dot- ca
Forest Engineering Research Institute of Canada
580 boul. St-Jean
Pointe-Claire, Que., H9R 3J9 Canada

"Technical writing... requires understanding the audience, understanding
what activities the user wants to accomplish, and translating the often
idiosyncratic and unplanned design into something that appears to make
sense."--Donald Norman, The Invisible Computer


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Help Authoring Seminar 2003, coming soon to a city near you! Attend this
educational and affordable one-day seminar covering existing and emerging
trends in Help authoring technology. See http://www.ehelp.com/techwr-l2.

A new book on Single Sourcing has been released by William Andrew
Publishing: _Single Sourcing: Building Modular Documentation_
is now available at: http://www.williamandrew.com/titles/1491.html.

---
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.