Usability and role of tech writer?

["Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>]

Beth Smith wondered: <<The software product I [document]... has undergone a
change within Product Marketing. As a result, they do not seem to think as
highly of the product as the previous team, and have requested a "usability
audit.">>

That's a wonderful opportunity. I hope you can figure out how to take
advantage of it.

<<I've been asked to provide a crude estimate of hours required to
review/audit the Help screens, which I gave at 500 hours. The team leader
for the front end estimated that for the other parts of the system, he'd
need to go through about 200 screens to do a comprehensive audit...page by
page.  He estimated it would take about 7 hours per screen, on average, to
run an audit.>>

These figures seem awfully high unless you're talking about full-blown
usability testing with real users of the software. Any interface that could
reasonably take an average of 7 hours per screen to review clearly needs
considerable simplification.

<<However, I think that the interface itself needs a redesign (alignment,
color, proximity, typography is relatively amateurish). From my perspective,
you have to define what is "usable" before you know what you have to do to
enhance usability. At the very least, maybe checklists could be used as a
benchmark for comparison. I think part of the problem with this audit is
that no one provided a definition of what exactly "usability" is, so we
don't know what criteria to compare our product against.>>

Since Marketing is the group that asked for the audit, your first step
should be to work with them to develop a list of somewhat objective criteria
for what they consider to be usability. Some of these may be as simple as
what you suggested (redesigning the screen layout), but others may require
fundamental changes to the software. See if you can find out what their real
and hidden agendas are; you'll need to know this to figure out how much
tiptoeing you need to do, how to work with the various personalities
involved, and so on.

I suspect that some significant redesigns will be required, this would
certainly explain the developer's high estimate for time requirements: He's
probably scared to add this much work to his team's workload, and thus
inflated his estimate in the hope that Marketing will back down. That being
the case, the second thing you'll need to do is talk to the development team
leader to find out his real and hidden agendas, because if you'll be
involved in this exercise, you'll need to reconcile these with the Marketing
team's agendas. If you're not formally part of either team, you have less
invested in this situation, and are ideally suited to become the peacemaker
between the two teams and to carve yourself a new and influential niche in
your company. Sounds like something worth trying!

<<I am very confused and would love advice on how to handle this
situation.>>

Given that you've documented the software already, you should have a clear
idea of the parts that strike you as ripe for a redesign. (Anything that had
you tearing your hair out trying to come up with a simple explanation should
be at the top of your list: hard to document = hard to use.)

One great way to get everyone onboard: demonstrate some simple (low time
investment from the developers), high-payback (obvious improvements)
interface changes. These are easy for you to do, easy for the developers to
implement, and show obvious improvements that satisfy Marketing. Starting
with these improvements and demonstrating successes lets you convince
everyone that the changes aren't inevitabley as horrible as everyone feared.
That gives you some capital to build on for requesting or suggesting more
detailed or demanding changes.

How do you quickly and easily propose interface redesigns? Well, you could
always do the "paper prototyping", but that's fairly primitive. Instead, why
not build dialog box mockups directly in Microsoft Office? See one of my
online articles for details:
Hart, G. 2001. Using VBA to prototype a software interface.
www.soltys.ca/techcomm/articles/Using_VBA_to_Prototype_a_Software_Interface.
html
(Since this article was written, I learned you can do this in Word too.)

If you're not keen on this approach, you can quickly and easily achieve
equally impressive results using any Web authoring tool. I've used
Dreamweaver to create fake interfaces with complete interactivity (e.g., the
interface buttons become hyperlinks to new Web pages, radio buttons and
dropdown menus are easy).

If you want more detailed examples of a simple and powerful approach to
iteratively redesigning an interface, have a look at another of my articles:
Hart, G.J.S. 2003. Redesigning to make better use of screen real estate.
Pages 337-350 in M.J. Albers and B. Mazur, editors. Content and complexity:
information design in technical communication. Lawrence Erlbaum Associates,
Mahwah, N.J. 368 p.
This particular one includes a batch of useful literature citations that
should also help.

--Geoff Hart, ghart -at- [delete]videotron -dot- ca
Forest Engineering Research Institute of Canada
580 boul. St-Jean
Pointe-Claire, Que., H9R 3J9 Canada 

"Wisdom is one of the few things that look bigger the further away it
is."--Terry Pratchett

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

ROBOHELP FOR FRAMEMAKER TRIAL NOW AVAILABLE!

RoboHelp for FrameMaker is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to online Help, intranet, and Web.  
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! Call 800-718-4407 for 
competitive pricing or download a trial at: http://www.ehelp.com/techwr-l4

---
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.