Use Cases and Personas

7 Oct 2004 - 5:01am
9 years ago
58 replies
2861 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

7 Oct 2004 - 5:52am
Ben Hunt
2004

I'm writing a book on goal-directed web design (Web Design from
Scratch), and have written a section comparing Use Case and Goal/Persona
approaches. This represents my thoughts on the question, Kevin, and I'd
be pleased to hear all feedback.

Ben Hunt
Scratchmedia

Personas and Goals v. Use Case Modelling
========================================

Use Case analysis is a powerful and deservedly popular tool for systems
architects and analysts. It works by breaking down or grouping tasks and
functions into discrete units, called Use Cases.
In many cases, different users (actors) directly or indirectly use the
same functions: whether:
* Accessing the home page of the site
* Submitting a search request
* Save data to database
* Log out

Describing these functions as use cases can help you reduce a complex
system into manageable chunks whose internal functions can be analysed,
developed, and tested independently.

A use case model shows each Use Case, and the interactions between them.
It's a great tool for analysing the scope of a system, identifying
development work in units that can be developed and tested by multiple
work streams. Use Case models also make it easier to ensure you develop
a whole system with no bits missed out. These benefits increase with the
size of a development project.

Use Case models help ensure that all actor tasks can be completed
successfully. Designers test an emerging model using Scenarios, where
you follow a particular actor's route through a system, to check that
all tasks can be fulfilled.

However, Use Cases have some significant competitive weaknesses when it
comes to designing successful systems. They're not useful for
investigating and designing qualitatively, because they are inherently
task-oriented and reductionist.

Use cases are task-oriented, not goal-directed
==============================================

Being able to perform a task or function is critically different to
achieving a goal
e.g. I know I can use any of half a dozen different sites to order train
tickets. I regularly use one particular site, not because it gives me
the best user experience, but because it's the one that helps me achieve
my goal more quickly than the others. In fact, it happens to have a weak
and painfully laborious booking process, and it never remembers who I
am, but it wins because it always gets me my confirmation email within a
few minutes after my payment has processed. Other (better-designed)
sites help me complete my task in a smoother and faster way, but my goal
isn't met until I have received the code that I need to get my tickets
from the machine the next morning.

Use Case Modelling is focussed on tasks, and a use case ends when all
the 'doing' is complete. Goal-directed design, however, doesn't end
until the goal has been reached, the state of being that normally
follows the doing.

Task-oriented use case design also tends to combine all different
contexts of use into a single use case.

e.g. "Tony the supplies buyer comes to the site looking for the contact
details for the Doncaster sales office" is critically different to "Anna
the prospective buyer comes to the site because she has seen a product
review and wants to find out whether the company's product offering is
competitive".

A use-case-based approach would very likely combine both these contexts
of use into "Actor (consumer) accesses Site Home page". This will result
in a site structure that the designers can prove (using the use case
model) is more logical, compact, and manageable, but it's not likely to
serve either Anna or Tony particularly well, and it's not going to help
explore creative opportunities to enhance all visitors' experience and
thereby achieve the company's true goals.

To help both Anna and Tony achieve their goals, the site design must be
developed around their goals, not just their tasks. The problem remains
that there are so many different users, with so many varying goals, you
need a way to manage the goals you work to enable, in order to focus the
design process on a successful outcome.

7 Oct 2004 - 7:07am
Peter Boersma
2003

Kevin Narey wrote:
> 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.

In our in-house design methodology, we develop personas concurrently with
high-level use cases. The personas are initially based on a target group
analysis plus usability requirements, the use cases are based on the vision
and business requirements. However, since our methodology is based on RUP,
the two can influence eachother in subsequent iterations.

To make sure these two artefacts cover the same ground, we write usage
scenarios that are used to (spot)check both the use cases' and the personas'
accuracy.
These scenarios, together with a content inventory, form the basis of our
screenflows.

> I expect a certain amount of
> resistance from developers if the introduction of personas doesn't
> categorically improve the quality of the use-cases.

I don't know if you intend to or not, but we don't show our personas to
developers. The personas are used to develop and evaluate our designs
(business, interaction and visual). The designs are then discussed with
developers, without referring to the personas. The improvement in quality
comes from the iterative development of both use cases and personas with
evaluations in each iteration.

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

7 Oct 2004 - 7:36am
Petteri Hiisilä
2004

Ben Hunt wrote:

> Personas and Goals v. Use Case Modelling
> ========================================

1. The biggest problem with personas is, that almost no one can make
them, yet it seems that everybody is making them. I had read every
possible article and book I could find about them, but I simply had to
take the Cooper U Practicum to learn it.

About Face 2.0 explains it in two or three pages, but that's not enough.
Getting the behavioral variables right and determining the patterns is
the trickiest part. Someone needs to show it to you once. Then it's
simple. Before that, almost impossible. The devil is in the details.

Name, slogan, photo, narrative and a set of goals is not automatically a
persona. It's just creative work.

There's almost no improvising and absolutely no guesswork in a real
persona. All the text is facts based on research. The "salt" is just
added to bring it to life, but those one or two personal details are
chosen in a way, that it does not affect the design. This is very important.

Phony research --> phony personas. It's not smart to shoot between the
eyes, if you shoot the wrong person. Creative personas still gives you a
clear direction, but the direction might well be wrong. There's no way
to prove it. A good map is worth nothing, if it guides you to wrong
destination.

Developers and stakeholders won't (and shouldn't) just take your word
for it. They want proof, and they should have it. Proper research and
modeling gives you just that.

There's no book on personas yet. That's why most people just have to
guess how to make them. As Georg Olsen put it:

"Compounding the problem was that Cooper's seminal The Inmates Are
Running the Asylum talked at length about why personas were important,
but didn't provide many details about how create them. So people
improvised, often with unsatisfying results."

http://www.boxesandarrows.com/archives/making_personas_more_powerful_details_to_drive_strategic_and_tactical_design.php

****

2. The second biggest problem is that you cannot say Personas and Goals
vs. Use Case Modelling. It's like saying planning vs. building. Or
eating vs. breathing. They simply don't compete or replace each other.
Personas come first, and "use cases" are derived from the personas later.

The before-after chart:

1. Research --> Modeling --> Personas
2. Modeling --> Goals
3. Personas & Goals --> Context scenarios (very unlike use cases)
4. Context scenarios --> Requirements
5. Requirements --> Key path scenarios (these are like use cases)
6. Key path scenarios --> Framework
7. Framework --> Design
8. Design --> Communication
9. Communication --> Development support

There's some iteration between 5 and 6.

****

I'm sorry that I have to be this nasty, but I believe that in the long
run it would be good to require that personas are based on pure research
and modeling, not creative writing.

In my opinion that's way more important than requiring that radio
buttons should always have a default, for example.

Creating proper personas won't take any longer, but gives you results
that are dependable.

However, I don't mean that people shouldn't use "creative personas" at
all to guide their work. A direction is still significantly better than
no direction at all. Creative personas can help you there. Otherwise
they wouldn't be that popular, wouldn't they?-)

Best,
Petteri

--
Petteri Hiisilä
Palveluarkkitehti / Interaction Designer /
Alma Media Interactive Oy / NWS /
+358505050123 / petteri.hiisila at almamedia.fi

"The unbroken spirit
Obscured and disquiet
Finds clearness this trial demands"
- Dream Theater

7 Oct 2004 - 8:30pm
Anirudha Joshi
2003

Petteri wrote:
1. The biggest problem with personas is, that almost no one can make
them, yet it seems that everybody is making them. I had read every
possible article and book I could find about them, but I simply had to
take the Cooper U Practicum to learn it.

