RE: What Are Writing Skills?

["Sharon Burton" <sharon -at- anthrobytes -dot- com>]

Tony, I really don't care what you call good engineering or bad engineering.
Every engineer I've known, every kind of engineer I've known, including the
one I was engaged to (who was a breath-takingly brilliant engineer), is
interested in what the technology does, not what you want to do with it.
It's what we want engineers to do. We want them to think of cool technology
and then build it. It's up to others to see the value of the cool technology
and come up with things for people to use it for. Hell, the engineers that
developed TV and then radio couldn't really think of a use for these
technologies. It's true - look it up.

No one here is saying not to analyze the technology they are writing about.
What we are saying is that Hooray! you seem to have found one way that works
for you. But it's just one way that works for you. There are other ways to
analyze the technology and get the same or better end result than what you
are doing. The point to all of this is:

Are you writing useful product documentation that makes your users lives
easier? Are you delivering that documentation to them in a way that makes it
easy for them to find that information? Are you meeting your users needs?
Are you hitting your deadlines?

I personally don't care if I ever understand how the data flows in a product
I'm writing about. It makes little difference to me if I ever figure that
out. If making pretty pictures makes it easier for you, then, well, that's
great. However, you are clearly a visual learner and pictures _would_ make
you very happy. I am not a visual learner. I am a hands on learner. Your
pictures would deeply frustrate me because they would make no sense to me.
They would tell me nothing about the product in a way that I can understand.

However, give me the product and let me work it for a few days and I will
understand what the thing does and how it does it. And what the users need
to know about the product. And why they need to know that. And have a
logical breakdown of the tasks they need to do in the product. And a content
spec. And a user analysis. And maybe a few scenarios.

My guess is that your product docs have a lot of pictures in them,
reflecting your visual learning nature. What are you doing to support the
other learning styles in your audience? Have you thought about that? What
has your DFD analysis told you about how to support the auditory learners in
your user base, for example?

What has your DFD analysis told you about how you should best index for
irretrievability? About how you should design your online help so the users
get both the big picture and the info they need, without putting too much
info on the screen that research shows they won't scroll? How about the
Getting Started manual? What does your DFD tell you about that? Did your DFD
tell you anything about the users who used a competitors product and how to
move the user from that product to this one in the most simple way possible?
How about the online training? How about the situation where the budget
allows for a 40 page manual when a 300 page manual is really needed but the
client has no money for the big manual? How do you decide what goes in
there, given the client doesn't have the budget or time for you to make a
DFD?

In other words, you have a nice tool that seems to work for you to do some
things. What other tool do you have in your kit for when that tool is
inappropriate? Not all tools are appropriate for everything. That's part of
what makes a senior writer - the understanding that having many tools in our
bag is a big help. Oh, that, and humility.

sharon

Sharon Burton
CEO, Anthrobytes Consulting
951-369-8590
www.anthrobytes.com
President of IESTC

-----Original Message-----
From: Tony Markos [mailto:ajmarkos -at- yahoo -dot- com]
Sent: Saturday, February 26, 2005 11:58 AM
To: sharon -at- anthrobytes -dot- com; TECHWR-L
Subject: RE: What Are Writing Skills?



--- Sharon Burton <sharon -at- anthrobytes -dot- com> wrote:

How you understand how the product works may very well
tell you nothing about what the user uses the product
for.

The engineers understand how the product works. What
they don't always understand is now the user will user
it to do their tasks.

Tony Markos responds:

This borders on confusing poor engineering with good
engineering.  Any good engineering analysis
methodology focuses first and foremost on the
end-user: his/her goals and tasks and how those all
those goals/tasks interrelate.

As any good engineer knows: A rigorous, comprehensive
understanding of essential end-user goals/tasks, and
how those goals/tasks interrelate forms the high-level
architecture within which all technology is properly
"pigeon holed".

Granted, this is not how the vast majority of
engineers function (dispite the claims of some TW's on
this listserv claiming to know alot of people-oriented
geeks).  But please don't equate poor engineering with
engineering.

Sharon Burton wrote:

For example, the cash register manuals I have talked
about were originally written by engineers. They were
literally useless to the user - there was no
understanding of the tasks the user needed to perform
when they used the cash register.

Tony Markos responds:

I don't doubt you one bit.  What I am saying is that
they knew better, but choose - for their own comforts
sake - to bastardize the engineering approach - to
deprioritize people and put highest priority on
technology.

Sharon Burton:

Structuring the information refers to climbing in the
users head(s) and identifying those things the user
needs to know to use the product for what the user
wants to use the product for.

Tony Markos:

"..climbing into the users head(s) and identifying
those things the user needs to know to use the product
for what the user want to use the product for." is a
defintion of good analysis.  Has been for decades!

FIRST we analyze the users and the technology that
they have/will have - ALWAYS giving the user top
priority, THEN we use this understanding to structure
our information for presentation.

And, as I said before, if our analysis is any good -
the structuring of information for presentation is
going to be very straightforward.



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

WEBWORKS FINALDRAFT - EDIT AND REVIEW, REDEFINED
Accelerate the document lifecycle with full online discussions and unique feedback-management capabilities. Unlimited, efficient reviews for Word
and FrameMaker authors. Live, online demo:
http://www.webworks.com/techwr-l

Doc-To-Help 7.5 Professional: New version with new features, improved performance and reliability, plus much more!  Download your free trial today at www.componentone.com/techwrlfeb.

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