atw: Re: Audience Analysis
- From: "Michelle Hallett" <michelle@xxxxxxxxxxxxxxxx>
- To: <austechwriter@xxxxxxxxxxxxx>
- Date: Sat, 21 Nov 2009 11:51:29 +1100
Have you read a book called The Design of Everyday Things? It seems to be
saying that objects themselves should provide clues as to how to use them
(for example, an object should show us by its structure where it should be
held). This is not so easy in an online or printed environment though some
clues have developed through usage, eg underlining and hand cursor says
'click here and something will happen'.
We could give some more thought to how that concept might be adapted to
documentation. I don't know how but hopefully someone else might. I think
it's useful because as Peter says: "Sure, a lot of them were simply lazy and
hadn't read the docs at all --- but then, that's an indication of a serious
problem, too"
I have to confess I rarely get what I need from online help and find it is
mostly structured as a printed manually with hyperlinked chapter headings
with some lip service paid to the fact that users will dip in and out of the
help as the need arises. I think wikis might add to this, with users able to
contribute their difficulties using documentation and how they went about
finding what they needed. This might be used as source material for updating
online documentation.
Having recently bought the Microsoft Vista Resource Kit for around $140
because I had trouble getting my Vista laptop to see a wireless printer and
finding that the section on printing in Vista was largely propaganda for the
many wonderful things Microsoft have incorporated into Vista, I find I'm a
little concerned about the documentation coming out of Microsoft these days.
Their manuals weren't always quite so bad, though I have never thought
Microsoft manuals were particularly good.
Michelle
_____
From: austechwriter-bounce@xxxxxxxxxxxxx
[mailto:austechwriter-bounce@xxxxxxxxxxxxx] On Behalf Of Peter Martin
Sent: Saturday, 21 November 2009 11:04 AM
To: austechwriter@xxxxxxxxxxxxx; austechwriter@xxxxxxxxxxxxx
Subject: atw: Re: Audience Analysis
Michelle Hallett wrote:
> Following on from my comment to Brian, I got to thinking (always
dangerous, I know) and
> it seems to me that we don't talk much about audience analysis and how
it's done on
> this list.
>
Hey, wait a minute.... I think you might have missed a bit back there.
:-)
I thought I'd been trying...
(Although it looks like you might be right, for all the impact ..... nah...
never mind!)
> I'm wondering what people mean by audience analysis. I've always thought
we meant
> pitching our text to the audience (what jargon do they understand, how
educated are
> they etc). I'm wondering if we should also include our audience's reading
habits, as in
> the example I gave to Brian where newspaper articles are structured to
take advantage
> of the way in which newspaper readers shift from article to article as
they read or on
> the internet, where readers skim what is visible on the screen and based
on the content
> can elect to scroll further. Some of what Christine's saying may relate to
this (though
> she should comment on this).
>
> It seems to me that no one reads a user manual from beginning to end.
Maybe they read a
> business case that way (though I suspect they decide after the first few
paragraphs
> whether to read on). How many of us structure user manuals the same way we
structured
> our uni essays? How many of us think about structure? (Note, I'm not
accusing anyone,
> I'm raising this as something we might discuss).
>
Yep. Reading patterns of user manuals never seem to be linear, and usually
docs seem to be things to be dipped into when in trouble.
I like to think I think about structure right at the start of the
documentation process, and I suspect all of us tend to. But I'm not sure
I've come up with too many answers, although I confess to a tendency to go
along with some of the basics of the Information Mapping kind, partly
because I'm initially aware of what I needed to find out first before I
could write stuff.
Problem is to determine which bits of a user manual people actually do read,
and that seems to be as variable as almost all the other factors.
I came to the conclusion some time ago that one of the most important things
you can do is provide indexes and finding aids to go with the docs --
although convincing project managers that that last-minute addition is worth
it is not often easy. An observation I read somewhere a suggestion from
someone that Microsoft manuals usually didn't actually fail to provide
information -- rather they provided it without much indexing, using terms
that weren't necessarily in common usage amongst all readers, and sometimes
included it in places you wouldn't expect it. That struck a chord, and has
influenced the approach I try to take ever since... subject to the usual
limitations -- because it was confirmed by observations of some of the
patterns reported by people in a very professional Support team I worked
with. They quite often had queries from users about information that is
already in the documentation, and I think if you can do a post-mortem
analysis on that, you find some interesting things you may need to change.
It was helpful for example, to try to find out where people had been looking
for the information they hadn't found.
Sure, a lot of them were simply lazy and hadn't read the docs at all --- but
then, that's an indication of a serious problem, too.
Structure may not always be the answer, but looking at the usage patterns
that work is a complex issue.
From time to time, I suggest in online docs that we set up some scripts to
check hits on various parts of the documentation set. It'd be interesting
to see which bits get read, which get ignored etc.. And that should
presumably inform ideas on online doc structures. Never seem to quite get
anywhere with that one, though.
-PeterM
peterm_5@xxxxxxxxxxxxxx
I like a man who grins when he fights. - Winston Churchill
************************************************** To view the austechwriter
archives, go to www.freelists.org/archives/austechwriter To unsubscribe,
send a message to austechwriter-request@xxxxxxxxxxxxx with "unsubscribe" in
the Subject field (without quotes). To manage your subscription (e.g., set
and unset DIGEST and VACATION modes) go to
www.freelists.org/list/austechwriter To contact the list administrator, send
a message to austechwriter-admins@xxxxxxxxxxxxx
**************************************************
Other related posts:
