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

[Laura Scheirer Quinn]

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