--- In agile-usability@yahoogroups.com, "Rachel Powers"
<rachelpowers@c...> wrote:
> Does anbody have any great tips, resources, stories to share on the
> best ways to integrate User Experience Design into the Agile
> process?

If I have a "thing" this is it... but, information I have on the
subject is still pretty incomplete.  There's a section in Cockburn's
Crystal Clear on the subject
[http://www.amazon.com/exec/obidos/ASIN/0201699478/qid=1103090953/sr=2
-1/ref=pd_ka_b_2_1/002-3899669-1706466]  This paper, now a little
dated and containing a few typos describes combining usage centered
design and agile approaches:
http://www.abstractics.com/papers/AddingU-CDToAgileDevelopment.pdf
This presentation: http://ebe.cpsc.ucalgary.ca/ebe/attach?
page=Root.CASCON2004WS%2FJeff.ppt gives slides I use for a standard
presentation on this subject.  The slides suffer without the dialogue
behind them.  But, the basic gist is I've overlaid Jesse James
Garrett's very useful Elements of User Experience model on my agile
development lifecycle model.  The result is some guideance on the
type of UCD stuff to be doing at particular points of the agile
development lifecycle.
I'm currently working on more in print.  Watch this list for somee
self serving announcements when it's available.  At that time I'll be
looking for the opinions of the very smart people subscribing to this
list.

Please post any specific questions you have as you come across them.
Thanks for posting!

-Jeff

> I work for a large company that is considering switching
> from a waterfall method to Agile/SCRUM. Are there any particular
> books or Websites that you recommend to look at. The UED group
> consists of user researchers, interaction designers, visual
> designers and developers. Questions that I'd like to find input on
> include:
>
> How do you integrate user research in 4 week cycles? (market
> research, user research, interviews, ethnography, longitudinal
> studies, usability testing)
> When should UED be included in the overall plan? (currently UED is
> brought in at conception)
> What is the best way for a user-cetered development process to
> thrive while being "whole."
> What are the pros and cons of Agile for UED?
>
> I'm sure that there are other people on this list that have gone
> from a waterfall development cycle to Agile. Does anybody have any
> stories or best practices to share?
>
> Thanks,
>
> Rachel Powers
> UED lead
> San Francisco, CA

jeff:

Alistair wrote in a past message that you have documented some real examples
about this process
Any link?

Thanks
    Agustin

"Jeff Patton" <jpatton@...> escribió en el mensaje
news:cpoiji+m6q9@....


--- In agile-usability@yahoogroups.com, "Agustín
Villena"
<agustin.villena@g...> wrote:
> Hi!
>     Conantine & Loockwood proposes that tasks must be described
as "essetial
> use cases". Well... when I try to apply this format of use cases, I
was
> quickly involved in an endless loop of refining the redaction of
this use
> cases... Thinking about it, I realized that he problem is that I
really
> don't have a good understanding about when an esential use case is
good
> enough to begin the user interface design based on it

The essential use-case is a handy variation of a conventional use
case.  The two column format limits the use case to a discussion
between a single user and the system - ideal for considering the
user's interaction with the system.  The column headings "user
intention" and "system responsibility" suggest thinking about what
the user intends to do with the software rather than specific UI
solutions to the problem.  But, moving from the abstract nature of an
essential use case to UI design is an act of design.  The essential
use case indicates what the user intends to do - it's up to you to
determine what user interface might best help the user accomplish
their goals - and the system accomplish its responsibilities.

The EUC is only a small part of the picture though.  The EUC
describes, abstractly, the interactions.  The use case is executed by
a user role with a specific goal and operating from a specific
context of use.  Information about that role helps.

The EUC describes interactions for a user task.  I've found
clustering tasks by affinity [in a task model] helpful for finding
interaction contexts.  Task performed by like people at similar
points in time cluster close together.  This usually suggests a place
in the UI where several tasks might be performed.  Knowing the
interaction contexts lets you think about navigation from context to
context.

