More Use Case Debate
Follow up to Feb 99 and Oct 99 editorials

Hi, David.

I've shared your concerns about use cases vs. good UI design, and especially confusion of business analysis with interaction design. So I thought I'd share with you a new thought that is a lot more optimistic about use cases.

Perhaps, because use cases are so easy to write, they are a much better fit with most developers than are methods that produce much better results but that most people can't apply well.

So in other words, this is a hypothesis along the lines of, "Microsoft makes the best software, not because their software is better than others, but because they've found an optimum between bugginess/clumsiness and market demands." If people are making better software thanks to use cases, then despite the flaws, this is an improvement. Yeah, their UIs are somewhat mediocre, but excellence is only possible for the extremely talented and dedicated anyway.

What do you think? Or maybe you could address this in a third article about use cases

BTW, here is the original thought that led me to this idea: use cases are here to stay no matter what we say or do. In arguing against them, don't you have that feeling of pushing a big rock uphill? I sure do. Generally when a convention evolves and settles in, that means that it strikes some sort of optimal trade-off--a trade-off often beyond the comprehension of the people who follow the convention, but one that they still benefit from.

Regards,
Ben Kovitz

Ben,

I agree that Use Cases are here to stay so we have to make the best of them. That is precisely why uidesign.net continues to advocate Essential Use Cases over any other style or method. As it is the only style or method of writing Use Cases which addresses the UI issues which you and I have both voiced to often.

David Anderson
Editor

Dear uidesign,

I would like to comment on your article "Are Use Cases the death of good UI Design?"

I think the main flaw in your argument centres around what a good use case is. You suggest it takes the form: - ... a Use Case takes the form of a narrative which reads: the user does this; the system does that; the user does something else; the system does the next thing. However I believe a use case is an evolving process.

A business analyst will come up with a list of use cases. Eg: 1. The user needs to be recognised by the system 2. The user needs to be able to browse catalogue items 3. the user needs to be able to search for a particular catalogue item by either name or ref number. This details of each use cases may then be refined by other members of the development team: 1. The user will be recognised by cookie and/or login 2. there will be a shop section that has a virtual reality room in which the user can click on any catalogue item for more details... etc..

I think use cases are very useful if used appropriately. They focus peoples attentions on 'WHAT' someone needs to do, rather than 'HOW' they will do it. The alternative to use cases is when the business analyst etc propose a site architecture and site flow - surely far more detrimental as they are already trying to come up with solutions at the same time as identifying a requirement.

Of course some people will use the technique badly - but then what's new?

Regards Briony

uidesign reply:

Briony,

An interesting note which requires a careful reply. Firstly, you comment on an editorial from February 1999 which was written perhaps 6 weeks earlier. At this time, Rational Corporation was in the process of publishing three books by Booch, Jacobson and Rumbaugh and promoting the notion that Rational Unified Process, by that time subtely remaned as Unified Development Process, should be widely adopted as the de facto standard process and methodology for object oriented software development.

uidesign.net considered this trend to be a serious problem for the future of good user interface design and software usability. The reason for this was simple. UI Design had never been considered by Rational and the 3 amigos as important enough to warrant much coverage. Rational Unified Process really had no way of addressing UI Design and had for the most part ignored it. The Feb 99 editorial refers to the Jacobson style of Use Case writing as described in the book, "The Unified Development Process", Jacobson et al.

You describe a method for working with Use Cases which has provided you with useful results. This I believe actually emphasizes the points made in the Feb 99 editorial. One of the big problems with Use Cases has been the lack of agreement on how they should be written. At least 7 styles exist. This was very adequately documented by Larry Constantine in his recent paper [Download the pdf (380K)].

uidesign.net continues to be concerned that Use Cases are poorly defined and continue to be used without any agreed standardization of style and purpose. The problem with this is primarily that it means Use Cases are not easily repeatable across the software development community. The same problems are not seen with UML Class Diagrams for example. The style, structure, purpose and usage of Class Diagrams is well understood and is highly repeatable across a large section of the development community. Until Use Cases can show this consistency uidesign.net will remain skeptical.

Meanwhile, uidesign.net continues to promote only one style and purpose for Use Cases. That is Essential Use Cases as described and detailed by Larry Constantine and Lucy Lockwood in their recent book, "Software for Use" [ Order from Amazon ] and at their website, foruse.com .

Regards,

uidesign.net