Use Cases and Personas

7 Oct 2004 - 5:01am
9 years ago
58 replies
3281 reads
Narey, Kevin
2004

Hi,

I'm interested to see what proportion of the community write use-cases as
part of their IxD involvement on a large development project?
My current interest is in how use-cases interface with personas. Or perhaps
how personas can improve/complement our use-case content.

In my company, the developers are given user profiles (akin to personas I
guess but without the accompanying photo), use cases and a hi-fi prototype
(used as a requirements source). This is clearly not enough as the user very
rarely gets to actually use the application in the design phase and the end
product goes out previously un-used - a common problem I believe, but one
that can be addressed. I like the concept of personas and will shortly
introduce them to our processes, however, I expect a certain amount of
resistance from developers if the introduction of personas doesn't
categorically improve the quality of the use-cases. Do they in your
experience?

My use of personas in the past has been on smaller, more marketing focussed
projects, where use-cases were not employed as a default development tool
and were therefore optional.

With eager anticipation!

Rgds

Kevin

**********************************************************************
gedas united kingdom limited
Registered in England no. 1371338

This email and any files transmitted with it are confidential
and it may be privileged.

It is intended solely for the use of the individual or entity to
whom it is addressed.

If you have received this in error, please contact the sender
and delete the material immediately.
**********************************************************************

Comments

9 Nov 2004 - 4:38am
Listera
2004

Narey, Kevin:

> I've recently made design a palpable business proposition here, not only by
> convincing developers that the way they did things as a team was flawed, but
> that my company and clients were losing significant ROI.

Excellent.

> A prototype,

Always.

> a rigorous and informative demonstration to the coders

Page by page, widget by widget, step by step.

> and...........obviously something tangible to close the gap on interpretation
> and dare I venture to cover yourself from blame.

Change the rules! Give a "rigorous and informative demonstration" for as
long as it takes and *let them take their own notes* in their own way, at
their own pace. Show, explain, answer, but make sure they understand it's
their responsibility to question, absorb and implement. Blame is for them,
for not asking the right questions.

Ziya
Nullius in Verba

9 Nov 2004 - 8:01am
Peter Boersma
2003

Kevin wrote:
> I still don't have a clear picture of what project deliverables you (or
> anyone else for that matter) hand over to the coding team.

Instead of a prototype(*) we, the information architects/interaction
designers/visual designers of EzGov deliver:
- screenflow (paths from screen to screen with conditions)
- wireframes (what's on each screen, and what's important)
- mockups (what's on each pixel, and how do things look)
- styleguide (navigation rules, interaction design standards, visual design
rules)
and we review these as a team, with the developers. These artefacts are
available for developers to use as reference.

Furthermore, our business analysts deliver, with whom we work together to
analyze the requirements, deliver use cases with associated:
- business rules (when is what field required)
- validation rules (what is a valid value in each case)
- error messages/rules (what if something goes wrong)
- exceptions (what if this is the last element deleted, etc.)
in the shape of developer reports that are extracted from our requirements
database.

After the delivery of drafts, reviewed versions and signed-off versions, we
keep reviewing the status of teh project, and the developers' deliverables
as part of our QA efforts.

(*) We combine the screenflow, wireframes and mockups into one deliverable,
our J-Flow.

Peter
--
Peter Boersma - Senior Information Architect - EzGov
Rijnsburgstraat 11 - 1059AT Amsterdam - The Netherlands
t: +31(0)20 7133881 - f: +31(0)20 7133799 - m: +31(0)6 15072747
mailto:peter.boersma at ezgov.com - http://www.ezgov.com

> -----Original Message-----
> From:
> discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
> [mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
> ers.com]On Behalf Of Narey, Kevin
> Sent: 09 November 2004 10:18
> To: 'Listera'; Interaction Designers
> Subject: RE: [ID Discuss] Use Cases and Personas
>
>
> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
>
> Ziya
> >Don't let the developers dictate your UI. :-)
>
> I apologise for my lack of clarity (a bout of emailitis), but I
> think you've
> misconstrued my current position. I haven't got where I am now by being
> dictated to. I've recently made design a palpable business
> proposition here,
> not only by convincing developers that the way they did things as
> a team was
> flawed, but that my company and clients were losing significant
> ROI. Keeping
> good relationships with all stakeholders in the software development
> process, makes change for them, much more of a feasible proposition for me
> to execute.
>
> I still don't have a clear picture of what project deliverables you (or
> anyone else for that matter) hand over to the coding team. A prototype, a
> rigorous and informative demonstration to the coders
> and...........obviously
> something tangible to close the gap on interpretation and dare I
> venture to
> cover yourself from blame. Multi-feature systems (yes I know -
> not ideal) do
> make for very complex prototypes if you are to cover as many scenarios as
> you can, but there either needs to be a trust angle with developers or the
> designing out of misinterpretation - funnily enough that's where
> developers
> tend to attempt to dictate my UI's :)
>
> Kevin
>
>
>
> **********************************************************************
> gedas united kingdom limited
> Registered in England no. 1371338
>
> This email and any files transmitted with it are confidential
> and it may be privileged.
>
> It is intended solely for the use of the individual or entity to
> whom it is addressed.
>
> If you have received this in error, please contact the sender
> and delete the material immediately.
> **********************************************************************
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at ixdg.org
> --
> to change your options (unsubscribe or set digest):
http://discuss.ixdg.org/
--
Questions: lists at ixdg.org
--
Announcement Online List (discussion list members get announcements already)
http://subscribe-announce.ixdg.org/
--
http://ixdg.org/