Constantine & other's approach using canonical components
[http://foruse.com/articles/abstract.htm] helps to bridge the gap
between a the EUC and a paper prototype.  Paper protyping [I like
Carolyn Synder's book on the subject] is critical for validating a
proposed user interface.  Try using the essential use case as a
script for validating the UI.

If I had a point in all this rambling it would be that the essential
use case doesn't stand alone.  You need all the models from usage
centered design to help, along with lots of other techniques worth
borrowing from other UCD approaches.  The Cooper people talk
about "jumping the spark gap."  Basically crossing from the essential
use case and all the other models you prepare to an appropriate user
interface is a jump - like a spark crossing a spark gap in a spark
plug.  You need a concise useful set of models expressing your
understanding of the user, their goals, context of use and tasks to
help close that gap - make the jumping easier.

Have you combined the essential use case with some of these other
techniques?  If you're interested in working through a specific
situation, consider posting an essential use case here.  I and the
group might likely be able to ask you questions to fill in the
context needed to suggest appropriate user interface.

Thanks for your post,

-Jeff

>     Well, is the "esential use cases" the only way to map tasks to
UI
>
> Any advice?
>
>     Agustin







Yahoo! Groups Links

Rachel,

Lisa Baker and I have been working to integrate many aspects of UCD with
an XP process for the last couple of years at our company.  We make a
shrink-wrapped product, and have a fairly short release cycle.

We have found the personae concept to resonate fairly well with our
developers.  We do a fair amount of research (somewhat asynchronously)
with our users to find out what they have in common.  We use contextual
inquiry to get the data and to make sure we have a firm grasp of what
our user truly needs.
Once we have the data in place, we can refer to it as the personae are
created.  We work diligently to make sure we present information that we
have data concerning.  The personae are then presented to the
programmers at the start of the project, focusing on the aspects that
help them understand.

This has also helped our marketing team understand their role a bit
better as customer representative and helped the contribute in a more
meaningful way as well.  Since at times we can't always get one of real
customers to supply answers, we can always come back to our data set
from the CI and refer to that.

david broschinsky
sr. interaction designer
landesk software, inc.

daveb at startide dot net, david dot broschinsky at landesk dot com

Rachel Powers wrote:

>
>Does anbody have any great tips, resources, stories to share on the
>best ways to integrate User Experience Design into the Agile
>process?
>

Hi -- especially those of you in Europe may be interested in ROOTS
2005 -- we have a useability track and Agile methods tutorials as
well as Linda Rising doing a Retrospectives tutorial -- roots.dnd.no
cheers, Cecilia

**official announcement**

Beginning Monday, December 20th the ROOTS website is fully launched
with the new look and early registration.  We hope all of you will
visit before and during the holidays and begin to plan your
participation in April.

Another important feature is the ability to register early and
change your selections right up to the day of the conference.  You
can even cancel with no penalties until March 11th.  So let us know
early what program elements you like best, you can always change
your mind. <<The first 20 paid registrants will receive a free ROOTS
T-shirt with the new logo.>>

After 5 successful years, the ROOTS organizing committee is looking
forward to our best event ever!  We continue our tradition of
bringing in world-class experts; this year in the fields of
security, testing and useability. Some of the speakers have
presented in past ROOTS events, but there will be many new faces and
new points-of-view at ROOTS 2005.

We look forward to hearing from you soon and seeing you in April.

I've heard about this before but wasn't sure it was real or just an
urban myth!

The UIML spec is available at: http://www.uiml.org/index.php

Seems the core is centered around: <!ELEMENT interface
(structure|style|content|behavior)*>

"The <structure> element enumerates a set of interface parts and their
organization for various platforms.

The <style> element defines the values of various properties associated
with interface parts (analogous to style sheets for HTML).

The <content> element gives the words, sounds, and images associated
with interface parts to facilitate internationalization or
customization of UIs to various user groups (e.g., by job role).

The <behavior> element defines what UI events should be acted on and
what should be done."

Some examples of UIML and resulting UI are here:
http://lumumba.luc.ac.be/~kris/projects/uiml.net/examples/


/bill pawlak


--- acockburn@... wrote:

> I haven't read this but the title caught my eye
> _Introduction  to the User Interface Markup Language_
> (http://www.stsc.hill.af.mil/crosstalk/2005/01/0501Shuster.html)
>




__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail

The UCD people on the list might have heard of Holtzblatt & Wood's
new Rapid Contextual Design.  Can anyone comment on it?

Is it just fast?  Or can we look at it as an agilization of
Contextual Design - by that I mean it deals with strategies for
incremental release and iterative development specifically.

thanks,

-Jeff

It's been a slow few weeks on this list - not much discussion.  But,
oddly, the number of joiners continues to be steady.  There are a lot
of people wanting to better understand how usability and UCD
practices work in an agile environment.  For those new people just
getting on to the list, please consider asking questions.  There are
lots of folks on the list engaged in usability/ucd stuff in agile
environments.  There are lots of folks proficient in this agile stuff
who can answer questions.

I get to read the tag lines of people who join.  [Thanks to those who
joined patient enough to fill them in - helps keep out the
spammers.]  The top reason folks put down is wanting to understand
how UCD/usability practices work in an agile environment.  Some of
you may have seen me present my short powerpoint deck on how I think
this works.  Well, in the spirit of turning "a sandwich into a
banquet" I've started writing around this subject.  I've got a
proposed table of contexts and 3 chapters for a book available to
look at.  In the first chapters I explain agility simply, the second
explains UCD - stealing Garrett's UE model, the third merges the
model and gives guidelines on what activities to do when in an agile
environment.

toc: http://www.abstractics.com/book-proposal/tableOfContents.pdf
chapter 1: http://www.abstractics.com/book-proposal/1-
AgileDevelopment.pdf
chapter 2: http://www.abstractics.com/book-proposal/2-UCD.pdf
chapter 3: http://www.abstractics.com/book-proposal/3-Threading.pdf

For those with a bit of time on their hands, I'd appreciate your
feedback, on or off the list.

For those with a different mental model of how this works, I'd love
to hear how it that - on or off list.

For those wondering how to merge agility and UCD, you've got my
complete take on this in these chapters.  Read them and form your own
opinion.

There's more work to come.  I'll get a website up with a chapters
available for download as they're available.

Thanks all.

-Jeff

It's been a slow few weeks on this list - not much discussion.  But,
oddly, the number of joiners continues to be steady.  There are a lot
of people wanting to better understand how usability and UCD
practices work in an agile environment.  For those new people just
getting on to the list, please consider asking questions.  There are
lots of folks on the list engaged in usability/ucd stuff in agile
environments.  There are lots of folks proficient in this agile stuff
who can answer questions.

I get to read the tag lines of people who join.  [Thanks to those who
joined patient enough to fill them in - helps keep out the
spammers.]  The top reason folks put down is wanting to understand
how UCD/usability practices work in an agile environment.  Some of
you may have seen me present my short powerpoint deck on how I think
this works.  Well, in the spirit of turning "a sandwich into a
banquet" I've started writing around this subject.  I've got a
proposed table of contexts and 3 chapters for a book available to
look at.  In the first chapters I explain agility simply, the second
explains UCD - stealing Garrett's UE model, the third merges the
model and gives guidelines on what activities to do when in an agile
environment. 

toc: http://www.abstractics.com/book-proposal/tableOfContents.pdf
chapter 1: http://www.abstractics.com/book-proposal/1-
AgileDevelopment.pdf
chapter 2: http://www.abstractics.com/book-proposal/2-UCD.pdf
chapter 3: http://www.abstractics.com/book-proposal/3-Threading.pdf

For those with a bit of time on their hands, I'd appreciate your
feedback, on or off the list.

For those with a different mental model of how this works, I'd love
to hear how it that - on or off list.

For those wondering how to merge agility and UCD, you've got my
complete take on this in these chapters.  Read them and form your own
opinion.

There's more work to come.  I'll get a website up with a chapters
available for download as they're available.

Thanks all.

-Jeff 

I have never tried either CD or RCD, but I like what I read about it. I
particularly like the fact that they focus on studying and understanding
workpractices as opposed to "requirements". In other words, you first try to
REALLY, REALLY understand the work that people are currently doing that your
software will have to support or complement or fit with. THEN, and only THEN
do you start thinking about features and requirements.

One of the interesting things about this approach is that it seems more
generative. Once you understand the user's work, you can imagine all kinds
of new innovative ways that S/W could support that work, and then test those
ideas with the users.

Alain Désilets, MASc
Agent de recherches/Research Officer
Institut de technologie de l'information du CNRC /
NRC Institute for Information Technology

alain.desilets@...
Tél/Tel (613) 990-2813
Facsimile/télécopieur: (613) 952-7151

Conseil national de recherches Canada, M50, 1200 chemin Montréal,
Ottawa (Ontario) K1A 0R6
National Research Council Canada, M50, 1200 Montreal Rd., Ottawa, ON
K1A 0R6

Gouvernement du Canada | Government of Canada



-----Original Message-----
From: Jeff Patton [mailto:jpatton@...]
Sent: Monday, January 10, 2005 4:02 PM
To: agile-usability@yahoogroups.com
Subject: [agile-usability] Rapid Contextual Design?




The UCD people on the list might have heard of Holtzblatt & Wood's
new Rapid Contextual Design.  Can anyone comment on it?

Is it just fast?  Or can we look at it as an agilization of
Contextual Design - by that I mean it deals with strategies for
incremental release and iterative development specifically.

thanks,

-Jeff






Yahoo! Groups Links

We were one of the case studies for the book. We are using contextual
design more asynchronously, storing the data for future use.  This works
in our case - as a maker of retail software - because our "customer" is
more stable than trying to be build custom software.

What can be done to make contextual design more agile is the turnaround
on the prototypes.  One of the things we hope to accomplish is to move
our prototyping into the iteration cycle (well actually ahead of the
iteration cycle but on the same schedule).  This allows us to use cheap
paper and pen before we have the cost of code.  By having prototypes
available before hand, we are also able to make sure that tests are
written with the prototype in mind.

dave broschinsky
senior interaction designer
landesk software, inc.

The Methods & Tools newsletter has just released in its html archive
section "Agile, Multidisciplinary Teamwork" by Gautam Gosh

This article presents techniques and tools used to create
requirements with a team composed of the different participants of
agile projects.

http://www.methodsandtools.com/archive/archive.php?id=17

There's an interesting "history" of usability on the redhat magazine
site about how artisans gave way to mass production and usability:

http://www.redhat.com/magazine/002dec04/features/usability/#principles

I'm an agile developer, with interests in usability... and this
article jives very well with my personal happiness scale.

I had a job with a small company a few years back where the CEO and I
just found out what needed to be done and built software to solve his
business problems.  Since then, I've experienced varying degrees of
"agility/formality" and "usability/lack thereof"... but none compares
to interacting daily and one-on-one with the people for whom you are
building the software.

This "everything I needed to know about usability I learned in
small-company IT" attitude has served me well through the years.

I guess consumers have to choose whether they want the Orange County
Chopper or just a Honda.  I only know the assembly line's not for me.

---

From: dave broschinsky [mailto:daveb@...]
Sent: Tuesday, January 11, 2005 12:44 PM
To: agile-usability@yahoogroups.com
Subject: Re: [agile-usability] Rapid Contextual Design?

We were one of the case studies for the book. We are using contextual
design more asynchronously, storing the data for future use.  This works
in our case - as a maker of retail software - because our "customer" is
more stable than trying to be build custom software.

What can be done to make contextual design more agile is the turnaround
on the prototypes.  One of the things we hope to accomplish is to move
our prototyping into the iteration cycle (well actually ahead of the
iteration cycle but on the same schedule).  This allows us to use cheap
paper and pen before we have the cost of code.  By having prototypes
available before hand, we are also able to make sure that tests are
written with the prototype in mind.

dave broschinsky
senior interaction designer
landesk software, inc.

 

Hey guys -- I was reading old notes to this list and had a sudden news flash
which is maybe obvious to everyone else, but maybe not -- what I realized is
that being a usability person on an agile product is going to require a
total change in your thinking. Presumably, you're there to help implement
the customer role--be the customer voice on the team. But that's going to
require that you behave not as a usability person, looking at a completed
design and searching for holes but that you operate as a
designer--conceptualizing the work of the users, thinking about a design
response and organizing that response into screens and interfaces.

Usability people have known from just about day one that they had to do such
things, of course. But the placement of usability after development produces
something to test meant that the problem was somewhat hidden. Now it's out
front--you aren't a usability person anymore, you're something else.

Or am I out to lunch?

	 Hugh



Hugh R. Beyer
CTO, InContext
2352 Main St., suite 302
Concord, MA  01742

978-823-0105 x122
beyer@...

---

From: Jeff Patton [mailto:jpatton@...]
Sent: Monday, January 10, 2005 4:02 PM
To: agile-usability@yahoogroups.com
Subject: [agile-usability] Rapid Contextual Design?

The UCD people on the list might have heard of Holtzblatt & Wood's
new Rapid Contextual Design.  Can anyone comment on it? 

Is it just fast?  Or can we look at it as an agilization of
Contextual Design - by that I mean it deals with strategies for
incremental release and iterative development specifically.

thanks,

-Jeff

---

From: Desilets, Alain [mailto:alain.desilets@...]
Sent: Tuesday, January 11, 2005 8:50 AM
To: 'agile-usability@yahoogroups.com'
Subject: RE: [agile-usability] Rapid Contextual Design?

I have never tried either CD or RCD, but I like what I read about it. I
particularly like the fact that they focus on studying and understanding
workpractices as opposed to "requirements". In other words, you first try to
REALLY, REALLY understand the work that people are currently doing that your
software will have to support or complement or fit with. THEN, and only THEN
do you start thinking about features and requirements.

One of the interesting things about this approach is that it seems more
generative. Once you understand the user's work, you can imagine all kinds
of new innovative ways that S/W could support that work, and then test those
ideas with the users. 

 

--- In agile-usability@yahoogroups.com, "Hugh Beyer" <beyer@i...> wrote:
> Usability people have known from just about day one that they had to
do such
> things, of course. But the placement of usability after development
produces
> something to test meant that the problem was somewhat hidden. Now
it's out
> front--you aren't a usability person anymore, you're something else.

It all depends what you mean by usability person.

To some, a usability person is just the really annoying person who
comes in after development is done (or almost done), runs some tests,
and then shakes his finger at you saying that you need to change this,
this and that when it's too late to do so.

Often times, the placement of usability after development is a result
of the management team and possibly the development team who naively
just want some to come in and "do usability" without understanding
what that really means.

In my view, a usability person should be involved throughout the
process.  Ideally, the usability person should be a key participant in
the initial formulation of a project, starting with helping to collect
initial data from users and then helping to formulate a complete
solution (including an interaction design).

What usability folks really do and how they are seen can dramatically
vary from person to person.  Some really do concentrate solely on the
late end testing.  Some primarily work early in the process
(ethnographic research and/or interaction design).  Others work
throughout the development process.

Ron

> It all depends what you mean by usability person.
>

Yeah, usability can be at least two things: 1) design and 2) testing. It
requires completely different skills and attitude. I can admit that I'm
a terrible usability tester, but I've had some success in the design
arena. Most people either suck or are average trying to do both. There
are some exceptions, but they are so called big stars and may still have
more reputation than skill :)

