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.


Previous by Author: Re: Context Sensitive (CS) Help in Web Applications
Next by Author: Re: Whaddaya know? (long)
Previous by Thread: RE: Having Your Style Guide and Eating Your Fries Too
Next by Thread: Re: Having Your Style Guide and Eating Your Fries Too


What this post helpful? Share it with friends and colleagues:


Sponsored Ads