Have you read Holtzblatt's recent book? Rapid Contextual Design : A
How-to Guide to Key Techniques for User-Centered Design.
I heard that they do have a chapter on personas. I have not read it yet,
but I will appreciate any recommendation.

Patteri wrote:
I believe that in the long
run it would be good to require that personas are based on pure research

and modeling, not creative writing.

Couldn’t agree more.
Anirudha

7 Oct 2004 - 8:25am
Gerard Torenvliet
2004

Petteri wrote:

> 1. The biggest problem with personas is, that almost
> no one can make them, yet it seems that everybody is
> making them. I had read every possible article and
> book I could find about them, but I simply had to take
> the Cooper U Practicum to learn it.

Well said. I recently attended a course in which the instructors said the same thing, but about a different techique (Gary Klein's Critical Decision Method, a method for deconstructing expertise).

The point is that our discipline rests on deriving great requirements, and requirements research is mainly qualitative research. Our discipline is going to improve the more that we apply rigour to these research techniques so that their results are, as much as possible, repeatable.

Back to your morning coffee,

-Gerard

:: Gerard Torenvliet / gerard.torenvliet at cmcelectronics.ca
:: Human Factors Engineering Design Specialist
:: CMC Electronics Inc.
::
:: Ph - 613 592 7400 x 2613
:: Fx - 613 592 7432
::
:: 415 Legget Drive, P.O. Box 13330
:: Ottawa, Ontario, CANADA, K2K 2B2
:: http://www.cmcelectronics.ca

7 Oct 2004 - 9:00am
Ben Hunt
2004

Petteri, thanks for your comments.

Do you support the assertion that a goal-directed approach is
qualitatively different to use case modelling? Or is that only true if
the goal-directed approach adheres to the highest standards? If it
doesn't, are we better off using just a use case model?

The key insight for me was: goals are greater than functions... and
therefore excellent systems should design right up to the goal's being
met, not just the function being carried out successfully.

The two approaches do seem to me to work on different levels, and I've
found even fairly random creative personas have helped me have insights
into software design that I simple wouldn't have discovered otherwise.

- Ben

7 Oct 2004 - 9:39am
Jerry John
2004

hey thanx Petteri,

... there is this thing stuck on my mind ! and need to get it outta my
system;

1) if i'm writing a persona; with a fictitious character; these
frustrations - that means i already know have a list his problems; how does
a narrative help me. i have already established this for a fact that there
is a feature that needs attention and will become a part of my requirements
list ....

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
ers.com]On Behalf Of Petteri Hiisilä
Sent: Thursday, October 07, 2004 6:06 PM
To: discuss at interactiondesigners.com
Subject: Re: [ID Discuss] Use Cases and Personas

[Please voluntarily trim replies to include only relevant quoted material.]

Ben Hunt wrote:

> Personas and Goals v. Use Case Modelling
> ========================================

1. The biggest problem with personas is, that almost no one can make
them, yet it seems that everybody is making them. I had read every
possible article and book I could find about them, but I simply had to
take the Cooper U Practicum to learn it.

About Face 2.0 explains it in two or three pages, but that's not enough.
Getting the behavioral variables right and determining the patterns is
the trickiest part. Someone needs to show it to you once. Then it's
simple. Before that, almost impossible. The devil is in the details.

Name, slogan, photo, narrative and a set of goals is not automatically a
persona. It's just creative work.

There's almost no improvising and absolutely no guesswork in a real
persona. All the text is facts based on research. The "salt" is just
added to bring it to life, but those one or two personal details are
chosen in a way, that it does not affect the design. This is very important.

Phony research --> phony personas. It's not smart to shoot between the
eyes, if you shoot the wrong person. Creative personas still gives you a
clear direction, but the direction might well be wrong. There's no way
to prove it. A good map is worth nothing, if it guides you to wrong
destination.

Developers and stakeholders won't (and shouldn't) just take your word
for it. They want proof, and they should have it. Proper research and
modeling gives you just that.

There's no book on personas yet. That's why most people just have to
guess how to make them. As Georg Olsen put it:

"Compounding the problem was that Cooper's seminal The Inmates Are
Running the Asylum talked at length about why personas were important,
but didn't provide many details about how create them. So people
improvised, often with unsatisfying results."

http://www.boxesandarrows.com/archives/making_personas_more_powerful_details
_to_drive_strategic_and_tactical_design.php

****

2. The second biggest problem is that you cannot say Personas and Goals
vs. Use Case Modelling. It's like saying planning vs. building. Or
eating vs. breathing. They simply don't compete or replace each other.
Personas come first, and "use cases" are derived from the personas later.

The before-after chart:

1. Research --> Modeling --> Personas
2. Modeling --> Goals
3. Personas & Goals --> Context scenarios (very unlike use cases)
4. Context scenarios --> Requirements
5. Requirements --> Key path scenarios (these are like use cases)
6. Key path scenarios --> Framework
7. Framework --> Design
8. Design --> Communication
9. Communication --> Development support

There's some iteration between 5 and 6.

****

I'm sorry that I have to be this nasty, but I believe that in the long
run it would be good to require that personas are based on pure research
and modeling, not creative writing.

In my opinion that's way more important than requiring that radio
buttons should always have a default, for example.

Creating proper personas won't take any longer, but gives you results
that are dependable.

However, I don't mean that people shouldn't use "creative personas" at
all to guide their work. A direction is still significantly better than
no direction at all. Creative personas can help you there. Otherwise
they wouldn't be that popular, wouldn't they?-)

Best,
Petteri

--
Petteri Hiisilä
Palveluarkkitehti / Interaction Designer /
Alma Media Interactive Oy / NWS /
+358505050123 / petteri.hiisila at almamedia.fi

"The unbroken spirit
Obscured and disquiet
Finds clearness this trial demands"
- Dream Theater

_______________________________________________
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/

7 Oct 2004 - 10:18am
Todd Warfel
2003

Bill Baxley has a book out that has a good section on Personas:

http://www.baxleydesign.com/pubs/mww_desc.html

On Oct 7, 2004, at 8:36 AM, Petteri Hiisilä wrote:

> 1. The biggest problem with personas is, that almost no one can make
> them, yet it seems that everybody is making them. I had read every
> possible article and book I could find about them, but I simply had to
> take the Cooper U Practicum to learn it.
>

Cheers!

Todd R. Warfel
Partner, Design and Usability Specialist
MessageFirst | making products easier to use
--------------------------------------
Contact Info
voice: (607) 339-9640
email: twarfel at messagefirst.com
web: www.messagefirst.com
aim: twarfel at mac.com
--------------------------------------
In theory, theory and practice are the same.
In practice, they are not.

7 Oct 2004 - 12:10pm
Josh Seiden
2003

Narrative is a powerful medium for clarifying and
expressing our thoughts. It has the advantage of being
a nearly universal medium. Anyone can understand story;
only trained and motivated audiences understand
spreadsheets and requirements documents.

Narrative has the additional quality of being
evocative--you tell a story, and the listener fills in
the gaps from his or her own experience. This dynamic
means helps people understand a complex data set in a
very deep, personal way. In these and other ways,
narrative helps communicate research and
decision-making.

Narrative also helps create decision making--it helps
the teller create the story. One of the great clichés
of fiction is that characters "take on a life of their
own." Personas do this too, when our intuitive or
non-verbal (or not-yet-verbalized) understanding of the
research finds an expression in a story. These stories
often carry design solutions with them, or crystallize
for us a part of the story which makes the solution
obvious.

JS

> -----Original Message-----

