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

[Anne Hjortshoj]

> Those developers who are much involved in design as well as coding should
be
> able to make good use of a use cases document, as part of the process of
> producing the sort of thing coders want, but that is not all of us (and
with
> many of us it's a matter of where our interests have lead us rather than
> what our job description says we should do
>
> Not only is a use case document not much use to a hacker, but they are
often
> familiar with seeing rather dubious "consultants" producing thin documents
> that are equally of no immediate value (the difference is that they are of
> no long-term value either), and hence will be immediately suspicious of
> anything that is light on what they consider to be the specifics

Yes. You've hit the disconnect right on the head.

The problem I've had is convincing developers that a use case document
should be a light document that isn't necessarily something they can code
from. Once they've been through wireframe construction a few times, they
tend to get it. I think wireframes make a lot of developers uncomfortable,
since it seems like it's too far into the process to be coming up with field
validation (but isn't if the use cases are light - the screen design happens
much earlier in that case).

One of the things that I -have- had success with is appending bullet lists
of pertinent info to each use case. So that if a developer does come up with
an important validation or business rule, it can be documented and not lost.

I also tend to format my use cases as description/precondition/use case/post
condition/notes, which developers like.

In my experience, the few cases where developers haven't gotten it, it's
been a function of the company having almost no design process in the first
place. So the developers tend to cling to a big fat use case document as the
only documentation they'll ever see, and distrust iterative design
processes.

-Anne