Use Case v/s IA Document

Prachi,

The short answer is that you can't cleanly slice the requirements, and I'd
put forward a strong argument against hard demarcation. The use cases put
out by the BA need to be informed by the user perspective brought to the
table by the IA. Similarly, field level validations - in fact all exception
conditions - are most likely to be known by the BA, but are best
communicated via the wireframes.

I would suggest you keep both BA & IA working on both sets of deliverables
until both are finished. Make it a joint effort, and make it clear that the
quality of both is a) equally important; and b) joint responsibility. In
fact, I'd suggest getting others involved in the process as well.

Best Regards,

Steve Baty

On 17/06/07, Prachi Sakhardande <prachisakhardande at gmail.com> wrote:
>
> This has been a grey area of sorts, with the BA and IA literally coming to
> blows at times about who should be doing what...Since a lot of people have
> only seen a usecase document as the end product of the requirements phase,
> the IA is considered a support function of a BA, someone who converts
> usecases to wireframes hust so that its easier to visualize.
>
> Does the industry work this way? How do you cleanly slice the requirements
> phase between the BA and the IA, so that they dont end up stepping on each
> other's toes?
>

--
----------------------------------------------
Steve 'Doc' Baty B.Sc (Maths), M.EC, MBA
Director, User Experience Strategy
Red Square
P: +612 8289 4930
M: +61 417 061 292

Member, UPA - www.upassoc.org
Member, IxDA - www.ixda.org
Member, Web Standards Group - www.webstandardsgroup.org

Prachi,

I am the sole interaction designer at my computer along with 8 Bas. Our
company just adopted the use methodology.

What I think you need to convince them of is that you have a different
point of view that they have. BAs have the Business point of view when
making use cases. By business I mean they try to streamline the process
by eliminating duplicate work, paper, delays, ... They really think
about cutting costs. This is very good but cutting costs is a business
goal, not a user goal. They need to be shown that what you do is
different. The use case document is just a repository of everything
that was collected/produced during the requirements phase.

At my company I had the chance of being hired before most of the BAs and
I had the time to create personas and a conceptual design so I had
concrete stuff to bring to the table that was also validated by the COO
and every vps. In the end what ended up happening is that the
user-centered view I brought helped me negotiate changes in the business
process they were mapping. In my experience, BAs are a bit lke
programmer in that they are very logical, they will accept a clear/logic
argument.

In terms of the storyboard section we have in the use case, the BA needs
to specify the fields that need to appear on each page. I am in the
process of convincing them that they show only list the fields required
but to realize that I might add some and also that I am the one who
should decide which fields go on which screens (the flow).

I think the classic triangle of good products with the User, Business
and Technology is a good way to introduce the user-centered perspective.
It is also important that you bring them user needs based on your
research to show them that they could not have discovered those needs by
mapping the business process. This is something that a lot of BAs think
they cover 100% but they just don't. They need to be shown what they
leave out.

In the end, the use case document should combine flavors of the 3
perspectives in every section of the document.

Good luck

Pierre Roberge
Business Analyst / User Experience Designer
Etfsinc.com

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
Prachi Sakhardande
Sent: Sunday, June 17, 2007 2:50 AM
To: discuss at ixda.org
Subject: [IxDA Discuss] Use Case v/s IA Document

Hi All,

I work as an information architect for a company that provides software
services, one of our key areas being our user experience practice.
Typically, a business anaylst and an information architect are allocated
in the requirements phase. Both attend the same business meetings, talk
to the same people, including both, clients and end users.
At the end of the requirements phase, the BA has to come up with the
usecase document and the IA with the IA document. For most people who
come from the conventional IT background, the IA document is
'wireframes', which can be conveniently merged into the usecase document
as screenshots at the appropriate places!
However, to me, and IA document, must also capture all aspects of
communication with the end user - field level validations , error
messages, field label descriptions, to name a few.

