Subject: RE: How to?



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