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.
Subject:Understanding... and active ownership From:Susan Harkus <susanh -at- CARDSETC -dot- COM -dot- AU> Date:Thu, 8 Jul 1999 09:08:39 +1000
I have really enjoyed the contributions of everyone who has participated in
this thread. It is obvious that product knowledge and user task knowledge
are always going to be challenges to us... and we shouldn't forget the"
user learning styles knowledge" that ultimately determines whether what we
deliver will be really usable - the latter being a key pillar of
The subject matter expertise required to design and develop supportive
information products goes far beyond what organisations think an SME is. In
fact, the information I draw from the technical experts is usually
information and insights that they haven't thought of but that come out
through exploring user task objectives together. So we should distinguish
between a writer being an SME and an engineer being an SME because the
writer's subject matter expertise is much wider and as a number of people
pointed out, is also user-focused.
When I use information I want it to support my task objective. For example,
I wanted to set up Appendix heading styles in Word. Naturally, I wanted the
sub-ordinate headings to number from the first level Appendix heading. It
took several hours to achieve because each Help topic explained only what
to do to achieve a particular end and nothing explained the full picture,
in particular how to enable the sub-ordinate heading numbering.
I am sure the people who wrote the Help understood what to do but never
thought about the likely "whole" purpose of the action. They failed me..
just as the Visual C++ documentation failed our GUI development team when
it was trying to set up various Help calls.
If we cannot add value by documenting more than the "what", if we cannot
provide the why and when insights, if we cannot prevent the user
fall-overs, if we cannot help the user develop a sense of being in control,
we are not doing very much because they are the basic things that
user/readers expect... AND it is impossible to provide that required level
of performance support in our information deliverables if we don't take
responsibility for developing our knowledge across the product, the user
task domain and user learning styles.
I accept that project timeframes, organisation blindness to our role, lack
of resources and anything else you can think of will constrain our
realisation of our goals but they mustn't prevent us chasing the knowledge
we need to make good design and content decisions.