This has been a grey area of sorts, with the BA and IA literally coming
to blows at times about who should be doing what...Since a lot of people
have only seen a usecase document as the end product of the requirements
phase, the IA is considered a support function of a BA, someone who
converts usecases to wireframes hust so that its easier to visualize.

Does the industry work this way? How do you cleanly slice the
requirements phase between the BA and the IA, so that they dont end up
stepping on each other's toes?

--
cheers,
Prachi
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org List Guidelines
............ http://listguide.ixda.org/ List Help ..................
http://listhelp.ixda.org/ (Un)Subscription Options ...
http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org Home .......................
http://ixda.org/ Resource Library ........... http://resources.ixda.org

----------
etfs inc. The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential and/or
privileged material. Any review, retransmission, dissemination or other
use of, or taking of any action in reliance upon this information by
persons or entities other than the intended recipient, is prohibited. If
you have received this in error, please contact the sender and delete
the material from any computer. Unless otherwise stated, opinions
expressed in this e-mail are those of the author and are not endorsed
by the author's employer.

etfs inc. L'information transmise ne s'adresse qu'au particulier ou a
l'organisme a qui il est dirige. Il peut contenir des renseignements de
nature privilegiee et/ou confidentielle . Si le lecteur de ce message
n'est pas le destinataire vise, ni l'employe ou le mandataire charge de
la livraison au destinataire vise, il est par la presente avise que
toute dissemination, distribution ou transcription de cette
communication est strictement interdite. Si vous avez recu la presente
communication par erreur, veuillez nous en aviser immediatement par
courriel et detruire le document de tout ordinateur le contenant. A
moins d'avis contraire, toute opinion exprimee dans le present courriel
est celle de son auteur et n'est pas endossee par l'employeur de la
personne qui l'exprime.

This topic brings up some questions for me as well. What if you don't have
the traditional BA role at your company - and nobody is providing use cases?
Business requirements may come down from any number of people, including
marketing folks - and they may be communicated verbally, via e-mail or
roughly formatted Word docs.

This gets transferred to me by my boss when the project starts. So one
question is, how important is it to really build a use case? I'm going to
distill the business information into my wireframes as it is - do I really
need a second document for it? (Particularly when we work under tight
deadlines). I would rather spend my limited time and resources on design
instead of dealing with documentation on business rules.

I realize the rules are important and must be considered, certainly. I guess
I'm just wondering how important it is to have that extra (or one larger,
bloated) document when you could just as easily make sure the business rules
are followed in the design documents.

Certainly the culture at the place of business is a consideration. In my
case, we are kind of trying to instill user-centered design into the
development process, and our resources are somewhat limited (more by time
than anything else.)

Coming from a large corporate environment, where all the standard waterfall
documentation is required (in order):

1.) Business Case
2.) Business Requirements
3.) Functional Spec
4.) Technical Design

We've recently started using a Screen Requirements document as the main tool
to communicate between the business folks, the design team, and the
developers. It is typically owned by the project manager who works with the
BA & Designer to produce it. Once all three have signed off, it is
considered to be the main development document.

The basic idea is that the design team creates the prototypes and we place
them in this screen requirements doc. It is sort of a storyboard approach
that has details for all the interactions. It is sort of a combination of
the Screen Shots and Use Cases from the Functional Spec. Also, we use it as
a checklist before implementation (not a full test plan, but rather a way to
ensure that the finished product matches what was designed).

The level of detail varies in this doc, however, we have been putting a good
amount of information in it (as needed). The basic layout is simple:

[SCREEN SHOT]

- explanation
- explanation
- etc.

[SCREEN SHOT]

- explanation
- explanation
- etc.

The project manager and BA still have to produce those other documents, as
part of our corporate methodology, but now our management team allows us to
shelve those as soon as they're completed and focus on this single document.
Some of the other cool parts of this are that we now are using this
document, as opposed to the old days when it was rare that you would ever
see anyone walk into a meeting with a copy of the functional spec (after it
was approved). Also, it helps with scope, because if anyone wants to change
something we have a common place to mark the changes (who requested it, who
approved it, etc). The document is version controlled as well. I'm not
saying this is perfect, but it has worked well for us.

