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.
> He qualified what he said by writing: "If the way you work is broadly
> representative, and you experience problems, then many other users will
> experience similar problems--that makes you an expert in the use of the
> tool, and an expert judge of whether that tool is effective."
I challenge you to find someone who does *not* tell you that the way
they work is broadly representative of their software-using peers.
When you do find that person, then you *know* that you can trust that
the info they give you is niche-only. Everyone else you get feedback
from will be a wild card. ;-)
> Geoff didn't say that it was, and I think he clearly made the distinction,
> saying that valid user feedback can be helpful along with formal usability
> studies.
...if you know what to do with it. Most people do not.
> Again, he's not saying this is a replacement for usability studies. He's
> saying that both usability studies and individual feedback are important in
> ascertaining *actual* usability.
But that is not a correct statement. Individual feedback *can be*, but
seldom *are* the individual info bits relevent to anything but how
someone would like the product changed to their benefit.
> > And frankly, I think you're misleading writers saying they
> > can do this with no training or experience. They can't and
> > they shouldn't. We should not be encouraging inexperienced
> > writers to go sticking their noses into an area of design and
> > development that they are not qualified to do.
>
> I didn't get the impression he was promoting what you say he was.
I certainly did, which is why I also replied in opposition to Geoff's post.
> Feedback is generally not considered to be griping.
TomAto, tomAHto... It all depends on how it's presented and received.
Most customer feedback *is* griping. Not to say it's wrong for them to
provide such feedback, nor to say that all griping is not valuable,
but let's call a duck a duck here. ;-)
> > > Just state
> > > your case helpfully, as a team member, rather than
> > proclaiming from a
> > > position of overt moral superiority.
>
> Technical writers do this with great success all the time. It's very easy,
> actually.
I find that many technical writers are actually quite poor at
providing this type of feedback to their project teams. It's amazing
that someone whose job is to develop a successful message can botch
good project relationships by not considering their internal audiences
as well. Not to say this is an epidemic case, but it happens more so
than not.
> If you're documenting a product and can't find a simple feature, or driving
> an automobile and can't see out the rear window properly, you're an
> authority on using the product in your particular circumstances.
Which may or may not be relevant. If I'm using Word to create
mechanical drawings and can't find what I need to properly scale the
drawing, I'm not using the product correctly. Likewise, if I've turned
my rearview mirror into a coathanger or curio hook, I'm not using it
correctly to see out the rear window.
> If a software element is hidden or too complicated to get to, you'd be
> negligent in your job as a technical writer if you didn't mention it.
But this isn't a usability issue, per se. It might be, but it isn't
always the case.
> If a GUI issue comes to my attention that I feel needs talking about, I
> don't hesitate to ask a developer about it and explain my concerns. I've
> found that most people view questions about GUI as just another topic;
> nobody feels threatened.
All well and valid, and you should continue to do so. But, this type
of feedback isn't necessarily a replacement for or a portion of proper
usability practices. In fact, how you present this info to the team
may be counter-productive to usability goals!
> I feel it's a disservice to my client if I ignore things that may cause
> ultimate market rejection of a product. Asking never hurt anyone, and the
> notion that developers think I'm "jamming my nose" into design issues
> because I ask a question or offer an opinion that something is a bit
> difficult to find is an unjust projection onto developers of
> unreasonableness.
There's nothing wrong with that. However, please bear in mind that
there are many writers out there who work on a day to day basis not
knowing the make or break points of their market's acceptance of a
product, nor would they know good software design from bad. It's all
relative, which is why you need someone in place to keep all this in
mind and be the stop-gap for all product feedback and user testing.
ROBOHELP X5 - SEE THE ALL NEW ROBOHELP X5 IN ACTION!
RoboHelp X5 is a giant leap forward in Help authoring technology, featuring all new Word 2003 support, Content Management, Multi-Author support, PDF and XML support and much more! View an online demo: http://www.macromedia.com/go/techwrldemo
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit http://www.techwr-l.com/techwhirl/ for more resources and info.