> To some, a usability person is just the really annoying person who
> comes in after development is done (or almost done), runs some tests,
> and then shakes his finger at you saying that you need to change this,
> this and that when it's too late to do so.


Yeah, the information ice age.

> In my view, a usability person should be involved throughout the
> process.  Ideally, the usability person should be a key participant in
> the initial formulation of a project, starting with helping to collect
> initial data from users and then helping to formulate a complete
> solution (including an interaction design).
>

Your view is shared by, I believe, most people who want to create more
useful software.

We involve design people in the team, and usability testing is conducted
by outsiders. They test our paper prototypes and "dummy" screen shot
implementations and either approve or disapprove the test. Usually all
the major problems and tweaks are found with just one usability test
iteration. This happens before any coding starts, and costs maybe 10-15
% of the whole budget.

> What usability folks really do and how they are seen can dramatically
> vary from person to person.  Some really do concentrate solely on the
> late end testing.  Some primarily work early in the process
> (ethnographic research and/or interaction design).  Others work
> throughout the development process.


Good observation. I can confirm this from my own experience.

Best,
Petteri

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

  "I know what I believe. I will continue to believe
   what I believe and what I believe - I believe what
   I believe is right."

   - George W. Bush

Call for Participation - Agile 2005
July 24-29, 2005. Marriott Hotel, Denver, Colorado, USA.
http://www.agile2005.org