>
> ... there is this thing stuck on my mind ! and need
to get it
> outta my system;
>
> 1) if i'm writing a persona; with a fictitious
character;
> these frustrations - that means i already know have a
list
> his problems; how does a narrative help me. i have
already
> established this for a fact that there is a feature
that
> needs attention and will become a part of my
requirements list ....
>

7 Oct 2004 - 12:43pm
whitneyq
2010

At 01:10 PM 10/7/2004 -0400, Joshua Seiden wrote:
>Narrative is a powerful medium for clarifying and
>expressing our thoughts. It has the advantage of being
>a nearly universal medium. Anyone can understand story;
>only trained and motivated audiences understand
>spreadsheets and requirements documents.

Yes yes yes.

In fact, I just completed a chapter on personas and storytelling. It will
appear in a new book on personas - The Personal Lifecycle by Tamara Adlin
and John Pruitt - due out from Morgan Kauffman this spring.

The book is a practical look at how to create and use personas, and has a
few guest chapters on related aspects of how and why personas work.

My basic belief, echoing everything that Josh said, is that personas work
because they encapsulate and communicate stories.

Whitney Quesenbery
Whitney Interactive Design, LLC
w. www.WQusability.com
e. whitneyq at wqusability.com
p. 908-638-5467

UPA - www.usabilityprofessionals.org
STC Usability SIG: www.stcsig.org/usability

7 Oct 2004 - 1:29pm
Listera
2004

Ben Hunt:

> The key insight for me was: goals are greater than functions... and
> therefore excellent systems should design right up to the goal's being
> met, not just the function being carried out successfully.

I'm struggling to see the difference here.

The example you provided was a bit contrived in the sense that a specific
task (email confirmation) was poorly designed (took too long), period. It
would stand as a badly designed bit of functionality no matter in what
combination of steps it stood given any trajectory of ticket buying
experience (goals). Here, the function (email confirmation) was *not*
carried out successfully.

If I'm buying books online why would I ever want to be told my item is out
of stock a day after I ordered it, if real-time inventory checking was
possible? Why would I ever want to look up train schedules online, if the
only way to get results was through email a day later, likely long after my
train left the station? These are poorly designed "functions" regardless of
the distinct permutations of steps that would define specific "goals."

Ziya
Nullius in Verba

8 Oct 2004 - 2:12am
Ben Hunt
2004

Ziya:
>> It would stand as a badly designed bit of functionality no matter in
what combination
>> of steps it stood given any trajectory of ticket buying experience
(goals).
>> Here, the function (email confirmation) was *not* carried out
successfully.

I agree with you. My point is that goal-oriented design isn't quite on
the same plane as use case design, in that goals and functions aren't
tied together.

In the ticket-booking example I used, my complete user experience on the
web site counted for nothing, because it didn't deliver me my mental
assurance goal. And yes, it was the function that let the system down
(or the design behind it), but that will always be true in a
computerised system.

So, sometimes goals come after a series of functions. Sometimes, I'd
imagine that goal states are reached *during* functions (e.g. "We're
having fun now!").

Therefore, a use case model that helps us prove *that* all the functions
are completed is qualitatively different to an exercise using
goal-directed scenarios that are more concerned with the *how*.

(I guess I have a lot of resentment against use cases, because I'm
currently working in a UK Government environment methodology where use
cases are considered all things to all men, and it's not succeeding in
delivering any kind of quality system design at all.)

- Ben

8 Oct 2004 - 2:22am
Listera
2004

Ben Hunt:

> I agree with you. My point is that goal-oriented design isn't quite on
> the same plane as use case design, in that goals and functions aren't
> tied together.

I'll take it further. On a reasonably complex interactive system it's folly
to think that you as a designer can discover and optimize all (permutations
of) usage patterns (goals). And, generally speaking, you don't need to.

During the course of the design process, you get to make dozens of decisions
based on your experience and understanding of the problems at hand, without
testing or creating personas, use cases, etc. There's no avoiding this,
unless you want to see your competitors release v 3.0s while you try to get
out your v 0.8b.

Successful companies understand this: Amazon, eBay, Google, etc don't
pretend to know in advance what their users are capable of doing with their
site (goals). They publish public APIs so that a secondary layer of
abstraction can be created by more focused independent developers or they
give end-users tools to customize their own experiences (goals). In other
words, their resources are better maximized on optimizing the functionality
and robustness of their components/frameworks, rather than trying to
anticipate the entire gamut of potential usage scenarios.

That obviously doesn't mean that they don't do any research. Just the
opposite, instead of engaging in a priori user-goal anticipation, they track
empirical usage patterns, and adjust.

Side question: If it were on the ballot next month, would you vote to
criminalize the delivery of personas/use cases in prose by designers to
developers? :-)

Ziya
Nullius in Verba

8 Oct 2004 - 5:50am
Ben Hunt
2004

Ziya:
>> I'll take it further. On a reasonably complex interactive system it's
folly
>> to think that you as a designer can discover and optimize all
(permutations
>> of) usage patterns (goals). And, generally speaking, you don't need
to.

I'm still totally with you :-)

I think a rough guide to web IA might go:

- Common sense (What's bleeding obvious?)
- Test first assumptions (e.g. Don't model directly on your corporate
structure, unless that's helpful for *people*)
- Content (What do you have to say? How much is there? How frequently
does it change? Is it permanent/growing/variable? What will *people*
come for and expect?)
- Conventions (What standard categorisations/flows exist in your
domain?)
- Test with specific prioritised persona-scenarios (I use a dialogue
method, using visitor personas and a site/brand persona who also
represents the site's goals)
- Hopefully, scenarios will reveal ways to optimise the flow through,
to achieve goals quicker, easier or better

Does that look sensible?

- Ben

8 Oct 2004 - 11:51am
Petteri Hiisilä
2004

> Do you support the assertion that a goal-directed approach is
> qualitatively different to use case modelling? Or is that only true if
> the goal-directed approach adheres to the highest standards? If it
> doesn't, are we better off using just a use case model?

Hi Ben,

Here's my long-winded answer. I hope this helps to clarify something.

Use cases (key path scenarios) are one subset of the whole Goal-directed
process. You'd better have a clear big picture before you start to do
any use cases.

Simply:

- who's the user
- what she's trying to accomplish
- how can we help her

I'm sure you do this with use cases too, but it has to happen before you
write the first use case.

Cooper's method has quite a different use of words or labels like Goal
or Scenario. I like the way it works its way from very high level
abstraction to very low level dirty details. And I also like the fact
that although it contains very small intuitive leaps, or "guesswork",
but it's still very creative process.

Here's how:

0. First you find out who to interview. Then you forget all assumptions,
and do the research and modeling. "Pillage, then burn." When you've
finished this, you've derived the goals and the narrative, which isn't
creative writing but a modeled version of a real person. An archetype.
Usually you get just one or two personas for any simple consumer product.

1. Goals = human goals, very high level. Like "make sales" or "enjoy
photos" or "find the perfect item quickly". This stuff is usually
obvious from the hindsight, but not at all abvious if you face a new
problem, product or concept. Check out About Face 2.0. It's got a good
chapter of the subject.

To get the goals right, you have to erase everything you assume about
the problem. Not literally, but almost. Good research and modeling gives
you those high-level goals. I'm confident that they are the same every
time, no matter who studies the problem. Assuming that the person knows
what he/she's doing.

Confident? How? I've now studied the digital photo book and digital
photo printing problem three times. First here in Finland by Idean
Research. Second time at Cooper U by David Fore. Third time at a Finnish
GDD seminar by the class of sixteen product managers. Never we made
stuff up. Every time we had interviews. Different people, different
backgrounds, even different countries. And every time the same set of
goals came out from the other end of the pipe! The same three! Can't
happen three times in a row by accident, can't it?-)

2. Context scenarios = high-level scenarios, like little stories how the
product or system is used in real life situations. These are very short.
It tells what is being done, but not how. These are derived from the
persona's life, lifestyle and goals. These are just few sentences long.
If you have to compare these to use cases, these are very very high
level use cases.

If these stories don't make much sense to the target group, the changes
are, that the product is also going to be a failure. Context scenarios
assume that a lot of the product technology is just magic. Black box
-thinking.

3. From these you get the data and functional requirements. Again, these
are still very high level and very much attached to human head. This is
stuff like mental data item = photo. Photo can have mental attributes
like "person" or "place" or "time". Functionality is derived from the
context scenarios: "find photos of certain place" "tag a place to a
number of photos".

4. Key path scenarios implement the functionality using the data and
attributes defined in step three. These have got quite a lot of detail.
This is the subset of the GDD process that is very close to traditional
"use cases" or "tasks". It's important to do steps 1-3 too, if you want
to stay on track, and on the right track.

5. Framework implements #4 in visual or other form. Drop the
functionality down on the plan and make sure that the big picture is
coherent.

6. Design phase puts smaller widgets and pixels in place.

What's so good about doing all these phases?

It's because everything is derived from the previous phase. Every view
and button is there NOT because it's possible, but because it HAS to be
there. It's place, size and usage logic is exactly that, because it HAS
to be.

Validation scenarios ("what if" -questions, in phase 4) make sure that
no functionality is forgotten. But usually missing features isn't the
problem. It's that we've got too many useless features. We all know how
to add anything that's missing. Reducing features, that's the tricky
thing to do. It's a whole lot easier, if you work top-down.

See, it's like a chain. When it's final, it's the simplest complete
solution.

Get rid of any view or button from the final framework (5), and key path
is broken (4). Functionality is missing (3). Context scenario doesn't
happen like it should (2). Human goal of "enjoy photos" isn't fulfilled (1).

The method starts from the top, from the goals. Goes down into details,
layer by layer. Top-down.

First you "work your way all the way up to the goals", and then "work
your way down" to details. Everything is derived from the higher level
of abstraction. It should be called Goal-derived design :)

It's very different method to collect tasks and pile them until you
"reach" the goal. It sure works that way too, but the result isn't
always both complete and simplest solution.

The problem is that when you start mixing these two, you're in danger of
going up and down, down and up.

Deriving the solution from the smallest possible dataset helps to get
the essentials to the design, and nothing else.

If use cases aren't directly derived from the higher level of proven
abstraction, they are in danger of being either wrong or irrelevant.

Of course, this happens just in theory. But as we all know, it's easy to
lose the big picture once you go deep into details. Especially, if you
never really made sure that THIS is the big picture. Outlining the
problem gives you focus.

That said, if you can't research and model the big picture, a good
educated guess is better than nothing. A slightly wrong direction is a
lot better than trying to get in all possible directions at the same time.

Use cases gives you directions. Creative personas give you a direction.
Personas give you the right direction.

Best,
Petteri

--
Petteri Hiisilä
Palveluarkkitehti / Interaction Designer /
Alma Media Interactive Oy / NWS /
+358505050123 / petteri.hiisila at almamedia.fi

"The unbroken spirit
Obscured and disquiet
Finds clearness this trial demands"
- Dream Theater

9 Oct 2004 - 2:15am
Listera
2004

Ben Hunt:

> I think a rough guide to web IA might go:
[...]
> - Conventions (What standard categorisations/flows exist in your
> domain?)
[...]
> Does that look sensible?

Yes, except for the word 'standard'.

Ziya
Nullius in Verba

4 Nov 2004 - 3:47pm
John Vaughan - ...
2004

Very belated thanks to all who contributed to this thread - as I've only just now done my info-gleaning...

This topic's finally gotten the interest of IT mgt here at the office, so I've forwarded on to them some of your collective thoughts, plus my own comments on the topic. (Ben, your excerpt very well-stated - Please keep me posted on book.) The org tries to be very processy here, but there's a big knowledge gap when it comes to gathering requirements.

As noted by several of you, Use Cases and Workflow charts just don't do a great job of identifying valuable "satisfiers" & ephemera. The concept of "goals" works for me, but doesn't have much cachet in the code-centric community - and language is critical. I sometimes try to characterize it as "capturing the water cooler info" or "a day in the life...".

Any success stories/suggestions re getting traditional IT Dev folks to buy into the systematic capture of personas, goals, narratives and other eclectic stuff?

** PS: Does anybody else use our forum as a resource for collecting supportive collateral, snippets, rants, etc. to use in prosletyzing IXD @ the office? **

4 Nov 2004 - 3:53pm
Listera
2004

vaughan1 at optonline.net:

> The concept of "goals" works for me, but doesn't have much cachet in the
> code-centric community

You hand in use cases directly to developers?

Ziya
Nullius in Verba

5 Nov 2004 - 5:29pm
kjnarey
2004

Ziya:
>You hand in use cases directly to developers?

I'll bite...
Why what do you do with them?

Kevin

_______________________________________________
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/

4 Nov 2004 - 5:34pm
Listera
2004

kjnarey:
>> You hand in use cases directly to developers?

> Why what do you do with them?

I'm a designer. I design stuff. I don't expect developers to take my use
cases and design them for me. I expect them to implement what I designed. My
job is to *reduce* ambiguity and/or risk, not increase it by handing
code-writers prose.

Ziya
Nullius in Verba

5 Nov 2004 - 6:00pm
kjnarey
2004

Ziya:
> I don't expect developers to take my use cases and design them for me.

Uh-huh,
So, are you saying that the complex class models and sequence diagrams that
OOP architects derive mostly from use-cases (whether they contain goal
related prose or not) are meaningless? Who actually uses your use-cases in
your world? What purpose do they serve? Are you writing class
models/sequence diagrams/UML too?

Kevin

4 Nov 2004 - 6:01pm
John Vaughan - ...
2004

> > The concept of "goals" works for me, but doesn't have much
> cachet in the
> > code-centric community
>
> You hand in use cases directly to developers?

In this shop the BA's write the actual Use Cases. Use Cases are x-refed to Business Rules, data tables & other collateral. Yes, the coders supposedly use all those materials.

The issue is that some very valuable info is missing from the pounds of redundant, poorly organized, unclear, lacking-in-context (or "story")documentation that's produced to support The Process Machine.

So there's lots of data and a functional mechanical structure - but little meaning. The code engine *works*, but the lack of practical context means that "customer satisfaction" is often a hit-or-miss exercise. Net Result: delays & re-engineering

4 Nov 2004 - 6:19pm
Listera
2004

kjnarey:

> So, are you saying that the complex class models and sequence diagrams
> that OOP architects derive mostly from use-cases (whether they contain goal
> related prose or not) are meaningless?

Who said they are meaningless? They are meaningful for developers, that's
*their* work-product, not a design by-product.

My job, in this case, is interaction design, not class models/sequence
diagrams/UML production. (Personally I can, but that's besides the point.)

My intentions as a designer are best expressed by an interactive prototype.
Developers can then observe, click and do their own class models/sequence
diagrams/UML, if they need to.

> Who actually uses your use-cases in your world?

Generally speaking, they are used during design by other designers and with
other stakeholders for input/validation/etc.

> What purpose do they serve?

They illuminate design, not development.

> Are you writing class models/sequence diagrams/UML too?

No, because developer get paid to do them.

Ziya
Nullius in Verba

4 Nov 2004 - 6:24pm
John Vaughan - ...
2004

> So, are you saying that the complex class models and sequence
> diagrams that
> OOP architects derive mostly from use-cases (whether they contain goal
> related prose or not) are meaningless?

...errr......noooooo... I didn't say (or even imply) that they are "meaningless".

What i SAID was that they are incomplete, in the sense that they *in*adequately capture valuable customer information that makes for a satisfying experience. And that is kind of what our job is all about - no?

BTW : "goals" - like any other information - can be presented (organized) in a format other than prose. In the code-centric world, communicating value is often a challenge. Doing so successfully helps the IT dev team to deliver a satisfying product.

Got any useful suggestions for how to do so?

4 Nov 2004 - 6:35pm
Listera
2004

vaughan1 at optonline.net:

> BTW : "goals" - like any other information - can be presented (organized) in a
> format other than prose. In the code-centric world, communicating value is
> often a challenge.

Why do you say that? For programmers, running code is the ultimate
expression. Designers do not produce prose, developers do not produce prose.
It's not the best medium to stuff intentions and shuttle between the two
teams.

> Got any useful suggestions for how to do so?

If anyone hasn't heard my rants on prototyping, let me know. :-)

Ziya
Nullius in Verba

4 Nov 2004 - 6:52pm
John Vaughan - ...
2004

John said
> In the code-centric world,
> communicating value is
> > often a challenge.

Listera said
> Why do you say that? For programmers, running code is the ultimate
> expression. Designers do not produce prose, developers do not
> produce prose.
> It's not the best medium to stuff intentions and shuttle between
> the two
> teams.

I'm getting a little lost here. Can you help me out?

"developers" = Coders?
"designers" = ?
"the two teams" = ?

BTW: I'm talking about the standard (by my experience) IT Team, which usually is comprised of many coders, several business analysts, a few managers, a few QA folks, a single UXP/UI person

4 Nov 2004 - 6:58pm
Listera
2004

vaughan1 at optonline.net:

"developers" = Coders
"designers" = Designers
"the two teams" = Design and Development

Ziya
Nullius in Verba

5 Nov 2004 - 7:19pm
kjnarey
2004

To Ziya:

So use cases are purely a communication between designers and should never
even reach the eyes of a developer. We've established your views on that.
Perhaps I'm reading this wrongly, but you seem to discount that there is not
even a modicum of design in the engineering faculty of software development
(not just in this string either). Do you feel this erodes your worth?
I guess it comes down to designing products that could never be realised. Do
you code your own prototypes?

Ziya:
>class models are not a design by-product.

I disagree - that's exactly what they are in my space. Objects are derived
from use-cases by design. Unless you want to re-write years of OO history.

I personally have good experiences of seeing highly skilled software
developers who design software within design patterns to solve user-derived
goal problems within technical constraints. I consider this to be
engineering design. Having empathy with developers (as they are also my
users) has proven mutually beneficial for me in being able to educate them
about user problems and how they should drive the design process. I rely on
technical bods giving me advice on what boundaries I should work within from
a practical perspective and knowing the users goals myself, come to a
workable design solution. Lookin' like a style thang.....

Kevin

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
ers.com]On Behalf Of Listera
Sent: 04 November 2004 23:20
To: discuss at interactiondesigners.com
Subject: Re: [ID Discuss] Use Cases and Personas

[Please voluntarily trim replies to include only relevant quoted material.]

kjnarey:

> So, are you saying that the complex class models and sequence diagrams
> that OOP architects derive mostly from use-cases (whether they contain
goal
> related prose or not) are meaningless?

Who said they are meaningless? They are meaningful for developers, that's
*their* work-product.

My job, in this case, is interaction design, not class models/sequence
diagrams/UML production. (Personally I can, but that's besides the point.)

My intentions as a designer are best expressed by an interactive prototype.
Developers can then observe, click and do their own class models/sequence
diagrams/UML, if they need to.

> Who actually uses your use-cases in your world?

Generally speaking, they are used during design by other designers and with
other stakeholders for input/validation/etc.

> What purpose do they serve?

They illuminate design, not development.

> Are you writing class models/sequence diagrams/UML too?

No, because developer get paid to do them.

Ziya
Nullius in Verba

_______________________________________________
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/

4 Nov 2004 - 7:38pm
Listera
2004

kjnarey:
> So use cases are purely a communication between designers and should never
> even reach the eyes of a developer.

For the last time, I haven't said anything about whether developers should
or should not use use cases. I'm not in a position to tell developers how
they should conduct their own internal affairs. What I said was, designers
should not be handing in prose to developers.

> We've established your views on that.

I'd feel much better if you let me state my own views.

> Do you feel this erodes your worth?
> I guess it comes down to designing products that could never be realised.

I have nothing more to add if you want to take this personally offensive
path.

> Do you code your own prototypes?

Of course, I do. Shouldn't all designers, at least some day soon?

> I personally have good experiences of seeing highly skilled software
> developers who design software within design patterns to solve user-derived
> goal problems within technical constraints.

I think I have explicitly stated, perhaps 867 times on this list, I'm
against programmers playing IA/UI/UX designers. I have of course no
objections to programmers doing whatever they feel they need to do
*internally* to do their job, which in my opinion should be implementing the
prototype done by the design team.

Designers should conceive/design, developers should code/implement.

Ziya
Nullius in Verba

5 Nov 2004 - 4:53am
Peter Boersma
2003

Vuaghan1 wrote:

> BTW: I'm talking about the standard (by my experience) IT Team,
> which usually is comprised of many coders, several business
> analysts, a few managers, a few QA folks, a single UXP/UI person

That is a limited experience. I've been in that situation (I think we've all
been) but some of us have been able to move to a new situation where, at
least during the requirements gathering and design phases, UX/UI people are
a sizeable part of the project team.

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

5 Nov 2004 - 7:40am
John Vaughan - ...
2004

> Vuaghan1 wrote:
>
>> BTW: I'm talking about the standard (by my experience) IT Team,
>> which usually is comprised of many coders, several business
>> analysts, a few managers, a few QA folks, a single UXP/UI person

Booersma said:
> That is a limited experience.

JV:
Not really. 20+ years so far.

Booersma said:
>I've been in that situation (I think we've all
> been) but some of us have been able to move to a new situation where, at
> least during the requirements gathering and design phases, UX/UI people
> are
> a sizeable part of the project team.

JV:
Clearly, my observation was a generalization - and, as such, it's generally
true of the corporate IT arena that is the overwhelming majority of the job
market opportunities for us IXD professionals. You're own admission - "I've
been in that situation (I think we've all been)" sort of underscores the
truth of the statement, doesn't it? Which is not to say that it isn't
changing - At least I hope so. But I'll stick with my version of perceived
reality for now.

The Question remains:
I propose that the "standard" IT practices (s.a.Use Cases and Biz Reqs)
don't successfully capture some of the more ephemeral "customer satisfiers".
How do we change that?

5 Nov 2004 - 9:15am
ralph lord
2004

> Vuaghan1 wrote:

The Question remains:
I propose that the "standard" IT practices (s.a.Use Cases and Biz Reqs)
don't successfully capture some of the more ephemeral "customer
satisfiers".
How do we change that?

My answer:
We don't change Use Cases and Business Rules. We use other deliverables
to communicate those things that ""standard" IT practices" don't. Some
suggestions have been: pictures, prototypes, powerpoint, sketches,
pictures, prototypes, examples, simulations, pictures, prototypes,etc.

RL

5 Nov 2004 - 10:38am
Robert Reimann
2003

I think the confusion here is with the term "use case,"
which means different things to developers than to IxDers
(at least where I come from).

I've avoided the term "use case" for this reason in my
writings about design methodology. At Cooper, we chose
the term "scenario," and identified (as others have) two types,
a high-level type addressing design issues at the level of goals,
and used primarily for concept exploration. These are
"day-in-the-life" scenarios-- very similar to what John Carroll
has called "context" scenarios-- and "detail" or "key-path"
scenarios, which are task-oriented, and more akin to what are
usually referred to as use cases.

I happen to agree that design scenarios of both types
are best used by designers in creating prototypes and
other illustrative design specs, and should not in general
be handed directly to developers, primarily because this leaves
far too much room for interpretation when it comes to
both the form and the behavior of the product.

I also agree that it is not the job of designers to develop
class models, UML diagrams, and other code-facing architectural
models.

Robert.

---

Robert Reimann
Manager, User Interface Design
Bose Design Center

Bose Corporation
The Mountain
Framingham, MA 01701

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.
com] On Behalf Of kjnarey
Sent: Friday, November 05, 2004 6:00 PM
To: Listera; discuss at interactiondesigners.com
Subject: RE: [ID Discuss] Use Cases and Personas

[Please voluntarily trim replies to include only relevant quoted material.]

Ziya:
> I don't expect developers to take my use cases and design them for me.

Uh-huh,
So, are you saying that the complex class models and sequence diagrams that
OOP architects derive mostly from use-cases (whether they contain goal
related prose or not) are meaningless? Who actually uses your use-cases in
your world? What purpose do they serve? Are you writing class
models/sequence diagrams/UML too?

Kevin

_______________________________________________
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/

5 Nov 2004 - 10:53am
ralph lord
2004

We use the two levels as well. One for concepting, which borrows some
from Cooper and others and is very high-level and then we let the term
use-case live on but call them "Visual Use Cases" since we're
essentially putting pictures in the order necessary to illustrate the
completion of a use-case.

RL

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
ers.com] On Behalf Of Reimann, Robert
Sent: Friday, November 05, 2004 10:39 AM
To: discuss at interactiondesigners.com
Subject: RE: [ID Discuss] Use Cases and Personas