9 Nov 2004 - 8:41am
Dave Malouf
2005

Peter, that was excellent detail; that is very close to the way that we work
here (less than more).

Question? Is this a designer's way of working?

Mind you, I'm in my industrial design classes at the moment so I'm taking a
lot of my thinking by combining what I'm learning there. I will incorrectly
characterize IndDes as being "pure design". Meaning it comes straight out of
the design schools and has very little combination with other disciplines.
There is a limited pull towards engineering, in the case of material
science, but from a methods and practice discipline it is "all design".

I also think that IndDes most closely matches the type of work we do here as
designers of interactions in that it is important for us to be able to
"play" with models before we can determine the level of success with it.

Now, models do not have to be used to communicate downstream to production
sources, but I have discovered that IndDes make their "documentation" very
much in the style of their models. They do annotated presentation layouts
and mechanical drawings and hand these to process/manufacturing engineers.

The other thing I'm curious about with Peter's example is the amount of time
that level of documentation takes? What is more important the documentation
or the design? I'm not saying that Peter is doing this, but I am often
concerned with the documentation time takes as much if not more time than
the time to design and prototype.

I believe as interaction designers that one of our greatest challenges in
figuring out consistent ways to communicate the level of complexity in our
designs. Just like the designs themselves are managing complexity, there is
a lot of complexity we are managing in the communication of that design. I
have not seen a full set of documentation, or just a communication practice
that fulfills the full-line of responsibilities for this communication
process inside and not-disruptive to the design process.

-- dave

10 Nov 2004 - 2:20am
Listera
2004

David Heller:

> The other thing I'm curious about with Peter's example is the amount of time
> that level of documentation takes? What is more important the documentation
> or the design?

Hellllooooo!!!

Call this the Surgeon of Design's Grand Corollary, if you must :-) but:

The amount of documentation is directly proportional to the number of
different titles working in the design team.

To vulgarize, the deliverables (written documentation) often become
title/role/job/salary justification. I'm sure I'm not the only one who has
seen documentation that had better production values than the actual
product.

When I start a new IA/UI/UX surgery project, I can almost always foretell
the kinds of problems I'm going to face by examining the length and the
density of the documentation. The more, the worse.

It's almost always easier to design something when you know there's going to
be 100-page documentation vs. when it has to fit into 5 pages. That goes for
product as well as prototype documentation.

Ziya
Nullius in Verba

10 Nov 2004 - 4:51am
Narey, Kevin
2004

Ziya:

> I'm sure I'm not the only one who has seen documentation that had better
production values than the actual product.

