Hey, Cal! 

Or embedded help might be an option. But we're guessing what they want. Ask
*them* - they contact the writer asking for help. At that point, call them
or email them asking for time to talk about what they need. 

Altho it's really hard, explaining what you're doing doesn't help. You don't
get to decide if what you've done is the right stuff. The users get to
decide that. Your users are telling you that what you provide is the wrong
stuff. Only they can tell you what the right stuff is. 

This is the ethnographic part of what we do - talking to people, looking at
how they do what they do, asking questions about how they do it. Then you
figure out how to provide user assistance that fits what they need. 

sharon

Sharon Burton
951-369-8590
IM: sharonvburton at yahoo.com
Blog: madcapsoftware.wordpress.com


-----Original Message-----
From: framers-boun...@lists.frameusers.com
[mailto:framers-bounces at lists.frameusers.com] On Behalf Of Cal Callahan
Sent: Wednesday, May 20, 2009 5:56 PM
To: framers at lists.frameusers.com
Subject: Re: Motivating end users to read the user manual

I like Sharon's advice (ask the user directly). But I haven't seen anyone
mention context-sensitive help or conditional text.

I hope the lengthy paragraphs in your query are not representative of your
manuals--that would certainly turn off users.

A couple of guidelines:

KISS--keep it simple, sir.

Tell them what you're going to tell them, tell them what you want to tell
them, then tell them what you told them

Engineers like flow charts and logic diagrams, so fire up your Visio and try
to put the points across that way.

And everyone likes pictures, so see where you can use those. (Many people
are visually oriented and don't like to read.)

I hope I haven't insulted your intelligence. I'm just picking trees out of
the forest.

cal

Reply via email to