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:Re: GUI battle with a developer From:"Marie C. Paretti" <mparetti -at- RRINC -dot- COM> Date:Tue, 1 Sep 1998 18:06:51 -0400
At 04:58 PM 9/1/98 -0400, Suzette wrote:
>I have a small situation that I would like some advice on how to handle.
I am
>currently documenting a rather complex application. Part of my job involves
>user testing, so I usually try to mention potential "hazards" in design
before
>an application gets to the user testing phase. Most developers are
comfortable
>with this and at least discuss/consider suggestions.
<details snipped>
>Seriously, did I have a reason to get upset (guilt is setting in). How would
>you guys have handled this situation?
>
It sounds as though you work regularly with developers on GUI questions, so
it's hard to say where this one went wrong. I also do a lot of
user-interface testing/design as part of my job, and my approach in these
situations is make sure that I have a list of positive suggestions (as well
as things I like) rather than simply a list of things I don't like.
In this case, it does sound like the View menu and the initial screen are
both confusing, but instead of "getting upset" and responding to the
developer's defensiveness (afterall, s/he spent lots of time on the product
and probably does feel protective of it), I'd take the "catch more flies
with honey than vinegar" approach. I.e. "This seems like a very powerful
program, and in playing with it there's a lot in here, but I think we could
work with the interface to make the features more accessible. For example.
. . " and then I'd launch into a redesign discussion with suggestions about
what to see instead of a gray screen, what other buttons or menus should be
available and what options should be under each, etc. And I'd keep checking
in with the developer to see what his/her reactions are - "Does that make
sense?" "How hard would it be to change. . .?" "How do you see it?" I find
that "How hard is this to change?" is actually an important question
because it lets developers know that I understand their time constraints
and often gives us a better basis for negotiating what changes will go in
this version and what things are for the next release.
It sounds like you need to meet the developer on "common ground" so to
speak - you both want a good product that will make users' lives easier. So
if it were me, I'd take the high road, apologize for expressing your
frustration (rarely a good idea even when you're right) and suggest a
*collaborative* meeting about the GUI. Tell the person that you respect
their work, etc., but in spending time with the app you have a few ideas on
how to improve it. Emphasize that you share the developer's goals and want
the product to be a success. In other words, even though you're acting as a
user-advocate, take the developer's side to some extent, and present your
suggestions from that perspective.
In short, it sounds like a personality/communication issue with this
developer and what's called for here are smooth interpersonal skills. I'd
try working this out one-on-one before I went to anyone's boss or called
for outside reinforcements.
Those are my Tuesday-evening thoughts. Good luck.
Marie
Marie C. Paretti, PhD
Recognition Research, Inc. (RRI)
1750 Kraft Drive, Suite 2000
Blacksburg, VA 24060
mparetti -at- rrinc -dot- com http://www.rrinc.com
