>Classic usability focuses on TASKS -- which is what you are doing with
>your list above. This is one of the hardest parts when building a site --
>IDing the tasks and then convincing management that a task-oriented focus
>will provide value to the end-user. And yes, every audience doesn't have
>the same task list -- that's where audience ID and priority needs to take
>place.
there's an interesting critter in the world of software design which seems
to be appropriate to this problem.. if nothing else, it provides a nice
conceptual handle for the process of task identification. it's called the
'use case'.
the basic idea is that a user goes to the system wanting something. if
the user doesn't want anything, there's no reason for them to interact with
the system at all. a use case is a specific instance of interaction
between the user and the system.
as a case in point, in the building where i used to work, there were two
vending machines side by side.. a Coke machine with a very finicky bill
scanner, and a food machine which would accept nearly anything you fed into
the slot. if i don't get regular Diet Coke fixes, people begin to wish
i'd never been born. when i'm hungry, i occasionally indulge a taste i
acquired in college for uncooked microwave burritos (rule 1 of food among
students.. if you don't want people mooching 2/3 of what you've just
bought, learn to eat something that makes everyone else hurl. IMHO that
principle is the basis for things like lutefisk and kimchee), so i spent a
lot of time dealing with these two machines.
the simplest use case for either machine is the vending of a product..
"getting a Diet Coke" and "getting a frozen burrito", respectively. both
those use cases break down into smaller components, like feeding money into
the machine, checking the display to see that the machine has registered
enough credit to vend the product, identifying my selection, and releasing
the product. each of those items can be further refined into sub-steps,
and the process continues until you have an engineering spec for the
electrical signals and componenets. from my perspective as a user,
though, the criterion for success or failure of the machine is whether i
get my Coke fix.
the simple fact that a system did what it was supposed to doesn't mean it
met the user's expectations for the use case. a specific example of a
failed interaction where the machine behaves perfectly is when all the Diet
Coke slots are sold out. the machine has performed every operation in its
spec according to the design, but i still haven't gotten what i wanted.
the subtlety of the slot-searching subsytem couldn't matter less to me,
because a cardboard box that actually contains a can of the precious liquid
would do a better job of meeting my requirements.
another common scenario when i dealt with the machines was that the Coke
machine would refuse to accept any bill from my wallet. in that case, i'd
run a bill into the ood machine, hit the change button for quarters, and
feed those into the Coke machine. if you break down the operations in
that sequence, most of them are the same as for a purchase from a single
machine, but the responsibility for various operations has been split
between two different physical systems. it all still fits under the
heading of "getting a Coke", though. in this situation, though, there's a
plausible use case for the food machine of "getting change for a dollar".
the good thing about use cases is that they codify the interaction between
the user and the system without putting constraints on the way that
interaction will be implemented. they're also very closely tied to what
the user wants as output from the system, which is how people tend to think
about their interactions with machines.
if you can get people to tell you what they want out of a system, it keeps
them from over-specifying the implementation, which is an all too common
habit. instead of saying "we want to handle a financial transaction",
people will tell you they want this secure server providing a front-end to
that database, with formatting for back-end processing package X. those
/may/ all turn out to be valid requirements for the final product, but then
again they may not. in the meantime, no mention has been made at all
about getting products and price information into the database in the first
place. implementation-specific specs tend to be wildly innacurate and
riddled with holes. worse yet, they offer no way to identify the
innacuracies or locate the holes. avoid them like the plague.
use cases, OTOH, by virtue of being implementation independent, give you an
overall compass bearing which tells you whether a specific implementation
will do the job or not. the process of breaking use cases down into
smaller sub-cases, which still remain implementation independent, is called
the functional decomposition of the system. keep it up long enough, and
eventually you'll have pieces which are small enough that implementing them
is a no-brainer. better still, you'll have a heirarchy of requirements
which allows you to flex the details of implementation at any point in the
system, then go back and see whether the system still works the way it's
supposed to.
mike stone <[EMAIL PROTECTED]> 'net geek..
been there, done that, have network, will travel.
____________________________________________________________________
--------------------------------------------------------------------
Join The NEW Web Consultants Association FORUMS and CHAT:
Register Today at: http://just4u.com/forums/
Web Consultants Web Site : http://just4u.com/webconsultants
Give the Gift of Life This Year...
Just4U Stop Smoking Support forum - helping smokers for
over three years-tell a friend: http://just4u.com/forums/
To get 500 Banner Ads for FREE
go to http://www.linkbuddies.com/start.go?id=111261
---------------------------------------------------------------------
