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

[Anne Hjortshoj]

Did you find that developers pressed for much more detail in the use cases
than you originally thought was necessary (both of you)?

One of the problems I've had is that developers want to see a lot of
detailed information in the use cases, detail such as precise form field
validation rules and business rules. Some of them even want to be able to
begin coding directly from the use cases, especially where use cases have
traditionally been more of a catchall business requirements doc. It's
difficult to convince them that use cases shouldn't be a huge document, and
that some things are better presented graphically than verbally. (Imagine a
form in Visio; now imagine describing the form verbally in a Word doc. This
is what I'm talking about.)

What have your experiences been? How did you sell developers on UI-agnostic
use cases (and by extension, IA-style graphical representations of the UI)?

-Anne

----- Original Message -----
From: "prady" <prai at prady.com>
To: <sigia-l at asis.org>; "Doug Howell (IT)" <DHOWELL at bordersgroupinc.com>
Sent: Wednesday, January 22, 2003 10:46 AM
Subject: Re: [Sigia-l] RE: Use cases and user centric design (was sitepath
diagramming)


> Doug Howell wrote -
> "we kept sabotaging ourselves because we couldn't grasp the iterative
nature
> of the development process"
>
> I agree with most of your experinces. Looks like you work in my office,
too
> :)
>
> Here is what I have to add to this -
>
> Use cases are not the final frontier, they are just a bit to perform the
> 'Task Analysis'. They help understanding what is required and how you
'may'
> plan doing it. But as you said, they don't (and should not) have anything
to
> do with the user interface. Hence, usability can't be guarenteed with the
> use of 'use cases', yet they are better means to be used effectively for
> 'feature inspection' after the development (better than SRD, offcourse).
>
> We have also progress from 'Use Cases' to the 'Work Flow' to complement
the
> development process. But in my opinion, it is not to say that 'use cases'
> were not needed. I feel that workflow, in fact, is very high level use
case.
> In our development, we at times skip writing use cases primarily for the
> time constraints. But we complement this by investing more time on the
> 'storyboarding' and 'wireframes' stages during design.
>
> My experience with the 'iterative' nature of development is that each
stage
> is an important 'investment'. You eaither pay on time or pay late (with
the
> late fee), but you can't avoid it.
>
> Pradyot Rai
>
> ----- Original Message -----
> From: "Doug Howell (IT)" <DHOWELL at bordersgroupinc.com>
> To: <sigia-l at asis.org>
> Sent: Tuesday, January 21, 2003 6:10 PM
> Subject: [Sigia-l] RE: Use cases and user centric design (was sitepath
> diagramming)
>
>
> Katherine  Marshak wrote:
>
> 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.
>
>
> The use case discussion hit home for me. We are still trying to find the
> most helpful combination of deliverables. We started our foray into
> object-oriented programming by creating use cases. We created what we
> thought was a very good template, combining some of the best ideas from
> several printed sources, consultants and experience. However, we kept
> sabotaging ourselves because we couldn't grasp the iterative nature of the
> development process. We were trying to use object-oriented techniques
inside
> a traditional, "waterfall" mindset. We ended up in "analysis paralysis"
> because we were trying to create _perfect_ use cases. People were spending
> way too much time trying to perfect the language, trying to make sure it
> covered every possible scenario, and having a very difficult time figuring
> out how to document alternate and exception flows.
>
> What we're trying now is replacing the main, alternate and exception flow
> narratives with flow charts (Visio) which we call business activity
> workflows. The developers seem to get more out of them, and the business
> people don't have to worry so much about language (except learning a few
> symbols). These diagrams then become the basis of screen flows.
>
> Thanks,
> Doug Howell
> Information Architect
> Borders Group Inc.
> ------------