March 1: Submissions due for Tutorials and Workshops

March 15: Submissions due for Research Papers, Experience Reports, and
Educators' Symposium

Agile 2005 integrates the best features of the Agile Development Conference
and XP Agile Universe to create an exciting conference about techniques and
technologies, attitudes and policies, research and experience, and the
management and development sides of agile software development. The agile
approach focuses on delivering business value early in the project lifetime
and being able to incorporate late-breaking requirements changes. It
accentuates the use of rich, informal communication channels and frequent
delivery of running, tested systems, while attending to the human component
of software development.

Agile 2005 gives attendees access to the latest thinking in this domain, and
bridges communities that rarely get a proper chance to exchange ideas and
thoughts. It brings together researchers from labs and academia with
executives, managers, and developers in the trenches of software
development. Agile 2005 is not about a single methodology or approach, but
rather provides a forum for the exchange of information regarding all agile
development technologies.

We invite submissions for the following:
- Research Papers
- Experience Reports
- Tutorials
- Workshops / Peer to Peer Sessions
- Educators' Symposium

Other conference activities include:
- Introduction to Agile (for Agile "newbies")
- Executive Summit
- Open Space


FOR MORE INFORMATION: http://www.agile2005.org


--
    Bill Wake  William.Wake@...  www.xp123.com