I totally concur with this. I often find that documentation is one of the
most time and money expensive 'assets' produced on projects and is often
regarded as a peripheral problem to the traditional project problem solving
focus. I see it as one of the major communication problems. I recently
backed out of authoring enormous UI Design Specifications to accompany
highly complex prototypes, as I have never yet been able to document *all*
the intricacies needed to communicate what needs coding. As I am
ever-present on the project, I'm used as the document myself - it's working
so far, but then there's no real historical record being kept other than the
prototype and use-cases.

I recently insisted that a consulting company provide me with a document
style that had everything in it that I needed to know and would take me no
longer than ten minutes to read - most would call this a management summary,
but it should be a default wherever possible. This should be accompanied by
a more in depth document for reference. They normally provide one tome-esque
document as a deliverable.

Paper-based documentation remains a potential burden on any project whilst
ever it's considered an asset.

Rgds

Kevin

**********************************************************************
gedas united kingdom limited
Registered in England no. 1371338

This email and any files transmitted with it are confidential
and it may be privileged.

It is intended solely for the use of the individual or entity to
whom it is addressed.

If you have received this in error, please contact the sender
and delete the material immediately.
**********************************************************************

10 Nov 2004 - 5:53am
Tommy Eskelinen
2004

Hi all,
I haven't read all post on this subject so sorry for any double-posting.

In my opinion documentation should be made for any interface that is being
developed. Of course this means the documentation should be of appropriate
detail depending on the size of the project. The bigger the project the
more detailed the documentation.

I use two different approaches for documentation, and thus ensuring
quality of the interaction design and to ensure that it will use the
design principles I've set:

1. Use cases. I use this method when developing a completly new system
(for example an internet banking interface). This method is fairly
detailed, but can be used to prioritize functionality that is being
developed - both by business people and programmers. It's best used in
functionality driven systems. And also useful for creating test cases when
implemented.

2. Dialogue models.
I use this to further detail an interface, and it is the least thing I do
in any project. It's an explanation of the interaction elements used and
what happens if clicked. It doesn't need any design sketches, a simple
powerpoint dummy is enough. This is mainly used by the programmers to
implement the functinality.

My experience is that programmers are happy if they don't have to design
the interface while programming, they want to solve the functionality and
leave the design and layout to other people.

All the best
Tommy Eskelinen
curently looking for a job in Basel, Switzerland
tommy at eskelinen.net

10 Nov 2004 - 3:47pm
Pradyot Rai
2004

On Wed, 10 Nov 2004 02:20:53 -0500, Listera <listera at rcn.com> wrote:
> To vulgarize, the deliverables (written documentation) often become
> title/role/job/salary justification. I'm sure I'm not the only one who has
> seen documentation that had better production values than the actual
> product.

I want to clarify where you are putting the blame and how you solve
the problem where Designer does "design" and developers do the
"coding", and they live/work in different planets.

What would guarantee that the end product comes exactly close to the
polished prototype? Nothing, I have seen equally great numbers of
prototype, which never takes shape of a product.

Problem is not in the better production value of documentation, or in
other design deliverable. I have seen exactly what you mentioned
because designers of the systems are limited to design/documentation,
but are kept away from affirming what's get done on the shop floor. It
points somewhere in the over all process, or the definition of Design,
but I am not sure.

Prady

10 Nov 2004 - 4:19pm
Listera
2004

Prady Rai:

>> To vulgarize, the deliverables (written documentation) often become
>> title/role/job/salary justification. I'm sure I'm not the only one who has
>> seen documentation that had better production values than the actual
>> product.
>
> I want to clarify where you are putting the blame

Management. For deluding itself that the quality of documentation is more
important than the quality of the final product.

> and how you solve the problem where Designer does "design" and developers do
> the "coding", and they live/work in different planets.

That in itself is a problem, perhaps requiring another thread.:-)
But given that, one can reduce ambiguity with more prose or better
prototyping. I choose the latter.

> What would guarantee that the end product comes exactly close to the
> polished prototype? Nothing, I have seen equally great numbers of
> prototype, which never takes shape of a product.

Documentation alone is never a guarantee of a successful product. As I
mentioned before, I make a living as a IA/UI/UX surgeon. In virtually every
case I look into, there is always more documentation than I care to wade
through. Projects do not succeed or fail based on the quality or quantity of
documentation.

Ziya
Nullius in Verba

Syndicate content Get the feed