RE: Technical writing, usability, GUI design, and how they fit together - your opinion is needed

[<laura_johnson -at- agilent -dot- com>]

You've gotten some great feedback here, and my experiences are in line with several of the others', so I'll just add a few points rather than recount all my answers to your original questions. My own role varies a lot from one project to the next, depending on my available bandwidth and on the skills and preferences of the developers designing the interface, but the teams nearly always welcome whatever usability input I do give.

In a nutshell, you want to make a shift from "complainer" to "collaborator". It is highly unlikely that you'll be able to convince management to give you final authority over GUI design, or even over the wording of labels. It's highly likely that if you establish yourself among the developers as a collaborative team member who has good ideas, you'll find yourself influencing (and liking) the GUIs a whole lot more than you do now. You may even get "final authority" later on, but that's not the main goal - the main goal is better product.

Assuming that your job title is some variation of "tech writer", your initial authority/excuse for kibitzing the UI is going to be your professional mastery of grammar and your staggering vocabulary. Don't bother being bothered by that; embrace it. (And by the way, you probably already know this, but don't use phrases like "My fellow techwriter and me keep complaining" in internal email. It undercuts that whole professional-mastery mystique thingie. ) Ask to review the terminology on the screen so you can "help establish consistency and improve the grammar". Actually do that, but also use the review as a gateway to critique screen layout, then task flow, then everything. Make sure you're reviewing early enough in the development cycle that things can actually be changed; nothing undercuts your collaborator role quite as badly as blithely suggesting a total change to the task flow on the day after code freeze.

Make heavy use of the technique others have mentioned, wherein you ask for clarification of a task flow that is difficult to document, and ask the developer to "help me understand" why it's so stinkin' complex. The explanation will be interesting and enlightening and also will provide you with an opportunity to collaborate, starting with "OK there's probably some great reason why this wouldn't work but..." and rapidly progressing to "Hey maybe it would be easier to use if we did it *this* way."

Good luck!
-Laura

-----Original Message-----
From: Robert Fekete [mailto:fekete77 -dot- robert -at- gmail -dot- com] 
Sent: Saturday, March 24, 2012 2:07 AM
To: techwr-l -at- lists -dot- techwr-l -dot- com
Subject: Re: Technical writing, usability, GUI design, and how they fit together - your opinion is needed

Thank you for everyone for your time and for sharing your experiences.
It was really helpful - and also hilariously funny at times - and
hopefully we will be able to influence the management to allow us to
help more to the developers.

Have a great weekend!

Robert



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create and publish documentation through multiple channels with Doc-To-Help. Choose your authoring formats and get any output you may need.

Try Doc-To-Help, now with MS SharePoint integration, free for 30-days.

http://bit.ly/doc-to-help

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot- 

To unsubscribe send a blank email to
techwr-l-leave -at- lists -dot- techwr-l -dot- com


Send administrative questions to admin -at- techwr-l -dot- com -dot-  Visit
http://www.techwhirl.com/email-discussion-groups/ for more resources and info.

Looking for articles on Technical Communications?  Head over to our online magazine at http://techwhirl.com

Looking for the archived Techwr-l email discussions?  Search our public email archives @ http://techwr-l.com/archives