--- Hugh Beyer <beyer@...> wrote:

...
> require that you behave not as a usability person, looking at a completed
> design and searching for holes but that you operate as a
> designer--conceptualizing the work of the users, thinking about a design
> response and organizing that response into screens and interfaces.

I'm really surprised to see you putting it that way, but perhaps I'm missing
something.  I never
perceived contextual design as requiring one start with a completed design.  It
often works that
way because so many projects wait until after they've done an amateur design
before bringing in
professional usability people.  Is it just that so many of your clients operate
in that mode that
you've started taking it for granted?  Or am I misunderstanding you?

Gary

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

--- In agile-usability@yahoogroups.com, Hugh Beyer <beyer@i...> wrote:
>
> What got me was realizing that as soon as you become part of an agile
> customer team, you're really not a usability person at all anymore. Your
> training may well give you a powerful mindset, but your role is to
be the
> customer voice.

Possibly being a little nitpicky here, but I don't agree that a
"usability person" should have the role of being the "customer's
voice."  The customer and the user aren't the same thing.  The
customer is the fellow buying the system, but the user is the poor
sucker who has to use it, and the two often aren't the same person.
The "usability person" has to know about the customer and her
needs/position/motivation, but the user is the one the "usability
person" represents.

Even if the customer and the user are the same person, being the
"user's voice" is a rather risky proposition.  I see usability people
as user *advocates* who have a deep understanding of the users and
push for things on their behalf but also know that, in the end, the
only person who can speak for the user properly is the user himself.
Thus, the importance of having real users involved in the process if
possible.

