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:Reflexive responses: forwarded for a colleague From:"Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA> To:"Techwr-L (E-mail)" <TECHWR-L -at- lists -dot- raycomm -dot- com> Date:Thu, 5 Oct 2000 08:30:49 -0400
Forwarded on behalf of a colleague who had some very interesting things to
say about this issue.
--Geoff
-------------------------------------
I agree that we ought to be aware of reflexive responses in users and use
them to our advantage. However, most of the time when I do that (or have
noticed it being done), it's done to make sure users are aware of
information they would usually skip. It's not really changing the effect of
a reflexive response, but rather making people not be able to do that
response in the first place.
I know that there are some software installations that make you click a
checkbox or press a certain key before you can click Next on the license
agreement page. I think the Windows installation does this. During an
install, a user's normal course of action is to just keep clicking Next
until the files start copying. In these cases, you have to actually be aware
that you are on the license agreement page. Of course, no one can MAKE you
read it, but at least you know that you were responsible for agreeing to the
terms.
Because I've spent some time in tech support and know what it's like to get
calls from angry people who messed something up because they "overlooked"
important information, I try to think of creative ways to get information
out to my users. On the most elementary level, I think (or hope) that most
of us on this list use features in our text that draws readers' attention to
information that is critical or even information that wouldn't be obvious to
most users. We use a style tag called Note that always begins with either
"Note," "Important," or "Caution" in bold. I think most people have
something similar. One of the first things I did when I came to the
Documentation department (from Support) was I asked people to stop putting
the notes on the first introductory page of each chapter. The information in
the notes is always really good, and most people skip over the first page in
the chapter because it just gives an overview of what follows. It's much
more visible on the next page where the real "meat" of the chapter begins.
Taken to the next level, we can incorporate this into the interface. A few
weeks ago I went to a design meeting for a Web-based application we make.
This application has a feature that allows users to change field names. You
open the form, enter the changes you wish to make, and then click OK. The
developer wanted a pop-up box that said you had to restart the Web server
for the changes to take effect to appear after you clicked OK. Knowing that
users tend to click away error messages without reading them (much like you
mentioned in your original example), I suggested that we just put the
warning next to the OK button on the form. More users will see it there, and
even if they miss it the first time, they may notice it when they go set the
changes again after they notice that the changes didn't take effect. It
won't work for every user, but it will probably save a few phone calls.
As with any type of technical communications, knowing your audience is
important here because otherwise you won't know what their reflexive
responses are. I used to think "tip of the day" boxes were pointless because
everyone knows that all users turn them off. While talking to our customers
on the phone, I found that wasn't true in our case. It makes sense. We make
maintenance software that is generally used by people who perform work on
machines used in production environments. These people aren't computer-savvy
as a general rule. I'm pretty sure the reason they haven't turned off the
tip of the day feature is because they don't know to look for the checkbox
on the bottom that turns it off. Of course, they will eventually quit
reading these tips, but we can make sure that the first one or two that show
up have the most important information in them.
Sorry this is so long, but I try to work a lot of "usability" into our
software, and much of what makes software usable is just making sure the
customers know vital pieces of information. I can't post to the list because
I read this from a public email folder we have at my company and I'm not
technically a member. I just wanted to make sure you did get at least one
positive response. I thought your observation was good, and I felt sorry for
you when everyone started disagreeing. :)
Amy Griffith
Datastream Systems, Inc.
Documentation
Ext. 5040