Hope this is helpful.

Jon

On 6/17/07, Prachi Sakhardande <prachisakhardande at gmail.com> wrote:
>
> Hi All,
>
> I work as an information architect for a company that provides software
> services, one of our key areas being our user experience practice.
> Typically, a business anaylst and an information architect are allocated
> in
> the requirements phase. Both attend the same business meetings, talk to
> the
> same people, including both, clients and end users.
> At the end of the requirements phase, the BA has to come up with the
> usecase
> document and the IA with the IA document. For most people who come from
> the
> conventional IT background, the IA document is 'wireframes', which can be
> conveniently merged into the usecase document as screenshots at the
> appropriate places!
> However, to me, and IA document, must also capture all aspects of
> communication with the end user - field level validations , error
> messages,
> field label descriptions, to name a few.
>
> This has been a grey area of sorts, with the BA and IA literally coming to
> blows at times about who should be doing what...Since a lot of people have
> only seen a usecase document as the end product of the requirements phase,
> the IA is considered a support function of a BA, someone who converts
> usecases to wireframes hust so that its easier to visualize.
>
> Does the industry work this way? How do you cleanly slice the requirements
> phase between the BA and the IA, so that they dont end up stepping on each
> other's toes?
>
>
> --
> cheers,
> Prachi
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

On 6/19/07, Jon Strande <jstrande at gmail.com> wrote:
>
> Coming from a large corporate environment, where all the standard
> waterfall
> documentation is required (in order): [snip]
>
> The level of detail varies in this doc, however, we have been putting a
> good
> amount of information in it (as needed). The basic layout is simple:
>
> [SCREEN SHOT]
>
> - explanation
> - explanation
> - etc. [snip]

That is exactly where I just came from, large corporation doing about the
exact same thing. Our problem was the functional spec was *never* finished -
it was always in flux. So the developers worked with a mutating document and
it frustrated them. Also, as I said in my last post, they were massive
documents that required a lot of work. The PM owned it, I made the screens
and supplied them.

Because of that document, my wireframes never got into low level detail and
if the functional didn't cover that things got lost. And we rarely had use
cases there (unless an internal client wrote one). Biz requirements were
handed down.

Anyway, don't want to spin our wheels here (or hijack the thread, which I
think I did). I'm just looking for a better case scenario where
documentation doesn't become a burden to the project, but a benefit.

Tom

On 6/20/07, Adrian Howard <adrianh at quietstars.com> wrote:

> On 19 Jun 2007, at 14:16, Tom Dell'Aringa wrote:
> > questions). I don't know what type of development process they have
> > been following, whether it be waterfall, agile or some other (I'm fairly
> > sure it isn't agile) but I am trying to find out.
>
> Yup - but the kind of approach can make a huge difference. For
> example, you may find developers who are rewarded for "meeting the
> spec" when the spec consists solely of "technical" tasks (add the Foo
> object with these fields to the Fribble database layer). It can be
> very hard to shim UCD processes into a system like this since the
> process completely divorces the developers from their impact on the
> users. In fact they'll get "punished" for moving off spec even when
> this helps the user.
>
> In contrast if the developers are following something like XP well
> then they'll _always_ be working on user level tasks - or at least
> bits of functionality of direct business value. These environments
> are much easier to work with.
>
> If you're faced with something like the former then (in my opinion
> anyway :-) it would be better to fix the development process first.

Turns out they are using the Microsoft Solutions Framework (MSF). My boss
stated that it is a guide and they are flexible with it. It's a pretty basic
framework with a Planning, Development and Stabilizing phase with peer code
reviews and a final user acceptance by the business owners. So basically
there is no "design" phase per se. The first project task in planning is
functional spec, so I assume that is where I would begin to inject ourselves
:).

The interesting thing is that this framework is only used for "software
development." If we are redesigning a marketing site (which we will be doing
a *lot* of) then it's up to us to use whatever process we want. So I want to
put something together that works for both scenarios.

Tom