>And that requires a deep understanding of the user's work
> practice, of rational design, and also of usability issues.
Usability folks
> who walk into this role without realizing this are likely to be
surprised.

I believe that most usability folks who are really involved throughout
the entire process (rather than tacked on at the end), *will* know
that the need to understand the user's work practice and usability
issues.

Whether or not they also need to be good interaction designers depends
on the person and team make up (more usability and design mature
organizations usually separate the interaction design and
usability/human factors roles (and then pair two+ people on the same
team).  Whether or not a "usability person" can be a good interaction
designer is also in considerable doubt by some very vocal interaction
designers.

Ron

> more usability and design mature
> organizations usually separate the interaction design and
> usability/human factors roles (and then pair two+ people on the
> same team).

In the standard MRD/PRD world, I would agree. But are there people doing this in
the agile world? It seems in the agile world they're sort of still trying to
figure out where HF/usability/interaction design fits period...much less having
two + people with complementary skill sets assigned to a team.

Lisa

________________________________

From: Ron Vutpakdi [mailto:vutpakdi@...]
Sent: Wed 1/26/2005 1:53 PM
To: agile-usability@yahoogroups.com
Subject: [SPAM] - [agile-usability] Re: Role of UCD in agile processes - Email
found in subject



--- In agile-usability@yahoogroups.com, Hugh Beyer <beyer@i...> wrote:
>
> What got me was realizing that as soon as you become part of an agile
> customer team, you're really not a usability person at all anymore. Your
> training may well give you a powerful mindset, but your role is to
be the
> customer voice.

Possibly being a little nitpicky here, but I don't agree that a
"usability person" should have the role of being the "customer's
voice."  The customer and the user aren't the same thing.  The
customer is the fellow buying the system, but the user is the poor
sucker who has to use it, and the two often aren't the same person.
The "usability person" has to know about the customer and her
needs/position/motivation, but the user is the one the "usability
person" represents.

Even if the customer and the user are the same person, being the
"user's voice" is a rather risky proposition.  I see usability people
as user *advocates* who have a deep understanding of the users and
push for things on their behalf but also know that, in the end, the
only person who can speak for the user properly is the user himself.
Thus, the importance of having real users involved in the process if
possible.

>And that requires a deep understanding of the user's work
> practice, of rational design, and also of usability issues.
Usability folks
> who walk into this role without realizing this are likely to be
surprised.

I believe that most usability folks who are really involved throughout
the entire process (rather than tacked on at the end), *will* know
that the need to understand the user's work practice and usability
issues.

Whether or not they also need to be good interaction designers depends
on the person and team make up (more usability and design mature
organizations usually separate the interaction design and
usability/human factors roles (and then pair two+ people on the same
team).  Whether or not a "usability person" can be a good interaction
designer is also in considerable doubt by some very vocal interaction
designers.

Ron





________________________________

Yahoo! Groups Links


* To visit your group on the web, go to:
	 http://groups.yahoo.com/group/agile-usability/

* To unsubscribe from this group, send an email to:
	 agile-usability-unsubscribe@yahoogroups.com
<mailto:agile-usability-unsubscribe@yahoogroups.com?subject=Unsubscribe>

* Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .



This email, and any files or previous email messages included with it, may
contain confidential and/or privileged material. If you are not the intended
recipient please contact the sender and delete all copies.