RE: Should the Doc Manager be equal to the Dev Manager? Response

["Glenn Maxey" <glenn -dot- maxey -at- voyanttech -dot- com>]

> -----Original Message-----
> From: Teemu S. [mailto:tselane -at- home -dot- com]
> Sent: Tuesday, August 14, 2001 1:49 PM
> To: TECHWR-L
> Subject: RE: Should the Doc Manager be equal to the Dev Manager?
> Response
> 

> Over the past year, I have focused on asking for improvements 
> to the user interface. 
> I explained that a better UI would require fewer pages of
> explanation, which saves the company lots of money in tech 
> writing time and translation costs. 

Another very powerful argument is that a better UI also reduces training
and support costs.

> My boss finally accepted this. But he has 
> no one able to improve the UI. 
> All of the developers are terrible at UI, 
> except one who is dedicated to a year-long project. 
> So if I wanted improvements, I had to do them. 
> I was delighted at the opportunity, but can not follow 
> through without compromising several other more important projects.

Here is a compromise based on what I learned attending UIE's "Product
Usability: Survival Techniques" course. Do a paper-prototype. I know,
very low-tech... but very effective at getting the message across of
where the problems are. Doesn't require a lot of time to snip of manilla
folders (because they're sturdy), write on them with markers, and come
up with drop-down menus, dialog boxes, etc. similar to the interface. It
doesn't have to even do the whole interface; just the areas that are
problematic.

Show this prototype to the developers -- even those terrible at UI. Have
them "run the program" through this paper protype. Have them do some
task. They will immediately see the problems. You can suggest and make
changes easily. Once the paper prototype has demonstrated the sequence
that is most logical and friendly, the developers will know what they
can do to improve the UI.

Then let the developers implement this change while you focus on what
you're good at.

Just a few days after I came back from this course, I took a
specification for a new project and did a paper-prototype of what I
understood the interface to be. I first showed this to the other tech
writers. Great positive feedback! Then to the developer. You could see
the gears turning in his head! It brought to light several things he
hadn't considered (and that weren't even in the part of the UI that I
was demonstrating).

The point is, the developers can become better UI developers with a
handy, low-tech, low-risk, low-investment (time/money/programming) tool
that shows the product.

[By the way, the techniques that I learned in this course were so
"no-duh" and "I know that already" that it is embarrassing that I paid
for it. However, it took paying for it, I guess, to give it value and
importance. You don't have to take time away from work or pay for
travel, lodging, and the course to do it.]


> Question:  What changes can a development department make 
> that would help a lone tech writer produce more? Better UI through UI
reviews 
> and iterations.
> Specifications that are accurate and up to date? Bug tracking 
> processes?
> Project plans? A UI freeze some time before ship date? A 
> development freeze some time before ship date? Hiring a real tester?

If you and your developers have stepped through your understanding of
the interface based on the requirements by coming up with a
paper-prototype, it will be easy to come up with a UI early that can be
(mostly) frozen even though the underlying functionality may still
fluxate. 

An early UI freeze is what we mandated and achieved at my last employer,
because it was the only way to achieve the schedule when several
language UI's were involved. Even without the languages, the UI freeze
is important. (It should be noted that the UI freeze wasn't a hard
freeze. It was just cold enough for them to come up with some heavy-duty
justification in order to thaw it out.)

Hiring a dedicated tester will go a long way into helping YOU make YOUR
schedules. Otherwise, the technical writer is always the first tester
and must constantly deviate from their primary task of writing to report
problems. If there are testers on board, then it isn't so critical that
the tech writer report all minor problems (except those involving the
UI).

The other stuff like bug tracking and project plans help the developers.
THEY know they are needed. Geez, they learned about them in school. They
know that they can't avoid them forever. Let the developers come to the
realization in their own time; you don't have to spear-head it.

Glenn Maxey
Voyant Technologies, Inc.
Tel. +1 303.223.5164
Fax. +1 303.223.5275
glenn -dot- maxey -at- voyanttech -dot- com


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

*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com

A landmark hotel, one of America's most beautiful cities, and
three and a half days of immersion in the state of the art:
IPCC 01, Oct. 24-27 in Santa Fe.  http://ieeepcs.org/2001/

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit
http://www.raycomm.com/techwhirl/ for more resources and info.