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.
Fw: Having Your Style Guide and Eating Your Fries Too
Subject:Fw: Having Your Style Guide and Eating Your Fries Too From:"MMdeaton" <mmdeaton -at- mmdeaton -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Fri, 6 Apr 2001 14:30:45 -0700
> Jim Shaeffer said:
> Saying that "No code should be written until user requirements are final."
> seems to imply that the mid-course corrections do not include changes to
the
> user profile.
>
> ***************
> No, it does not imply that at all. Notice I said "requirements are final"
> not "user profile is final." A requirements document that all agree on
> should be final when production coding starts. If the requirements or the
> user profile, later change, then change orders need to be written and
> everyone needs to buy-off on those before the changes are made.
>
> ****************
> Then Jim Shaeffer said:
> I submit that a team cannot complete the user requirements until the users
> have responded to a couple of iterations of functional software. What
users
> say when they encounter the software is very enlightening about what is
> really important to them.
>
>
> And what users say is equally enlightening when they see prototypes or
paper
> prototypes or mock-ups or any of the other things you can test against
> before you have functional software. To let your users be the beta
testers,
> I consider an insult to users. Why should I pay good money for software
for
> which nobody bothered to do adequate research and preliminary testing to
> know what I even needed?
>
> *****************
> And then Jim Shaeffer said:
> I have yet to see any combination of prose and pictures that conveyed the
> same user experience as actually interacting with the software. I now
> proceed on the assumption that creating such a combination of prose and
> pictures is impossible.
>
>
> It is absolutely possible, through field studies, paper prototyping,
> prototype testing, and a variety of other methods to know how users do
their
> work, what their task requirements are, and how they respond to
preliminary
> functional prototypes before throwing out all of the prototypes and
starting
> from a set of firm requirments, storyboards, and specs to create a final
> product.
>
> Of course there will have to be further user observations, testing, and
> feedback for the next version. The first version of any mission critical
> software changes how people work; the second version has to account for
> that. New technology also changes what it is possible to do, so a second
> version can account for that. Cost often means you have to create a
product
> in phases, so a second or third version is needed to read the final
> application as it was envisioned. And all along the way, you continue to
> analyze, observe, redesign, prototype, test, and gather feedback.
>
> I have worked on lots of products for lots of user types in lots of
> environments, and believe me, the products where development started
writing
> code they meant to ship before they had adequate requirements were all
over
> budget, over deadline, and a failure with the end users. And many of the
> projects I have worked on where they did a prototype turned into a fiasco
> because some senior manager liked the prototype so well they thought the
> whole app was finished and said to ship it! Prototypes are meant to be
> thrown out. They are not meant to become production code.
>
> The problem is very few development managers or senior managers want to
pay
> for the cost of doing it right the first time. They have a false notion
that
> they do not pay for it down the road. But, boy, do they. A project that
> slips two months or three months because they started without adequate
> planning costs more than if they had spent those two or three months
> planning before they started coding. It is much more costly to fix bugs or
> rewrite code than to conduct a field study of user tasks!
>
> Whew! I've got to take a deep breath. As you can tell, this is a subject
> that really jiggles my jello!
>
> Mary Deaton
> (206) 323-0701
> Used Tech Com Books For Sale at
>http://home.mindspring.com/~mmdeaton/books.html
>
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available 4/30/01 at http://www.devahelp.com or info -at- devahelp -dot- com
Sponsored by DigiPub Solutions Corp, producers of PDF 2001 Conference East,
June 4-6, Baltimore, MD. Now covering Acrobat 5. Early registration deadline
April 27. http://www.pdfconference.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.