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

[prady]

Hi there,

I am impressed by the excellent postmortem (pun intended) of my previous
remarks. Just want to reiterate few things again here.

The opinion I expressed before is infact in sync with the that of others
that use cases are good for feature/functionality design and documentation.
Just to add to it I want to say that it is also a good means for starting
the 'Task Analysis' (or else correct me on my definition of task analysis).
Most of the requirements, when they come from the Product Management are
vague enough that jumping oven to pen-paper to create interface could be
disastrous. At the top level, it is very good practice to elaborate all such
requirements in terms of use cases.

I won't go in the issues of 'roles' vs. 'tasks' as I am little unsure of
those two, but I agree that use cases are not means for justifying usability
of the end product. But in my little experience, I have seen them as a good
means which are being followed by the whole team - UI group, Data Server
guys and QA for the implementation/review of the design.

If you guys are interested, 'Usage Centered Design' by 'Lockwood and
Constantine' is real good book to follow the whole issue. But just beware of
one fact about them - if you are coming from the use case theory of
Jacobson's Rational Unified Process, you will have to go there with real
open mind to understand the issue. Having said that, I can assure you the
book will surely make your opinion richer.

Regards,

Pradyot Rai

----- Original Message -----
From: "Laura Scheirer Quinn" <Laura.Quinn at IntraSphere.com>
To: <sigia-l at asis.org>
Sent: Monday, January 06, 2003 10:37 AM
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