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.
> My question: What's an effective way to approach
> a touchy, rather defensive SME to offer help in
> designing a GUI? Nothing that smacks of implied
> criticism will work; she's very thin-skinned.
> Also, her command of English is less than
> perfect. Any suggestions would be very much
> appreciated. Thanks.
I'm currently doing the same thing at my company: documenting a GUI
that could use some work on the interface. I'm lucky - the developer
is extremely good to work with and has been receptive to my suggestions
so far. But I don't want to overwhelm him with ALL the details that
could be improved, partly because he's on a tight schedule. So I've
been thinking a lot about these very issues.
I have decided to organize my comments into 3 categories: terminology
problems, organization/usability issues, and layout problems. Then, I
prioritize each of the lists. If an item is at the bottom, or if it's
something that another team member could report, I drop it (for now).
This takes more time than just putting my head down and typing. Why am
I doing this? Because a confusing or poorly organized GUI is much harder
to document. (And, of course, to use!) As the user advocate, I must
explain how a user can accomplish their tasks. If the interface is
confusing, I'll end up writing more documentation that will in itself
be harder to use. Because my goal is simple, easy-to-read documentation,
working on the GUI makes my job much easier in the long run.
My suggestions: Try to to build a working relationship with Rita, and
stay in touch on a frequent basis. (I've found that personal visits and
phone calls are preferable to email - less chance of misinterpretation.)
Chat about user problems with the old interface. Make yourself available
as someone Rita can bounce ideas off of. Offer to be a tester for beta
versions of the GUI. Ask, often, what kind of feedback Rita would prefer.
And prioritize, prioritize, prioritize. Decide what changes would make
the most impact, and ease off on the small stuff. If Rita is emotionally
attached to a term that makes your hair stand on end, but the term can be
explained easily in the help file, let it go; better to focus on clear
buttons and organization. Most importantly, always try to acknowledge
that you are both working on the same goal - making a good product for
your users. You want Rita to see you as a helpful team member; this might
involve some compromises as you build your reputation with her.
And if you see that Rita works well with other team members (developers
or testers), you could suggest that they work with her to review the GUI,
so that criticism doesn't seem to be coming from you only.