[Sigia-l] Use cases and user centric design (was sitepath diagramming)

[Katherine Marshak]

My company has also struggled with the relationship between use cases,
user-centered design, and IA-driven approaches. I've used use cases
since the mid-90s and know their strengths & weaknesses very well.
Anytime you bring together people from different disciplines together to
solve a single problem you get great ideas but also competing
perspectives. We've found a way to balance these different perspectives.


Briefly, we use a variety of requirements elicitation & user research
techniques to inform the development of both a use case model and a site
map early in the project. We often develop personas to supplement actor
descriptions. (Actors are part of the use case approach. Actors
represent the roles that people & systems play in relation to the
application/site being developed.) We complement the use case model and
specifications with wireframes and navigation diagrams. We strive to
keep user interface details out of the use cases so they focus on
functionality. This gives us flexibility to improve the interface and
interaction design without changing the underlying requirements. 

Details are at http://www.iconprocess.com/iconProcess/ueWorkflow.php. 

I also wrote a white paper explaining the common ways people misuse use
cases. The paper is available from the home page: www.iconprocess.com.

best regards,
Kathy Marshak, senior consultant
IconMedialab | www.iconmedialab.com 
IconProcess | www.iconprocess.com  
Training | www.training.iconmedialab.com 
voice: + 1 636 530 7776




-----Original Message-----
From: Laura Scheirer Quinn [mailto:Laura.Quinn at IntraSphere.com] 
Sent: Monday, January 06, 2003 9:38 AM
To: sigia-l at asis.org
Subject: RE: [Sigia-l] Use cases and user centric design (was sitepath
diagramming)


Prady wrote:
> I am
>inspired by the Use Case theory of 'Larry L. Constantine, Lucy 
>Lockwood' and there's a good paper by them called - 'Structure and 
>Style in Use Cases for User Interface Design'. Find it at - 
>http://www.foruse.com/articles/structurestyle2.htm

I've been spending a lot of time recently, in a fairly traditional
technology consulting firm, struggling to build a process that uses both
user-centric design techniques and use cases (as if we have to chose
one, it's not likely to be the use cases that goes away).  I have to
admit that even after reading about and using use cases (almost entirely
in a Rational Rose and UML context) for a number of years, I wasn't
aware that Constantine and Lockwood's work was out there framing use
cases in a more user-centered way than other works.  This is a great
article, Prady, thank you. 

Though that certainly says something about how use cases are being used
much of the time out in the world.

Prady, you also seem to find use cases very useful in requirements
definition.  
> At the end I would also say, if you have ever suffered (or suffering) 
>by the politics of Requirements Vs. Technical Design (or Product 
>Management Vs Engineering), use cases are the best to make things black

>and white during the Requirement or Task analysis Phase.

I find use cases invaluable as a functionality documentation method.
However, although I know that they're frequently used specifically to
define requirements, I see several drawbacks when trying to use them to
define a system in a user centered way.   

The biggest is use case's undeniable focus on users in system-centric
roles.  Even if you call them "roles" rather than "actors", it's very
difficult to try to frame your "roles" to be anything else than people
who perform significantly different system functions, and/or have
different levels of system security.  While this is of course necessary
to system design, I find it counter to a user-centered definition of a
product.  At the very beginning of a project, you want to think through
user groups based on actual user needs.  As you gather data (or at least
do a conceptual exercise), it may turn out that there's no difference in
the features needed to support a novice desk clerk and a experienced
desk clerk, and they may be the same system actor-- but I wouldn't want
to assume this going in. Use case methodology encourages you to guess
what your system roles-- and often even your feature set-- should be
without thinking through the user needs.

Secondly, use cases are difficult to use to solidify an overall concept
of what you're building.  Although they can effectively document what's
been arrived at, I feel strongly that those that are using them as a
tool to identify, iterate, and work through features and requirements
are asking for trouble.  They're simply too hard to read and to process
as a whole by anyone except those hired (like us!) to be able to
visualize systems from diagrams.  While tech savvy clients and users
will review them, have comments on them, etc., you get the same kind of
effect that user-centered design tries to avoid, where people will
"change their mind" and turn out to have forgotten critical aspects and
generally show signs downstream of not having really conceptualized what
they were asked to sign off. This effect is more pronounced the less
tech savvy your client and user base is.

Where I've gotten to with a lot of thought about this for my company is
to use use cases as a documentation technique, and to use other user
centered techniques (probably in our case user profiles, task analysis,
and a conceptualization step through prototyping, diagramming or the
like) to actually define requirements.

Laura S. Quinn
------------
When replying, please *trim your post* as much as possible. *Plain text,
please; NO Attachments

ASIST SIG IA website: http://www.asis.org/SIG/SIGIA/index.html
Searchable list archive:   http://www.info-arch.org/lists/sigia-l/
________________________________________
Sigia-l mailing list -- post to: Sigia-l at asis.org
Changes to subscription: http://mail.asis.org/mailman/listinfo/sigia-l