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:Re: Business Process Information in a User Guide From:"Michael West" <mike -dot- west -at- oz -dot- quest -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Wed, 5 Sep 2001 14:54:28 +1000
> In the latest version of the manual I have been asked to include these
> business process maps in the user guide. I objected for two reasons:
>
> 1. These diagrams use a specialised notation which is not immediately
> understandable to an audience unfamiliar with business process
> analyis.
> 2. The second point is more difficult to define: The view in this kind
> of business process analysis is very much a business process
> consultant type of view. I'm having difficulty reconciling this
> view with the view I'm using as amy focus for the user guide, that
> of a user who needs to use a software application within this
> business process
The first thing I would do is ask whoever it was
several questions, among them:
* who needs the process diagrams?
* why do they need them (that is, in support of which task)?
* when do they need them?
This should help clarify the issues. Quite possibly
the requestor has not thought carefully about what
a user guide is and how it is used. Perhaps he/she
thinks of it as a text that is to be used by managers
rather than users (rather like an "implementation
guide" or "application administrator's guide").
It may be that a user guide is not really what your
manager is expecting. You may need to educate; to help
others understand how content must be tailored
to user needs. A manual that attempts to be all things
to all people will never be used by anyone.
You might need then to rethink the high-level design
of the user-assistance package. You may need
something to supplement the user guide -- something
that provides the high-level management perspective
that your manager seems to be recommending.
One could go on speculating; the point is to identify,
define, and agree with your manager the audience(s)
and the information need(s).
Having said all this, I certainly agree with others in
this thread who have emphasized the need for task-based,
results-oriented content for users. That does not in itself
prohibit the use of business process flow diagrams, as
long as they are carefully positioned and clearly defined
as to their use and purpose.
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/
+++ Miramo -- Database/XML publishing automation. See us at +++
+++ Seybold SFO, Sept. 25-27, in the Adobe Partners Pavilion +++
+++ More info: http://www.axialinfo.comhttp://www.miramo.com +++
---
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.