[Please voluntarily trim replies to include only relevant quoted
material.]

I think the confusion here is with the term "use case,"
which means different things to developers than to IxDers
(at least where I come from).

I've avoided the term "use case" for this reason in my
writings about design methodology. At Cooper, we chose
the term "scenario," and identified (as others have) two types,
a high-level type addressing design issues at the level of goals,
and used primarily for concept exploration. These are
"day-in-the-life" scenarios-- very similar to what John Carroll
has called "context" scenarios-- and "detail" or "key-path"
scenarios, which are task-oriented, and more akin to what are
usually referred to as use cases.

I happen to agree that design scenarios of both types
are best used by designers in creating prototypes and
other illustrative design specs, and should not in general
be handed directly to developers, primarily because this leaves
far too much room for interpretation when it comes to
both the form and the behavior of the product.

I also agree that it is not the job of designers to develop
class models, UML diagrams, and other code-facing architectural
models.

Robert.

---

Robert Reimann
Manager, User Interface Design
Bose Design Center

Bose Corporation
The Mountain
Framingham, MA 01701

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
ers.
com] On Behalf Of kjnarey
Sent: Friday, November 05, 2004 6:00 PM
To: Listera; discuss at interactiondesigners.com
Subject: RE: [ID Discuss] Use Cases and Personas

