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

[Lorelei Brown]

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

I used to think that this was the case, but then I
left strictly-defined role in a process-driven agency
life and worked for a very small business, and my role
went from being an IA/UI designer to being an
IA/requirements writers. I think that iteration and
process are everything.

I've found that developers who aren't used to working
with IAs get impatient initially, but accept it once
they see that the time investment will result in
better requirements and less changes at the end of the
process. Frankly, given some of the poor project
management, 11th hour changes, and other mitigating
factors we all have to work with, I don't blame them.
It's as important for you to understand them as it is
for them to accept you.

Short version:
I think selling the whole IA process as part of
requirements gathering is the best tactic. It makes it
more palatable, and it's true - it's taking the needs
and methods of the end user, and representing them
graphically. It's developers' job to make them into
some sort of application.

Longer, picky version:
First, use case means something different to
developers - in software development, it's this
incredibly detailed document with data fields, error
messaging, and other application behaviors. So, we're
talking about different things, which get at the same
purpose. I've tried selling it as a 'first draft' of
their version of use case. There are other terms that
overlap, so make sure that the expectations are the
same.

Second, while certain things may convey better
graphically, we still have to help the developers
convey them into code. That may mean drawing every
single error message, or making a second version of
your wireframes with the friendly form labels stripped
out, and the database field names put in. 

Third, requirements are another kind of narrative,
which is also the task of the IA. Try sitting with the
person who writes requirements, and understand how
they take your documents and convey them into their
list of instructions for developers. Some
developers/requirements writers I've worked with have
found it helpful to have a written narrative of the
wireframes (pretend you're giving a presentation), or
having a kind of key that matches your graphic
representation to the requirement number (this takes
great fortitude, but will guarantee that your ideas
are correctly executed). Or better yet, try to write
requirements from your own wireframes. 

Finally, see yourself as a diplomat. You are there to
be the user advocate in the application process. You
are also have to respect the project - there are some
things that you just can't do, for one reason or
another (be it the technology, the scope, the time,
whatever). 

I think that developers are asked to do the impossible
in the shortest period of time with the least
consideration. I've gotten the furthest with the
approach of 'I want to do this because it is the
method of doing more extensive discovery, and will
make your life easier', than 'It's the right way to do
it, and I'm from the school of IA.'

Just my opinion. Your mileage may vary.

Lorelei

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com