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

[prady]

Anna wrote -

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

Anna,

Very nice question.

The school of thought I hail from is not bothered about selling it to
developers alone with the amount of detail they may seek. Because of the
reason that the immediate customer of the use case is 'not' those who code
the UI, but are those who are actually creating the Prototype, first. Please
read this - http://www.foruse.com/articles/structurestyle2.pdf

I am follower of 'Constantine & Lockwoods' theory of Essential Use Case.
They present the theory which says that this use case be written in context
(or in perspective) of how user is using it. This theory does bring
ideological conflict with that of 'Jacobson (of Rational Rose' Unified
Theory') but it does work in the iterative process which I described in the
last mail.

I consider the use of my use cases as purely for interpreting requirements
before starting on design. This is essential 'R' in 'R&D'. But that is not
saying that I have not faced the situation as you describing. In some
earlier instances, when I invited UI developers for use case creations, the
experience have been really unmanageable. For example, I can tell you an
instance - Developers wanted to create a use case for 'Login' mechanism and
they rightly justified so, that it is important to know the security
feature, validation rules, pre-conditions and post conditions to make it
work. From the user perspective, I did not consider it important (you may
guess why). Although the Use Case theory which I described above does not
say that developers' need can't be fulfilled using the same style and
structure. So, we arrived at set of use cases for design and let the output
be open for decomposing into 'concrete use cases' as we move with the
design. But essentially we agreed that decomposing the essential use cases
are responsibility of UI development lead. I do try helping the developers,
but avoid spoon feeding them. I also believe that when Developers work,
their point of reference could not just be contained to a single documents.
They refer to SRD, use cases, prototypes, database schema, etc. to proceed
on their tasks.

I just want to describe again, the context of my comments about 'use case
theory' in this mail and the one before. I see it as a part of a big
development process, which is iterative in nature. I believe that most of
the 'front loading' efforts set the path towards failure at the very
beginning. I have noticed if you are designing a system (which has less
industry parallels, and which is not same as, yet another 'Shopping Cart'),
you tend not to do everything in just one go. Neither you want all the team
to follow the same process/frame work.

At times, keeping front end design walks different path than those who code
it at the end, is right thing to do. It may meet multiple times in between,
for the sanity checks but following the common path is often chaotic than
useful. In my experience, the vested interests of Usability, Product
Management and Development are do different that it is not possible for all
of them to go together, all the time. There should be means for interactions
so to make the design and prototyping be usefully integrated but user needs
should not be over loaded with the developers need at the very beginning on
the investigation.

Hope I answered your query.

Pradyot Rai


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


> 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.
> > ------------
>
>