[Please voluntarily trim replies to include only relevant quoted
material.]

Ziya:
> I don't expect developers to take my use cases and design them for me.

Uh-huh,
So, are you saying that the complex class models and sequence diagrams
that
OOP architects derive mostly from use-cases (whether they contain goal
related prose or not) are meaningless? Who actually uses your use-cases
in
your world? What purpose do they serve? Are you writing class
models/sequence diagrams/UML too?

Kevin

_______________________________________________
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/
_______________________________________________
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/

5 Nov 2004 - 11:23am
John Vaughan - ...
2004

Bingo. And thank you, Robert.

> I've avoided the term "use case" for this reason in my
> writings about design methodology. At Cooper, we chose
> the term "scenario," and identified (as others have) two types,
> a high-level type addressing design issues at the level of goals,
> and used primarily for concept exploration. These are
> "day-in-the-life" scenarios-- very similar to what John Carroll
> has called "context" scenarios-- and "detail" or "key-path"
> scenarios, which are task-oriented, and more akin to what are
> usually referred to as use cases.

So here's my dilemma:

In my experience, the "standard" IT environment embraces the "key-path"
scenario (usually calling it a "Use Case"). The Use Case is
well-integrated, respected and accepted as an integral part of the IT Dev
Process.

In my experience, the "standard" IT environment DOES NOT embrace the
"context" scenario. Goal Directed Design (or whatever we choose to call it)
is generally NOT integrated, respected and accepted as an integral part of
the IT Dev Process. The design is weaker as a result - of course.

Given this assumption (and such is my experience)

1) How do we evolve the "standard" IT Dev Process so as to ensure that this
valuable GDD information is captured in the first place?

2) How do we ensure that the GDD info is actually implemented?

If you're already in a working environment that has the strategic vision to
do GDD, cool. I'm trying to come up with tactics for getting less the
enlightened workplaces (which are the majority of the IT shops, I'm sorry to
say) up to that level.

5 Nov 2004 - 12:26pm
Listera
2004

John Vaughan:

> the "standard" IT environment

The "standard" IT approach doesn't work very well, and hasn't for a good
while. We know this empirically because an embarrassingly large portion of
IT-led site/app design efforts have failed over the last decade. And will
continue to do so if current IT practices keep dominating the design
process. We can all argue around the edges and terminologies, but the
solution begins with IT going back to implementation and leaving the
concept/design arena to designers. There, I said it.:-)

Ziya
Nullius in Verba

5 Nov 2004 - 1:32pm
John Vaughan - ...
2004

Ziya:
> The "standard" IT approach doesn't work very well, and hasn't for a good
> while. We know this empirically because an embarrassingly large portion of
> IT-led site/app design efforts have failed over the last decade. And will
> continue to do so if current IT practices keep dominating the design
> process. We can all argue around the edges and terminologies, but the
> solution begins with IT going back to implementation and leaving the
> concept/design arena to designers. There, I said it.:-)

Yup Yup Yup

All quite true - and abundantly self-evident to all of "us". Of course. Not
necessarily so for most of the IT managers I've met, tho.

Nonetheless, I'm trying to address that problematic area of the diagram
labelled "... and then A Miracle Happens ...".

You know -
The arrow that sits between
"The Way Things Actually Are Right Now"
and
"The Way Things Oughtta Be"

Suggestions?

Gating Factor:
> "the solution begins with IT going back to implementation and leaving the
> concept/design arena to designers."
I agree. Of course. But have you ever, ever, EVER seen a bureaucrat (or
anyone, else, for that matter) voluntarily give up power to an unknown
entity who's below them on the org chart? Do you know many(any?) IxD
professionals who swing that kind of swat? Actually, this makes a fairly
compelling argument for maintaining IxD as an outsourced service - and, as
it happens, I'm a believer. In the meantime / in the real world, it seems
that most of the immediate work opportunities are to serve as the token
humanist in a geek-centric world. so how do we pull it off gracefully?
Thereby convincing them to do what you suggest...

JV

5 Nov 2004 - 3:06pm
Robert Reimann
2003

I think the real issue is that while IT use cases are *similar*
to detail/key-path scenarios, they aren't identical. IT-generated
use cases very much view humans as peripherals attached to a
system: the human provides input and the system responds with
an action. They therefore tend to be machine-centric, whether
they mean to be or not.

The reason detail scenarios are different is because they use
the output of context scenarios (hi-level design concepts) as
an input to drilling down into detailed tasks; it's a top-down
approach to interaction/experience design. Without the user
context revealed by context scenarios, detailed use cases will
lack the coherence that a goal-directed approach permits.
What provides the coherence at the context scenario level is a
clear understanding of the primary users achieved via tools such
as ethnography and personas.

Getting this type of methodology adopted in a traditional
IT organization is a challenge, but not an insurmountable
one. If you can get your organization to admit that some
amount of understanding of users is a prerequisite to building
a product, then you can try by lumping everything that happens
before detail scenarios into the "research", "pre-development",
or "product definition" bucket. If marketing is involved in
any of these tasks, try forming an alliance with them.

As for ensuring that context scenarios and other GDD knowledge
actually make it to the implementation phase, the first thing
to try is getting it officially into the process, as discussed
above. If that isn't immediately possible, then guerilla tactics
might be necessary. I'd try developing some provisional personas
based on available user info and running through some context
scenarios as a skunkworks, and then doing some triage on the use
cases to get them more in line what you believe user goals to be,
as per the "GDD and Legacy Systems" thread that was on the list a
while back.

Robert.

---

Robert Reimann
Manager, User Interface Design
Bose Design Center

Bose Corporation
The Mountain
Framingham, MA 01701

-----Original Message-----
From: John Vaughan [mailto:vaughan1 at optonline.net]
Sent: Friday, November 05, 2004 11:23 AM
To: Reimann, Robert; discuss at interactiondesigners.com
Subject: Re: [ID Discuss] Use Cases and Personas

...

So here's my dilemma:

In my experience, the "standard" IT environment embraces the "key-path"
scenario (usually calling it a "Use Case"). The Use Case is
well-integrated, respected and accepted as an integral part of the IT Dev
Process.

In my experience, the "standard" IT environment DOES NOT embrace the
"context" scenario. Goal Directed Design (or whatever we choose to call it)

is generally NOT integrated, respected and accepted as an integral part of
the IT Dev Process. The design is weaker as a result - of course.

Given this assumption (and such is my experience)

1) How do we evolve the "standard" IT Dev Process so as to ensure that this
valuable GDD information is captured in the first place?

2) How do we ensure that the GDD info is actually implemented?

If you're already in a working environment that has the strategic vision to
do GDD, cool. I'm trying to come up with tactics for getting less the
enlightened workplaces (which are the majority of the IT shops, I'm sorry to

say) up to that level.

5 Nov 2004 - 4:18pm
Listera
2004

John Vaughan:

> I agree. Of course. But have you ever, ever, EVER seen a bureaucrat (or
> anyone, else, for that matter) voluntarily give up power to an unknown
> entity who's below them on the org chart?

I don't expect them to. But, really, they are not the ones who'll decide the
direction, their bosses will.

> Do you know many(any?) IxD professionals who swing that kind of swat?

I'm usually brought into a project *over* these bureaucrats. Why? Because
they've already failed. I won't take on a sizeable project unless the
IA/UI/UX part belongs to me/design team and not the IT. I speak the language
of business (heck I live across the New York Stock Exchange :-) and
development, and that helps. Nobody's going to BS me. My advantage is that I
do IA/UI/UX surgery, so the organization already understands they need
better.

> Actually, this makes a fairly compelling argument for maintaining IxD as an
> outsourced service - and, as it happens, I'm a believer.

Hallelujah. Now you're talkin'.

> In the meantime / in the real world, it seems that most of the immediate work
> opportunities are to serve as the token humanist in a geek-centric world. so
> how do we pull it off gracefully? Thereby convincing them to do what you
> suggest...

Fight. Yes, this carries risk. Yes, you'll hear people say that's reality.
Etc. But if designers don't fight for their own future, who will? Do you
want to spend the rest of your design life as an appendage to the IT dept?

Ziya
Nullius in Verba

5 Nov 2004 - 5:43pm
John Vaughan - ...
2004

Ziya said:
> I'm usually brought into a project *over* these bureaucrats. Why? Because
> they've already failed. I won't take on a sizeable project unless the
> IA/UI/UX part belongs to me/design team and not the IT. I speak the
> language
> of business (heck I live across the New York Stock Exchange :-) and
> development, and that helps. Nobody's going to BS me. My advantage is that
> I
> do IA/UI/UX surgery, so the organization already understands they need
> better.

Lucky you. I'm sure that we all view ourselves as having close to the same
skillsets & aspirations, but I don't happen to assume that my inflated
self-image necessarily drives corporate policy. BTW: The image of an IxD
"surgeon" hip-deep in the blood & shit of the standard IT abbatoire is just
too-too "Nip/Tuck". Thanks for providing a vivid image - and a hearty
chuckle.

Here's the $64 question:
Do you get to be "*over* these bureaucrats" because of your subtle
negotiating skills? or because "the organization already understands they
need better"? ( i.e. serendipity, driven by the fortuitous intercession of
enlightenment coming from further up the food chain). Heck, IT's been
failing miserably at doing decent UI for decades. No news there. The winds
of change don't come from within. So - We just hang in there and hope for a
change in upper management...?

5 Nov 2004 - 5:48pm
Dave Malouf
2005

> Here's the $64 question:
> Do you get to be "*over* these bureaucrats" because of your
> subtle negotiating skills? or because "the organization
> already understands they need better"? ( i.e. serendipity,
> driven by the fortuitous intercession of enlightenment coming
> from further up the food chain). Heck, IT's been failing
> miserably at doing decent UI for decades. No news there.
> The winds of change don't come from within. So - We just
> hang in there and hope for a change in upper management...?

I think John is asking, how do you get the chance to be hired from the
outside, if there aren't people inside already figuring out that they need
you? Who are these people? Who are the people driving change inside the
organization? (If not, then that is my own question I'm projecting onto
John.)

I believe that it's the insider designers that have the best opportunity for
doing just that. It is slow and it is hard, but through persuasion (isn't
that what designers are supposed to do best) and patience change does occur.

-- dave

5 Nov 2004 - 6:24pm
Listera
2004

John Vaughan:

> ...my inflated self-image

Thanks for the compliment but this is not an ego issue, it's a very
practical problem. They have already tried in-house and other
consultants/firms. So they understand they need a different direction. I
bring a sharp focus from three vantage points: business, design and
development. I've done them separately and together for nearly two decades.
Once you integrate/interrelate those three, solutions begin to appear where
wrong directions had been taken because they were dealt with separately by
separate, often competing teams.

> The image of an IxD "surgeon" hip-deep in the blood

Yes, I literally announce myself as "IA/UI/UX surgeon" at the beginning of
most every project. In the project I delivered just a few hours ago, I did
just that at the start. One of the directors, a sophisticated lady with a
fabulous pair of eyeglasses, rolled her eyes (and probably chuckled inside
too and I'm used to the look.:-) Today after I delivered it, she came up to
me to thank me personally and say how amused she was by my self-description
at the beginning but how she understood what I meant. She had seen 3-4
iterations of this app and virtually had given up.

> Do you get to be "*over* these bureaucrats" because of your subtle
> negotiating skills?

There's nothing subtle about me.:-)

> or because "the organization already understands they need better"? ( i.e.
> serendipity, driven by the fortuitous intercession of enlightenment coming
> from further up the food chain).

Yes, usually people upstairs had had enough of the IT foibles so they are
looking for better. Some upper management is design averse. Don't waste your
time with those.

> The winds of change don't come from within.

Sometimes it happens.

> So - We just hang in there and hope for a change in upper management...?

I'm sure there are better in-house politics strategists here than I.

Ziya
Nullius in Verba

5 Nov 2004 - 8:26pm
John Vaughan - ...
2004

Ziya:

>> ...my inflated self-image
>
> Thanks for the compliment but this is not an ego issue, it's a very
> practical problem.

Wasn't intending to characterize it primarily as an ego issue (tho, if the
shoe fits, etc.) In fact, I regard it as a truism. IxD professionals are -
by definition - the "slash" polymorphs of the IT development shop:
business/design/tech (ditto, Ziya). We are high level integrators, tho our
unique combination of skills is rarely well-supported (by budget or by
organizational structure or by process) in the standard IT environment.
Ziya's evidently got such a gig now, but only because upper management
stepped in to change the structure. Good on you, Ziya - I envy your
arrangement and hope the same will happen for the rest of us. Towards that
end I'd like to help MAKE another miracle happen, if I can.

I think any of us would LEAP at the opportunity to enjoy the degree of
autonomy that Ziya has now. But - unless I'm terribly out of touch with
reality - that's nowhere near the norm. I will occasionally walk away from
an egregiously abusive working environment, but the "standard" IT situation
is still pretty much as I described it.

Dave Heller captured the essence of my ongoing question, which I'll amend
slightly here:
"How do you get the chance to be placed in * a position of appropriate
authority, with appropriate resources and appropriate autonomy *, if there
aren't people inside already who are willing to " restructure the existing
system so as to cut you that turf *?"

Ziya, you're clearly a bright person in an exceptional position. I'd like
to hear a little more thoughful analysis than "Sometimes it happens."

> Yes, I literally announce myself as "IA/UI/UX surgeon" at the beginning of
> most every project.

And it provides so many opportunities for extending the metaphor:
implementation "triage", a website "facelift", data "lipsuction" ...
Loooooove it.

BTW: When asked, "What exactly is it you do?", One of my recent favorites is
to describe myself as "Queer Eye for the Website". And that's a
serendipitous segue to George Olsen's proposal for "Trading Sites" (Re: [ID
Discuss] Experience design vs. interaction design)...

JV

5 Nov 2004 - 10:42pm
Listera
2004

John Vaughan:

> Good on you, Ziya - I envy your arrangement...

Just in case it's misunderstood I'm not in-house.

> Ziya, you're clearly a bright person in an exceptional position. I'd like
> to hear a little more thoughful analysis than "Sometimes it happens."

Greater opportunity and authority doesn't come without advocacy. Advocacy
entails risk-taking (of your reputation, career, job, relationships etc). So
you need to be mature enough in terms of experience, age, rank, confidence,
political acumen, etc to take the risk. That becomes a very personal issue
-- of what you're willing and able to do at a given moment in your career.

This is too general though, I might be able to address more specific
questions if more narrowly framed.

> And it provides so many opportunities for extending the metaphor:
> implementation "triage", a website "facelift", data "lipsuction" ...
> Loooooove it.

I actually use a lot of medical terms while explaining design strategy:
triage, stabilize, freeze, block, shock, dissect, reroute, stitch, monitor,
scan...

Ziya
Surgeon of Design :-)

6 Nov 2004 - 1:45am
John Vaughan - ...
2004

>> Good on you, Ziya - I envy your arrangement...
>
> Just in case it's misunderstood I'm not in-house.

And there you have it. "Are you an innie or are you an outie" is an ongoing
consideration for any IxD professional. I've been both, and it's certainly
easier to exercise autonomy (as well as an independent attitude) when you're
playing the "outie" role. My current line of questioning presumes more of an
in-house perspective, which is a slightly different set of challenges.

However conservative the conventional corporate IT environment may be,
they're now (sort of )on the verge of coming to grips with IxD. Will it be
by growing in-house staff or by booking out of house? Service bureau or
high level consultant or IT appendage contractor? Does IxD report to IT or
to Marketing or to Creative or to upper management? Or is it an independent
design leader? Does IxD include requirements gathering, documentation, QA,
online help, training, usability testing, graphics, CRM, etc.? Where does it
fit into the process? Does it have a role in defining the process? Does IxD
serve the Development team or lead it or guide it?

Interesting times...

8 Nov 2004 - 4:38am
Narey, Kevin
2004

Robert wrote:
>I also agree that it is not the job of designers to develop class
>models, UML diagrams, and other code-facing architectural models.

We've got our interview/persona-based use-cases/scenarios (both types) which
have fed into our finalised phase prototype....

So what do we as IxDers give as a project deliverable to developers to close
that gap in interpretation?

NB. I understand that the prototype has now been designed, developed and
presented to the developers, who have played a part in technically
validating the prototype and in some (most?) cases helped to build it.

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

8 Nov 2004 - 8:11pm
Listera
2004

Narey, Kevin:

> the developers, who have played a part in technically validating the prototype

Design prototype, generally speaking, should need no technical validation.
Its purpose is to illustrate functionality, not (technical) compliance.

Ziya
Nullius in Verba

10 Nov 2004 - 2:07am
kjnarey
2004

Ziya,
>Design prototype, generally speaking, should need no technical validation.
>Its purpose is to illustrate functionality, not (technical) compliance.

I'm trying to avoid 'general' here wherever possible. This could well be my
undoing, but hey I'll take the career risk ;).

I have to design in a highly complex legacy environment which is:

1. Very system mature (i.e. stick to what you know/resistance to change type
(for last 20 years) culture)
2. Design immature (design is still the visual communication "fluffy,
look-and-feel, user-stuff [append other stuff that gives an interaction
designer as much worth as a ten year old slice of lemon peel floating down
the Nile]")
3. Architecturally complex data (i.e. proverbial can of worms/Pandora's box
that creates systems design mayhem).

In this space, having the prototype technically validated is a necessity as
I could very easily (you'll have to take my word for it I guess) design a
UI/solve a problem that could cost potentially millions to
source/harness/model/replicate/reconstruct data in order to achieve the
user's goals. The business simply cannot afford to take that risk. I don't
and never will have a view of that data complexity. This technically
validated prototype is also an expectation setter to stakeholders - A
natural risk settler in anyone's book.

Kevin

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
ers.com]On Behalf Of Listera
Sent: 09 November 2004 01:11
To: discuss at interactiondesigners.com
Subject: Re: [ID Discuss] Use Cases and Personas

[Please voluntarily trim replies to include only relevant quoted material.]

Narey, Kevin:

> the developers, who have played a part in technically validating the
prototype

Design prototype, generally speaking, should need no technical validation.
Its purpose is to illustrate functionality, not (technical) compliance.

Ziya
Nullius in Verba

_______________________________________________
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 - 2:27am
Listera
2004

kjnarey:

It's hard to comment on your specific situation without details. But...

> I have to design in a highly complex legacy environment which is:

...may I suggest another approach to this, which I have encountered many
times over the years. Hopefully, it might be of some help to you.

One doesn't design a legacy system. One leaves the legacy system alone and
designs around it.

As long as there's data I/O, and very few legacy systems these days cannot
deal with text of one sort or another (ascii/tabbed/XML/etc), you can design
the system you want/users need and create a middle layer API that reroutes
the data to/from your legacy system. You get a modern, flexible,
useful/usable UI and the legacy system gets its data in the old fashion way,
often without even knowing that there's an intercepting API in the middle.

By coincidence, I'm about to start one such project for a very large Wall
Street financial company. They were at first worried about being led by
their legacy considerations and had a huge sigh of relief when I explained
and showed examples of how you get around that UI wise.

Don't let the developers dictate your UI. :-)

Ziya
I'm a Designer: I Solve Problems

9 Nov 2004 - 4:17am
Narey, Kevin
2004

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

Syndicate content Get the feed