Agile User-Centered Design

24 Mar 2004 - 11:45am
10 years ago
27 replies
1258 reads
FelcanSmith, Mark
2004

Using [ID Discuss] Cooper Vs. Beck, as a springboard...

I'm in a development environment where an agile methodology is
being practiced. There is considerable interest in the
methodology; both in terms of how it differs from what was done
in the past, and can it be successful moving forward. The
company has relied in the past on outside agencies to provide a
user-centered design methodology.

The current project is kind of a blend of the two, agile and
ucd. However, the outside agency, the ucd practitioners are no
longer on the project and we've really just begun the pilot
development. They provided business requirements, style guides,
wireframes, conducted some low-level usability - which helped
solidify some of their design decisions.

I'm in the position now to lead the continuation of the ucd
effort moving forward with the pilot as well as into subsequent
releases. My concern is this: the agile methodology that is
being embraced seems to lack the necessary *big picture* vision
that I feel is required and is attainable w/ an ucd methodology.

I had an opportunity to speak w/ Martin Fowler, who along w/
Kent Black pretty much outlined what XP (extreme programming)
is...about whether UCD and an agile methodology could co-exist -
and if so, given the overlap, how. One of the most interesting
comments he made was this, it seemed to him that the interaction
designer was super focused on getting the interaction spec
settled upfront, where as the agile developer is content with
letting this grow organically over the course of the project.

That really struck a chord w/ me. That's been one of my main
concerns is the feeling that we don't have all the required
interactions figured out - and there are developers coding. In
my experience, having developers coding before there was
sufficient design to spec out *what* they should be coding has
led to products being produced that miss their mark in many
ways; the balance between usable and useful, a cohesive user
experience, consistent interactions, and consideration of users
expected behaviors.

Question:
The long intro really gets me to this question: can both
user-centered design and agile (XP) methodologies co-exist in
the same development environment. And if so, how does this
co-existence look (and feel). What are the expectations when
there are obvious differences in the methodologies? e.g. having
a cohesive, clear definition of the interactions *before*
starting coding vs. seat-of-the-pants, make-it-up-as-you-go
development.

I've been struggling with this for a couple months now, and am
thinking that perhaps my view of the ucd methodology needs to
change, particularly if I'm going to stay on this project. The
agile approach isn't going away any time soon, and I've already
got buy-in for ucd from management - the issue is how do they
fit together. I sit now looking at an agile user-centered design
approach.

FYI - there are advanced topics and tutorials on this issue at
the UPA 2004 conference:
http://www.upassoc.org/conferences_and_events/upa_conference/2004/program/Tutorials_ALL.html

--
Mark FelcanSmith
mfs at ureach.com

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
ers.com]On Behalf Of Sarah Brodwall
Sent: Wednesday, March 24, 2004 3:31 AM
To: discuss at interactiondesigners.com
Subject: [ID Discuss] Cooper Vs. Beck

I'm not sure if this article has been discussed here before, but
I would
very much like to hear your opinions on
http://www.fawcette.com/interviews/beck_cooper/ (see also
http://c2.com/cgi/wiki?CooperVsBeck).

I'm studying interaction design with a focus on IA, while my
husband is an
outspoken proponent of agile software development methods.
Probably
because of my husband's influence, I find myself agreeing with a
lot of
what Beck has to say here, while Cooper comes off as being
somewhat out of
touch with the realities of software development. Have any of
you ever
worked as interaction designers on a development team using
agile
methodologies? Do any of you come to the field of interaction
design from
software development? I'd really like to hear what you have to
say about
this article.

--
Sarah Brodwall Time you enjoy wasting is not
sjb at broadpark.no wasted time. ~T. S. Eliot

Comments

24 Mar 2004 - 12:35pm
Rob Adams
2004

On 3/24/04 11:45 AM, "Mark FelcanSmith" <mfs at ureach.com> wrote:

> Question:
> The long intro really gets me to this question: can both
> user-centered design and agile (XP) methodologies co-exist in
> the same development environment. And if so, how does this
> co-existence look (and feel). What are the expectations when
> there are obvious differences in the methodologies? e.g. having
> a cohesive, clear definition of the interactions *before*
> starting coding vs. seat-of-the-pants, make-it-up-as-you-go
> development.
>
> I've been struggling with this for a couple months now, and am
> thinking that perhaps my view of the ucd methodology needs to
> change, particularly if I'm going to stay on this project. The
> agile approach isn't going away any time soon, and I've already
> got buy-in for ucd from management - the issue is how do they
> fit together. I sit now looking at an agile user-centered design
> approach.

I've recorded a few thoughts on how such a process might work here:
http://www.lokislabs.org/~loki/weblog/archives/2003/08/22/extreme_usability.
php
Has anyone actually run or contributed to a project that used a "mixed"
agile/ucd methodology? I've never come across any case studies on such an
approach; I've found design/usability people talk about UCD processes and
software people talk about agile processes, and never the twain shall meet.
But maybe there's some great story out there I just haven't come across yet?

-- Rob
http://www.lokislabs.org/~loki/
http://roblog.org/

24 Mar 2004 - 1:17pm
Todd Warfel
2003

[warning - this is a bit long]

It could only work if both parties finally realize that both of their
deliverables are LIVING ARTIFACTS. This is the thing that's missing in
the ID vs. XP argument. We can't expect that all the interactions are
locked down, forever. And we can't expect that the code "evolving" over
time based on the guidance of the customer (business owner - wrong
customer) will produce a healthy product. Those are two extremes. The
fact is, great products aren't about extremes, to the effect stated
above, they're about compromise and negotiation. And the faster we
(both design and engineering) realize this, the faster we'll be able to
really create killer products, instead of ones that are just "good."

I can't think of any significantly large project that we've ever worked
on where all of the interactions are defined and written in stone prior
to development starting, or being complete. We typically get 90- 95% of
it down, but then something changes - a deadline, the available
resources, some technology glitch, maybe some unexpected error message
we have to deal with. Then that requires one "small" change (in the
eyes of the stakeholders, or development team) to the interaction
models, which creates a waterfall effect. Pretty soon, that one "small"
change of 15 minutes, turns to two hours of updating interaction models
and wireframes - it can have a global impact.

Same thing with engineering. We need to make one "small" change, which
has a waterfall effect and that turns into several edits that globally
impact the product, even in object oriented and modular designs.

This is where our process model excels. We don't realistically expect
that all of our interaction models are written in stone prior to
development beginning. We expect to get 85-95% of them done before
development begins. We involve the engineers in the process early on to
make sure that we're making informed decisions about our interactions
and consider the constraints (not based on the constraints). We focus
on the global elements that have significant impact. Nail those down.
Then hand them off to development to get them started. As they go
through development, inevitably, we will get a few:

"Um, yeah, this won't work correctly because of [insert your favorite
constraint here], which we didn't anticipate."

To which we generally reply

"Okay. Let's see if we can adjust your code to make it work that way.
Every technology has strengths and weaknesses. So, develop to the
strengths around the weaknesses. Maybe we'll need to invent a new way
to do it that's never been done in this framework before (developers
tend to like a good challenge). And if we find that we can't do it,
due to some constraint, then let's adjust the interaction to get a
healthy compromise."

Sometimes we create a new way. Sometimes we compromise and adjust the
interaction model(s). In either of these cases, we both win, and more
importantly, so does the user and business. When we don't find a new
way, or compromise and the product just doesn't work, or include a
function the way it's expected, then we all lose. Sure, we save some
time now on engineering, but the long-term costs can be, and often are,
detrimental.

On Mar 24, 2004, at 12:35 PM, Rob Adams wrote:

> Has anyone actually run or contributed to a project that used a "mixed"
> agile/ucd methodology? I've never come across any case studies on
> such an
> approach; I've found design/usability people talk about UCD processes
> and
> software people talk about agile processes, and never the twain shall
> meet.
> But maybe there's some great story out there I just haven't come
> across yet?

Cheers!

Todd R. Warfel
User Experience Architect
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 4297 bytes
Desc: not available
Url : http://listserver.dreamhost.com/pipermail/discuss-interactiondesigners.com/attachments/20040324/af693ee1/attachment.bin

24 Mar 2004 - 2:40pm
Cindy Alvarez
2004

> In my experience, having developers coding before there was
> sufficient design to spec out *what* they should be coding has
> led to products being produced that miss their mark in many
> ways; the balance between usable and useful, a cohesive user
> experience, consistent interactions, and consideration of users
> expected behaviors.

The company I work for does not formally practice XP, although as a whole
our software development process is more or less a mixture of UCD and
revising through iterations.

What typically happens with us is that the core interactions - the tasks
without which the product would not be a valid product - are designed.
Then I run through an internal review with product managers, and tweak,
then run through casual or formal usability testing (depending on
time/budget/feature criticality), and tweak. I'd estimate that this
usually gets me 80-90% of the way there.

At that point I review HTML prototypes with engineering, who always have a
lot of feedback. Some ridiculous, some remarkably insightful, and some
raising new use cases. Another round of tweaking to the prototypes and
they start coding.

In the process of coding things come up. Maybe they wouldn't if I spent
longer on wireframing and testing, but I doubt it, honestly. Things come
up (if Cooper claims they don't, I don't believe him) and there are 2 ways
that we deal with this without creating a lot of chaos:

1) Interaction standards and interface standards
i.e. how are errors displayed, when are confirmation pages used, what
behaviors are done serially vs. in batch, how are columns aligned...

This allows me to focus on the new problem specifically without having to
worry that the new stuff will be inconsistent.

2) Shared understanding of product experience
This is similar to the "benevolent dictator" and design-by-committee
concept - basically, I try to be very open about why I make the design
calls that I do. Removing those links because the user is in a
task-centered mode here. Separating those steps because one is optional
and the other isn't.

The result - and I must say that I work with an exceptional team - is that
engineers will IM me and say "what do we do if X and Y happen? I would
guess you would want to do Z" and usually, they're pretty close.

That's a third thing, I guess - which is the need to work very closely
with engineering. I talk with my developers (whether stateside or abroad)
every day, and that means that there is a lot less chance for chaos to
build up.

Cindy Alvarez

24 Mar 2004 - 4:44pm
Rick Cecil
2004

All,

This conversation is really interesting. We are currently developing a
combined UCD/Agile methodology for our company. The most interesting thing
that I've found in reviewing different Agile methodologies is how
complementary it is to UCD. In fact, I would argue that more products would
be more successful if they used a combined approach.

Agile is seriously lacking when it comes to the design of the product
(design-on-the-fly, IMO, is not really design). And UCD doesn't address how
you go about developing the product--rather, it focuses on the work of the
UE team.

A combined approach, which I would still call UCD--hey, I'm biased,
recognizes that there are actually three systems that must be accounted for
in the development process: the user system, the organization (or business)
system, and the product system. For the project to succeed, you must
understand and account for all three systems.

You have the most control over how the product is created and no control
over your users. The business falls somewhere in between. (As a side note,
this seems to be one place where Cooper and Beck disagreed; Cooper wants us
to have more control over these business processes--and, to his point, when
you are able to design the business process, you do get a better product,
but the idea is still too revolutionary for most businesses. Beck, on the
other hand, wants to work within the existing business system and has
created a process that will account for two of the three systems (business
and product) but falls short of addressing user needs.)

Given that the project team has the most control over the product, it makes
the most sense, then to build the product such that the user has an easier
time using and understanding it--after all, you can't programmatically
increase the user's ability to use your system.

With all that said, Agile's emphasis on developing working sub-systems plays
right into UCD's goal of including the user early and often. What better way
to involve the user during development than to actually test working
sub-systems?

And if you add 1wk to 6mos or more at the beginning of the
project--depending on scope--for the user experience team to work with the
users and the stakeholders, then you get a workable UCD methodology.

A solid UCD process also means that user involvement continues after the
software or Web site has been released. The project team continues making
improvements by testing and interviewing users.

To that end, I have yet to see a software company take full advantage of the
Web and the UCD design approach. In exchange for paying more for a piece of
software, they could give users incremental updates that improve usability
and usefulness. So far, companies who release dot updates only release one
or two security or stability updates--and they provide these updates for
free. Never do these incremental updates improve workflow, UI, or features.

As Todd said, to implement this combined methodology, not only would all
project team members have to buy into the concept of Living Documents; and
they also have to understand that the product is also Living. Product
development should never end--even after it is released.

-Rick

24 Mar 2004 - 3:52pm
Jim McCusker
2004

Mark FelcanSmith wrote:

>Using [ID Discuss] Cooper Vs. Beck, as a springboard...
>
>Question:
>The long intro really gets me to this question: can both
>user-centered design and agile (XP) methodologies co-exist in
>the same development environment. And if so, how does this
>co-existence look (and feel). What are the expectations when
>there are obvious differences in the methodologies? e.g. having
>a cohesive, clear definition of the interactions *before*
>starting coding vs. seat-of-the-pants, make-it-up-as-you-go
>development.
>
>
When I saw this post I had to check twice to see if it was coming from
the Scrum list I subscribe to or the ID Discuss list. I was responsible
for getting both Scrum (an Agile SD process) and UCD introduced into the
company I work for. It turns out that for us, the two are rather
complementary. We use a spiral UCD design process, where each cycle is
done on a more complete version than the last. The progression is rough
paper mock up, PPT/diagram/HTML mock up, functional prototype, and then
the functional product. The idea is that heuristic analysis (we call
them design reviews) and usability testing can be done at each stage,
you just need to make sure you put the time in that's appropriate.

The idea here is to get the big concepts hammered out first, and then
get the details down later. A story/backlog item usually is only a
functional description of how this stuff works. The first step is on
paper on purpose, since it's a throwaway, and so it encourages the
designer to not worry about smaller details. Often those details will
simply appear when going through an informal test or review, since
people will ask questions, and those questions will reveal the user's
model. After the diagrammed phase, which is only incrementally more
detailed than the paper one, we create a live prototype, that partially
works. We can do this since the designers are also the developers, but
there's no reason a designer and developer can't pair program the design
into code. We can also do this cheaply because our UI architecture is
very flexible, and allows for adding new UI's very quickly.

From there, the details come into play. Should this have a pop up menu?
What should the formatting look like? How, exactly, should this dialog
stretch? Those are all things that the developer can do quickly, esp.
with feedback from the designer. Again, at the end of each design phase,
someone conducts a design review and usability test. When the system is
close enough to finished, we do a larger-scale usability test on the
(nearly) completed system, just to make sure that there aren't details
that we've missed. There shouldn't be any big surprises at this stage,
though, because you've already put versions of this thing in front of
users 3 times already.

Of course, there's the question of how this fits into an iteration.
Well, the best thing is if the whole thing start to finish fits in one
agility cycle (in Scrum, it's a sprint). But if you break it up into
doing the mock ups in one cycle, and the coding in the next, you also
allow for some feedback in between the cycles. Either way, it's very
compatible, and the hardest thing has been forcing myself and other
designer/developers to take the time for feedback, whether it's a design
review or usability test.

Jim

24 Mar 2004 - 5:40pm
Peter Bagnall
2003

Cindy Alvarez said...
> The result - and I must say that I work with an exceptional team - is
> that
> engineers will IM me and say "what do we do if X and Y happen? I would
> guess you would want to do Z" and usually, they're pretty close.

I think Cindy is hitting on something really important here. Many
interaction designers, and I suppose this is almost true by definition
for consulting designers, stop working on a project at the handover to
engineering point. But things do crop up after that point, and
sometimes other considerations mean that changes have to be made. So
designs change.

The important thing is that when the design changes those changes
should be made by someone who understands the design and the impact the
changes will have on the user, and that means a designer should approve
the changes in some way. I'm not talking about having a formal process;
really what I'm getting at is the engineering team needs a designer who
will stay with them throughout the life of the project. It sounds like
Cindy is that designer, and that her guidance is really helping the
developers she's working with.

Many people have suggested this, but my impression is that it's
somewhat rare that this happens in practice. Is there a sense on the
list as to how common this is?

This is also why I think for open design projects the rational behind
design decisions is what really matters. That's what allows another
designer to know who to make changes when changes are needed in a way
that stays true to the original concept.

--Pete

------------------------------------------------------------------------
------
Blood stains cannot be removed by more blood; resentment cannot
be removed by more resentment; resentment can be removed
only by forgetting it."
Buddha

Peter Bagnall - http://www.surfaceeffect.com/

25 Mar 2004 - 8:10am
CD Evans
2004

On 24 Mar 2004, at 22:40, Peter Bagnall wrote:

> The important thing is that when the design changes those changes
> should be made by someone who understands the design and the impact
> the changes will have on the user, and that means a designer should
> approve the changes in some way. I'm not talking about having a formal
> process; really what I'm getting at is the engineering team needs a
> designer who will stay with them throughout the life of the project.
> It sounds like Cindy is that designer, and that her guidance is really
> helping the developers she's working with.
>

Yes, this is key. Just as an architect answers many questions during
the construction phase, an Information Architect or Interaction
Designer should be referred to for both scope and detail, respectively.

We should think about a model for this that works alongside Agile, XP,
UCD and ED.

Perhaps it should be called something like Interactive Information
Planning?

CD Evans

24 Mar 2004 - 10:20pm
pabini
2004

In response to Pete Bagnall's question about interaction designers staying
involved in projects throughout development:

When I was at WebEx and my specifications required either additions or
modifications during development, the engineers were very good about
bringing issues to me. I also worked very closely with them during the
design phase to ensure that I understood engineering constraints.

I'm just starting a consultancy and wonder how well other interaction-design
consultants are able to keep a dialogue open with engineering during
development. To ensure a high-quality product, I think it's essential that
interaction designers remain actively involved in a project throughout
development. Are other consultants able to achieve this?

Pabini Gabriel-Petit
Spirit Softworks
www.spiritsoftworks.com

25 Mar 2004 - 10:00am
Robert Reimann
2003

The primary issue with "pure" agile/xp methods is
that they assume that design up front is impossible;
that you can't truly design software without building
something that "works" first (or to be more fair, perhaps
the assumption is really that a design's existence can't be
relied on).

However, as most of the participants in this group
know, this need not be the case. As Rick indicates below, a
"pre-development" phase consisting of research, user modeling,
requirements definition, and concept/framework definition can provide
the necessary starting point to launch an agile-like development
process in which developers and designers/usability folks
can work closely together to alternately refine the design and the
code through a series of design/code/test cycles. This should ideally
continue until the product is mfg-ready, as Peter B. has mentioned.
Difficult to manage as a design consultant (without giving your time
away or negotiating a retainer arrangement), but essential for an
in-house team.

The important point is that this latter process works much
better when there is a solid product definition and conceptual
framework already in place that has been signed off on by both
the business and engineering stakeholders.

And yes, this does almost demand changing business processes
at most companies, which I have come to believe is one of the
chief challenges of IxD and usability professionals-- but
certainly not an insurmountable one.

Robert.

---

Robert Reimann
Manager, User Interface Design
Bose Design Center

Bose Corporation
The Mountain
Framingham, MA 01701

-----Original Message-----
From: Rick Cecil [mailto:rick at hesketh.com]
Sent: Wednesday, March 24, 2004 4:44 PM
To: discuss at interactiondesigners.com
Subject: RE: [ID Discuss] Agile User-Centered Design

All,

This conversation is really interesting. We are currently developing a
combined UCD/Agile methodology for our company. The most interesting thing
that I've found in reviewing different Agile methodologies is how
complementary it is to UCD. In fact, I would argue that more products would
be more successful if they used a combined approach.

Agile is seriously lacking when it comes to the design of the product
(design-on-the-fly, IMO, is not really design). And UCD doesn't address how
you go about developing the product--rather, it focuses on the work of the
UE team.

A combined approach, which I would still call UCD--hey, I'm biased,
recognizes that there are actually three systems that must be accounted for
in the development process: the user system, the organization (or business)
system, and the product system. For the project to succeed, you must
understand and account for all three systems.

You have the most control over how the product is created and no control
over your users. The business falls somewhere in between. (As a side note,
this seems to be one place where Cooper and Beck disagreed; Cooper wants us
to have more control over these business processes--and, to his point, when
you are able to design the business process, you do get a better product,
but the idea is still too revolutionary for most businesses. Beck, on the
other hand, wants to work within the existing business system and has
created a process that will account for two of the three systems (business
and product) but falls short of addressing user needs.)

Given that the project team has the most control over the product, it makes
the most sense, then to build the product such that the user has an easier
time using and understanding it--after all, you can't programmatically
increase the user's ability to use your system.

With all that said, Agile's emphasis on developing working sub-systems plays
right into UCD's goal of including the user early and often. What better way
to involve the user during development than to actually test working
sub-systems?

And if you add 1wk to 6mos or more at the beginning of the
project--depending on scope--for the user experience team to work with the
users and the stakeholders, then you get a workable UCD methodology.

A solid UCD process also means that user involvement continues after the
software or Web site has been released. The project team continues making
improvements by testing and interviewing users.

To that end, I have yet to see a software company take full advantage of the
Web and the UCD design approach. In exchange for paying more for a piece of
software, they could give users incremental updates that improve usability
and usefulness. So far, companies who release dot updates only release one
or two security or stability updates--and they provide these updates for
free. Never do these incremental updates improve workflow, UI, or features.

As Todd said, to implement this combined methodology, not only would all
project team members have to buy into the concept of Living Documents; and
they also have to understand that the product is also Living. Product
development should never end--even after it is released.

-Rick

_______________________________________________
Interaction Design Discussion List discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

25 Mar 2004 - 10:11am
Dave Malouf
2005

I think robert hit something on the head here.

But I will put it a bit more directly.

There are many many other design/engineering disciplines that exist.

Do you make a building w/o a design up front?
Do you make a car w/o concept models?
Industrial designers as well have non-usable prototypes.

To me this speaks volumes of how important it is to have requirements before
building.

I think the problem statement is being addressed fairly; the problem is that
the problem statement "software development is inefficient" cannot be soley
answered by one role in the process. It is a full team effort and all the
teams have to figure out for their part how they can increase efficiency,
for their part and for the project's team.

Something that has come up for us is how do you define "latent" requirements
in an "agile" method. The best that you can do is translate articulated
requirements in this process. This is tautamont to doing what we fight so
hard to avoid ... Using wha the customer asks for as a starting point for
requirements.

The example I've been giving my team here is ...
Customers say, "I need a chair". They keep badgering us for a chair.
One simple perspective would be to keep building chairs, putting it in front
of the customer until it fulfills their needs. This is the Agile approach.

Our approach would be to go out and find out if even a chair answers the
real problem statement that the customer hasn't told us. The real problem
could be, "my feet hurt" ... Hmm? Why not better shoes? Or "I have a butt
w/o a home" ... Maybe a swing would be more practical than a chair (or is
that just a different type of chair?)

My point is that unless we envoke our processes of defining and researching
and analyzing, we will just be taking huge steps back.

Our questions should be; how can we do better to make the process more
efficient for getting to those latent requirements and what type of
prototyping can we do that would be easier to get the programmers going that
much quicker, better, and them working faster?

== dave

25 Mar 2004 - 11:33am
Peter Bagnall
2003

> Do you make a building w/o a design up front?
> Do you make a car w/o concept models?
> Industrial designers as well have non-usable prototypes.

I find it interesting that the answer to these rhetorical questions is
obvious to everyone. And yet it still appears to be non-obvious to many
in the software world.

Robert points out, quite rightly in my view, that this means changing
business processes. But I think there's something deeper. It requires
changing the view of software as something infinitely malleable. Alan
Cooper was talking about this problem a couple of years back, saying
how since planning is cheap and coding is expensive we should do more
of the former and (therefore) less of the latter. This is a message we
are still failing to get across, although progress is being made.

As for the process, it seems that a consensus in emerging on how agile
methodologies and design can work together. While agile without design
can produce something, with design they are even better. Maybe a better
way to tell this story would be to accept agile methods as being
popular within the developer community, since they protect them from
changes, but then add to that that a further layer of protection can be
gained by doing up front design and getting buy-in. The design can then
be kept from going astray (leading to fewer revs) by making a designer
available to the development team during the build. That doesn't seem
to be particularly revolutionary to me, I see no inherent contradiction
in the two processes.

Robert's other point about it being hard as a consultant to be
available to developers is a major problem I think. It means that IxD
doesn't get the respect it deserves, since it significantly reduces the
chances of a design being implemented correctly in the face of
engineering constraints that emerge later. Architects consult during
the build, so perhaps there are some tricks we could learn from them.

--Pete

------------------------------------------------------------------------
---
The wit makes fun of other persons; the satirist makes fun of the
world; the humorist makes fun of himself.
James Thurber

Peter Bagnall - http://people.surfaceeffect.com/pete/

25 Mar 2004 - 11:43am
Jim McCusker
2004

David Heller wrote:

> I think robert hit something on the head here.
>
> But I will put it a bit more directly.
>
> There are many many other design/engineering disciplines that exist.
>
> Do you make a building w/o a design up front?
> Do you make a car w/o concept models?
> Industrial designers as well have non-usable prototypes.
>
>
I think this is a bad analogy, especially the building one. When a
software project is done being designed, it's usually done. The idea of
agile software development is that the design is encoded in the user
stories, test cases, and the software itself. In an agile environment,
the idea is to do as little as possible for a project to work. Ideally,
the IxD becomes part of the agile process, in that the high level
ethnography and user modeling feed into the user stories, but from
there, the design happens hand-in-hand with the code. The designer
should work hand in hand with the backend architect and developers to
make sure that the user's needs are satisfied. While not all user
stories are created up front, likewise, not all interactions in a system
should be thought up up front. There is a learning process, and feedback
is essential. You do test your interaction models, right? One big part
of agile is the test-first methodology. That is, you develop the test
(in this case, the usability test) before coming up with the interaction
model. The designer can then send themselves (in the most lightweight
case), users or other people through the test as needed. This gives you
the same feedback that people get when they do test-first in development.

> To me this speaks volumes of how important it is to have requirements
> before
> building.
>
> I think the problem statement is being addressed fairly; the problem
> is that
> the problem statement "software development is inefficient" cannot be
> soley
> answered by one role in the process. It is a full team effort and all the
> teams have to figure out for their part how they can increase efficiency,
> for their part and for the project's team.
>
> Something that has come up for us is how do you define "latent"
> requirements
> in an "agile" method. The best that you can do is translate articulated
> requirements in this process. This is tautamont to doing what we fight so
> hard to avoid ... Using wha the customer asks for as a starting point for
> requirements.
>
> The example I've been giving my team here is ...
> Customers say, "I need a chair". They keep badgering us for a chair.
> One simple perspective would be to keep building chairs, putting it in
> front
> of the customer until it fulfills their needs. This is the Agile
> approach.
>
> Our approach would be to go out and find out if even a chair answers the
> real problem statement that the customer hasn't told us. The real problem
> could be, "my feet hurt" ... Hmm? Why not better shoes? Or "I have a butt
> w/o a home" ... Maybe a swing would be more practical than a chair (or is
> that just a different type of chair?)
>
>
I think you're missing the point about how ASD (agile software
development) works. You're leaving feedback out of the loop. It's not
all guesswork. It usually goes more like this:

The user asks for a chair. The developers ask the user how they might be
using the chair, how long they need to sit in it, how sturdy does it
need to be, etc. This is then put into a user story, and the developers
go ahead a create a preliminary chair. They don't spend a lot of time on
it, because they know that there's going to be something they missed. So
they bring it back to the user, and the user says: not bad, but it needs
arms, and a softer cushion. So the developers take the same chair
(remember, software is refactored, not rewritten from scratch) and add
arms and a softer cushion. This repeats until the customer is satisfied
with the chair.

So where does IxD and UCD come into this? Well, from the start, the
designer would know all sorts of additional questions to ask the user
about the chair, and know lots of ergonomic consequences of those
requests. They would know that if the user is sitting in the chair for a
long time, a firmer cushion is needed, etc. They would come up with some
preliminary designs for the developers to make the initial chair off of,
and then help the developers refine the design until it satisfies the user.

Jim

25 Mar 2004 - 11:50am
Jim McCusker
2004

Peter Bagnall wrote:

>> Do you make a building w/o a design up front?
>> Do you make a car w/o concept models?
>> Industrial designers as well have non-usable prototypes.
>
>
> I find it interesting that the answer to these rhetorical questions
> is obvious to everyone. And yet it still appears to be non-obvious to
> many in the software world.
>
> Robert points out, quite rightly in my view, that this means changing
> business processes. But I think there's something deeper. It requires
> changing the view of software as something infinitely malleable. Alan
> Cooper was talking about this problem a couple of years back, saying
> how since planning is cheap and coding is expensive we should do more
> of the former and (therefore) less of the latter. This is a message
> we are still failing to get across, although progress is being made.

I'm sorry, but planning is not cheap. Planning involves lots of time
from lots of people. You often have to get many people (usually
high-level and therefore highly paid) into a room for many hours. Even 4
hours of planning can cost $1000s. Coding is very cheap by comparison.
And requirements move. By the time you get everything nailed down, the
market or internal requirements has shifted, causing a need for more
planning. And then, if you ever do get to the coding phase, you have to
keep up with shifting requirements again. And if you're using 3rd party
software, more often than not you need to figure out how to work around
some of its limitations. Agile is set up so that you can respond to
those changes easily and quickly, while maintaining the sanity of
everyone involved. What Cooper is advocating is essentially a waterfall
methodology, which was discredited years ago, and only works when the
project exists in a vacuum, which it never does. Things change, you need
to respond, and there's no reason to nail down details before their
time, because the assumptions that were made to cause those details to
need to be thought about may change.

Jim

25 Mar 2004 - 11:51am
Dave Malouf
2005

I think there is a myth that I don't understand why developers want to
propagate which is the myth of the malability of code.

I'm sorry, code has so many issues of interropability that its structures
are just as fixed in many instances as a wall. Sure I can take down a wall,
but what about the beam that is going through it that has a stabalizing
effect for the structure as a whole.

I believe wholeheartedly in object-orient and componentized programming, but
my experience in working with huge code projects is that the structure
surrounding code makes code not so maleable. Some might chime in and say
this is poor architecture, but my experience w/ amazing engineers is that
when you reach a certain level of complexity in your application (when
application becomes platform for example) this all fall apart.

This is where design comes in. this is where the import of strong
requirements comes in.

The other aspect to this that feels like it is missing is the other side of
the development process. Where is QA? In Agile? You cannot leave testing to
those who coded it. QA is a vital component to a release process thus
perpetuating the "waterfall'.

That being said, we are working on a non-agile system here in my corp that
has a different problematic element.

The system is ... Design components, throw them in a bucket that the dev
team gets to when they can, then they throw it in their bucket and when QA
gets to it they get to it. Whatever is complete by a release date gets put
in the release.

My problem with this is that you loose a sense of designing for the whole
(that structure thing again.) It is rare that a new component has no effect
on components outside of itself.

I'd love to hear people's thoughts about wholistic vs. compartmentalized
approaches.

-- -- dave

25 Mar 2004 - 12:24pm
Jim McCusker
2004

David Heller wrote:

> I think there is a myth that I don't understand why developers want to
> propagate which is the myth of the malability of code.
>
> I'm sorry, code has so many issues of interropability that its structures
> are just as fixed in many instances as a wall. Sure I can take down a
> wall,
> but what about the beam that is going through it that has a stabalizing
> effect for the structure as a whole.
>
> I believe wholeheartedly in object-orient and componentized
> programming, but
> my experience in working with huge code projects is that the structure
> surrounding code makes code not so maleable. Some might chime in and say
> this is poor architecture, but my experience w/ amazing engineers is that
> when you reach a certain level of complexity in your application (when
> application becomes platform for example) this all fall apart.
>
>
The company that I work for develops middleware for parallel
supercomputing. We're a platform. And we have a very modular,
componentized system, which allows us to change direction very quickly.
For instance, it took us 1 man-month (spread out over 4 developers) to
embed our back end software into our development environment, after the
head of sales had the idea to do so. Architectures should be flexible,
not brittle, and there should be well-defined interaction points between
them. If there isn't, then there's something wrong with the design.

> This is where design comes in. this is where the import of strong
> requirements comes in.
>
>
Design, yes, strong requirements, yes, but not detailed requirements.
And that is where the confusion lies, I believe. The fundamental
requirements need to be solid, and that's true no matter what method you
use. But when you say getting the requirements nailed down, most people
think that means getting all of the details straightened out before
coding starts. But guess what? Even if you try, you still won't have
thought of everything, and you'll have to make changes to the
requirements as you go anyway.

> The other aspect to this that feels like it is missing is the other
> side of
> the development process. Where is QA? In Agile? You cannot leave
> testing to
> those who coded it. QA is a vital component to a release process thus
> perpetuating the "waterfall'.
>
>
QA people are part of the development team, and therefore do testing
"continuously", or as close to that as possible.

Jim

25 Mar 2004 - 1:50pm
Nick Ragouzis
2004

Well, Jim beat me to the "enter" key. So my old post is dead.
He's got one part of it. Some other parts are, in a nutshell:

* Coding is cheap. Alan Cooper, as much as anyone, knows
this. Creating Visual Basic made all sorts of coding
really cheap. Other sorts were still relatively expensive.
But soon even many of these have fallen dramatically.
Tools that help one reconcile code to other code, to other
libraries, and to other platforms are all part of this
dramatic reduction in risks, therefore costs. The usual
unfolding of our practice (interaction design) depends
wholly on this nature -- something I mention again at
the bottom.

* What defines the threshold, and the distinction that
David just raised about complexity in systems, is the
capability to validate. Once you can validate, costs
(and risks) dive. Often these benefits are offset by
a tendency to increase the complexity of the system.
This isn't so bad, really -- few systems around us
actually do what we really want.

* To tie in Jim's post(s), I cannot think what has been found
to be more expensive to validate than planning (hence
design). Relative to the aim of the project itself, all
effort that flows from planning *is* its validation.

For a bizarre example, sometimes one has to wait for an
earthquake to validate certain planning _assumptions_
worked out through social process over modeling. And in
the eventuality, if it turns out to be 'mere' shoddy
construction or materials ... well, this is much easier
and less expensive to fix.

Further, the costs of planning (including its prototype
artifacts) are often so expensive that they cannot be
amortized in the revenue of the initial or central result.
Recovery requires realization of a complete family of
products and services. This isn't limited to software.

* UCD is the overture to validation of certain kinds of
design. Looked at this way it provides a foundation for
validating at one remove from interface twiddling. In
practice, however, little beyond that (interface twiddling)
is actually validated. For example rarely are the totality
of the ethnographic findings validated with interim
or 'final' implementations. As sometimes happens, the
overture is more promising that the opera itself. The
chair examples here are an instance of this -- if only
because of the assumptions (or imposed constraint) that
there be only a few or one model of chair produced.

* So we can see that patterns and reusable objects both
serve as carriers of validation, and therefore reduced
risk ... and in consequence a potential for reduction
in costs. Those components also, however, become less
open to certain kinds of innovation or adoption to user's
ends. The reduction in risk that validation brings is
also a reduction in the necessity in precision of
planning and design -- you reduce the risks associated
with cutting short the social and organizational
components.

Further, this sort of validation (as opposed to the most
narrow quality control-like perspective) serves two
purposes. The first is operational; the second is
reification. It is the latter, and its exposure to the
user and client, that agile methods really seek to
leverage.

* XP becomes Agile Methods only because of recognition
and servicing of the organizational aspects of design.

Agile Methods are a social-process tool, not a
technical tool. Really this is mostly so even in the
narrower XP sense.

By comparison on the same grounds (that is, within the
design process) UCD is an artifact-process tool. For
the most part the complaints we hear within the community
(acceptance, etc) are evidence of this lack of adoption
to (or by, some say) the social process.

* This leads to a rather rude conclusion: the problem lies
with us not agile methods.

Given that neither method seeks to dramatically reduce
the user's ends we are left with the difficulty that we
do not have effective tools for our discipline: tools for
the process of designing and realization, and the validation
that's required at any/every stage. Either that or we don't
use them effectively. I think it's a bit of both, but in
the larger picture, we just do not yet have these tools.

* Related to this, Todd's excellent list project tasks,
merged with his "some technology glitch" shows just how
much our "planning" depends on certain assumptions about
the realization of the result and the standards of acceptable
results. This allows us to get okay results by getting
"85-90% of [interaction models] _done_ before development
begins." In this context we can, should, look at the
"one little change" phenomenon (that specific presentation)
as reflecting our customer's response to our somewhat
limited social-process methods. An appropriate response
from us would be to open the social process until such
change requests aren't presented in that way. Wouldn't
such an opening look a lot like agile methods?

Best,
--Nick

> -----Original Message-----
> From:
> discuss-interactiondesigners.com-bounces at lists.interactiondesi
> gners.com
> [mailto:discuss-interactiondesigners.com-bounces at lists.interac
> tiondesigners.com] On Behalf Of Jim McCusker
> Sent: Thursday, March 25, 2004 08:51 AM
> Cc: id-discuss
> Subject: Re: [ID Discuss] Agile User-Centered Design
>
>
> Peter Bagnall wrote:
>
> >> Do you make a building w/o a design up front?
> >> Do you make a car w/o concept models?
> >> Industrial designers as well have non-usable prototypes.
> >
> >
> > I find it interesting that the answer to these rhetorical questions
> > is obvious to everyone. And yet it still appears to be
> non-obvious to
> > many in the software world.
> >
> > Robert points out, quite rightly in my view, that this
> means changing
> > business processes. But I think there's something deeper.
> It requires
> > changing the view of software as something infinitely
> malleable. Alan
> > Cooper was talking about this problem a couple of years
> back, saying
> > how since planning is cheap and coding is expensive we
> should do more
> > of the former and (therefore) less of the latter. This is a message
> > we are still failing to get across, although progress is
> being made.
>
> I'm sorry, but planning is not cheap. Planning involves lots of time
> from lots of people. You often have to get many people (usually
> high-level and therefore highly paid) into a room for many
> hours. Even 4
> hours of planning can cost $1000s. Coding is very cheap by
> comparison.
> And requirements move. By the time you get everything nailed
> down, the
> market or internal requirements has shifted, causing a need for more
> planning. And then, if you ever do get to the coding phase,
> you have to
> keep up with shifting requirements again. And if you're using
> 3rd party
> software, more often than not you need to figure out how to
> work around
> some of its limitations. Agile is set up so that you can respond to
> those changes easily and quickly, while maintaining the sanity of
> everyone involved. What Cooper is advocating is essentially a
> waterfall
> methodology, which was discredited years ago, and only works when the
> project exists in a vacuum, which it never does. Things
> change, you need
> to respond, and there's no reason to nail down details before their
> time, because the assumptions that were made to cause those
> details to
> need to be thought about may change.
>
> Jim

25 Mar 2004 - 2:25pm
Cindy Alvarez
2004

> Many people have suggested this, but my impression is that it's
> somewhat rare that this happens in practice. Is there a sense on the
> list as to how common this is?

In my experience, it's quite rare. A combination of "just in time"
staffing and splintering tasks into many people (one for IA, one for ID,
one for copywriting, one for visual design) leads to no one with a "big
picture view" of the project.

When clients are pleased with the overall consistency and quick turnaround
time that comes from having a dedicated "benevolent dictator", I advertise
that success and it has helped me to be able to come back and say, "I
understand that X in your organization would like to make Y change. Let
me explain why I think Z would be a better option, and if they disagree, I
would like to talk further with them to find the best new option for the
product as a whole."

Doesn't always work, but it's always worth trying.

Cindy Alvarez

25 Mar 2004 - 2:43pm
vutpakdi
2003

--- Jim McCusker <jim at usablesoft.com> wrote:
> I'm sorry, but planning is not cheap. Planning involves lots of time
> from lots of people. You often have to get many people (usually
> high-level and therefore highly paid) into a room for many hours. Even 4
> hours of planning can cost $1000s. Coding is very cheap by comparison.

Planning is also hard and not fun (for most people). I've seen people turn
away from planning and design because those activities are harder and less
fun than going straight to coding.

Planning also doesn't immediately result in something as tangible as code.
A number of managers and executives still don't recognize that a
plan/design shows as much progress towards the goal as some X percentage of
code done.

Ron

=====
============================================================================
Ron Vutpakdi
vutpakdi at acm.org

25 Mar 2004 - 3:00pm
Rick Cecil
2004

Nick Ragouzis wrote:

> * This leads to a rather rude conclusion: the problem lies
> with us not agile methods.
>
> Given that neither method seeks to dramatically reduce
> the user's ends we are left with the difficulty that we
> do not have effective tools for our discipline: tools for
> the process of designing and realization, and the validation
> that's required at any/every stage. Either that or we don't
> use them effectively. I think it's a bit of both, but in
> the larger picture, we just do not yet have these tools.

What about interviews, contextual inquiry, surveys? Personas, scenarios?
Card sorting? Task analysis, competitive analysis, gap analysis, mental
modeling? Sitemaps, workflow, use cases, UML diagrams? Usability tests at
every stage of the design process? Design patterns?

And there's more.

The problem really comes down to businesses not understanding our value.
We're not programmers who produce working software that we can put in front
of users. What we do is more nebuluous, but just as valuable. And as long as
businesses don't understand our value, they will not spend any money for
what we do. And that is our fault. We do need to spend time communicating
with business decision-makers who can invest more money into these processes
and methodologies.

> This allows us to get okay results by getting
> "85-90% of [interaction models] _done_ before development
> begins."
> In this context we can, should, look at the
> "one little change" phenomenon (that specific presentation)
> as reflecting our customer's response to our somewhat
> limited social-process methods. An appropriate response
> from us would be to open the social process until such
> change requests aren't presented in that way.

How are our social processes limited? It seems to me that UCD is a fairly
well defined design process that has change management features built into
it. Further, I'm not sure I buy into the assessment that we need 85-90% of
our interaction models complete before development begins. Ultimately,
though, the individual design and development team must choose a process
that works for them. And, IME, these processes tend to be a mixture of
pieces from different theories.

Also, could you better explain what you mean by "opening the social
process"?

> Wouldn't such an opening look a lot like agile methods?

It would also closely resemble a UCD approach. We would have a hybrid,
felxible approach, which would give us a range of processes, tools, and
artifacts. As designers we should apply the appropriate tools to the
project. Not every tool makes sense on every project.

The bottom line, here: We must use the appropriate tools, artifacts, and
processes for each project's scope. Deciding which tools, artifacts, and
processes are appropriate is not something we can do in a theoretical
discussion, but we can identify our plethora of available tools, artifacts,
and processes.

-Rick

25 Mar 2004 - 2:59pm
Cindy Alvarez
2004

> I'm sorry, but planning is not cheap. Planning involves lots of time
> from lots of people. You often have to get many people (usually
> high-level and therefore highly paid) into a room for many hours.

I suspect that people on the list have varying ideas of what "planning"
entails. It's extremely rare that I am in a long planning meeting with a
lot of people - and to be honest, that smacks of management who are unable
to delegate properly.

Planning to me means identifying pieces that are likely to change, pieces
that need to maintain consistency with other apps or parts of a platform,
and making sure that the critical but unglamorous functions are handled
well. (For example, I've never yet had a client want to make changes to a
login screen - but what an incredibly important piece! If people can't
find the login, who cares what the rest of the product does?)

I'd never advocate trying to hammer out every detail in advance - that
does assume the non-existent vacuum - but I cringe when I hear, "oh, we'll
just figure that other stuff later" -- I'd much rather have a list of
items or concepts so that we know that X may change after client input or
Y will depend on the installation environment, etc...

Cindy Alvarez

Even 4
> hours of planning can cost $1000s. Coding is very cheap by comparison.
> And requirements move. By the time you get everything nailed down, the
> market or internal requirements has shifted, causing a need for more
> planning. And then, if you ever do get to the coding phase, you have to
> keep up with shifting requirements again. And if you're using 3rd party
> software, more often than not you need to figure out how to work around
> some of its limitations. Agile is set up so that you can respond to
> those changes easily and quickly, while maintaining the sanity of
> everyone involved. What Cooper is advocating is essentially a waterfall
> methodology, which was discredited years ago, and only works when the
> project exists in a vacuum, which it never does. Things change, you need
> to respond, and there's no reason to nail down details before their
> time, because the assumptions that were made to cause those details to
> need to be thought about may change.
>
> Jim
> _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
> http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members get announcements
> already)
> http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/
>

25 Mar 2004 - 5:19pm
pabini
2004

Participants in this discussion seem to be dividing into camps according to
whether they believe in the efficacy of planning and design phases at the
beginning of the software development process. I think planning and design
are essential to the success of any project.

I agree with Jim McCusker that a pure waterfall lifecycle model is
inappropriate for most software development projects--with the possible
exceptions of a well-defined maintenance release of existing software or a
port of existing software to another platform. The waterfall lifecycle model
is certainly not well suited to innovative software projects, which require
iterative design and development phases. A pure waterfall lifecycle model
has the following disadvantages:

* Because of its high management and documentation overhead, it is not well
suited to rapid-development projects.
* It does not provide support for identifying and controlling risks that
could impact the development schedule or software quality.
* Because it requires that all marketing requirements be defined during the
concept phase, it does not allow the development team to take full advantage
of customer feedback or respond to changes in the market in a timely manner.
* Because it requires that all functional specifications be completed during
the design phase, it does not accommodate the iterative cycles of design and
usability testing that are necessary for user-centered design (UCD).
* It is not well suited to projects requiring innovative software
architectures.
* It does not accommodate rapid prototyping.

Most of the limitations of the pure waterfall lifecycle model derive from
its succession of discrete phases, in which the various tasks that are
essential to all software development cannot overlap one another. However,
either a modified waterfall lifecycle model, a spiral lifecycle model, or an
"agile" software development model that incorporates UCD supports

* rapid development
* risk management
* visibility of progress to management
* evolving marketing requirements
* iterative cycles of software design and usability testing
* development of innovative software architectures
* development of software architectures that support incremental improvement
and expansion of functionality in future releases
* rapid prototyping
* midcourse corrections
* development of high-quality, reliable software with few defects

Relative to the cost of development, planning and user-experience design and
specification are indeed cheap. Refer to almost any well-known book on
software development process and you'll find graphs showing how the cost to
make changes to software increases radically as a project progresses. There
are "agile" methods of planning and design, as well as development.

One software-quality risk that would likely result from engineers working
without specifications would be inconsistency in design. With various
software engineers programming different parts of an application without a
specification to guide them, it's likely that they would reinvent the wheel
when encountering similar design problems. This is neither efficient nor
good for users. On the other hand, I agree with Todd Warfel that design must
be an iterative process, incorporating feedback from both usability testing
and engineering, and therefore, that specifications are "living documents".

I agree with Rick Cecil, Pete Bagnall, and Robert Reimann that the "agile"
approach need not exclude planning and design phases and, indeed, can
greatly benefit from their inclusion. I agree with Jim and Rick that the
"agile" approach and UCD can be complementary. Any well-conceived
development process can incorporate UCD and, if users are to be well served,
should do so. For user-experience designers and usability engineers to be
successful, I think it's important that they be able to adapt their
processes to any workable software development process. It's easier to
persuade companies to make minor modifications to their processes than to
make comprehensive changes.

Pabini Gabriel-Petit
Spirit Softworks
www.spiritsoftworks.com

25 Mar 2004 - 5:44pm
pabini
2004

Cindy Alvarez said:

> When clients are pleased with the overall consistency and quick turnaround
> time that comes from having a dedicated "benevolent dictator", I advertise
> that success....

I agree that one user-experience designer should provide the vision for a
software user interface, to achieve the benefits that Cindy mentioned.

Pabini Gabriel-Petit
Spirit Softworks
www.spiritsoftworks.com

25 Mar 2004 - 10:48pm
Nick Ragouzis
2004

Well ... a response in two parts. Part 1, here, about
the specific challenges you've tossed me, Rick. Part 2,
the second message, about your comment on appropriate
tools -- a bit of history.

> discuss-interactiondesigners On Behalf Of Rick Cecil
> Subject: RE: [ID Discuss] Agile User-Centered Design
>
> Nick Ragouzis wrote:
>
> > * This leads to a rather rude conclusion: the problem lies
> > with us not agile methods.
> >
> > Given that neither method seeks to dramatically reduce
> > the user's ends we are left with the difficulty that we
> > do not have effective tools for our discipline: tools for
> > the process of designing and realization, and the validation
> > that's required at any/every stage. Either that or we don't
> > use them effectively. I think it's a bit of both, but in
> > the larger picture, we just do not yet have these tools.
>
> What about:
> interviews,
-- artifact & artifact-related-process bound
> contextual inquiry,
-- artifact & artifact-related-process bound
> surveys?
-- artifact & artifact-related-process bound
> Personas,
-- artifact & artifact-related-process bound
> scenarios?
-- artifact & artifact-related-process bound
> Card sorting?
-- artifact & artifact-related-process bound
> Task analysis,
-- artifact & artifact-related-process bound
> competitive analysis,
-- artifact & artifact-related-process bound
although the artifacts under analysis here
may be the competitor's. (Possibly extending
to economics and all the related social com-
ponents, although this is rare in the ID
business.) Further, because this often requires
expertise (or portfolio) beyond the usual
interaction designer's it's likely to have a
larger social-process component than many
others listed here
> gap analysis,
-- artifact & artifact-related-process bound
> mental modeling?
-- artifact & artifact-related-process bound
> Sitemaps, workflow, use cases, UML diagrams?
-- artifact & artifact-related-process bound
> Usability tests at
-- artifact & artifact-related-process bound

> every stage of the design process?
> Design patterns?
-- artifact & artifact-related-process bound
>
> And there's more.
-- artifact & artifact-related-process bound :-)
>
> The problem really comes down to businesses not
> understanding our value.

Well, this is the symptom, not the disease, and
reversal isn't the cure.

> We're not programmers who produce working software that
> we can put in front of users. What we do is more
> nebuluous, but just as valuable.

Well, by two ordinary metrics what we do would be
considered even more potent with value. But in that
difference (potent vs. realized) lies the true
challenge.

> And as long as businesses don't understand our value,
> they will not spend any money for what we do.

Blaming the patient ? ...

> And that is our fault.

... okay, we *are* likely to carry some of the fault in our
methods, and our practices ... and perhaps we exacerbate
a problem or two latent in the context itself.

> We do need to spend time communicating with business
> decision-makers who can invest more money into these
> processes and methodologies.

Well, sure ... once we've got something credible (to them)
to say ... suffice to say that would also be something
new to say.

> > This allows us to get okay results by getting
> > "85-90% of [interaction models] _done_ before development
> > begins."
> > In this context we can, should, look at the
> > "one little change" phenomenon (that specific presentation)
> > as reflecting our customer's response to our somewhat
> > limited social-process methods. An appropriate response
> > from us would be to open the social process until such
> > change requests aren't presented in that way.
>
> How are our social processes limited? It seems to me that
> UCD is a fairly well defined design process that has
> change management features built into it.

Ah, long discussion. One challenge in this is due to the
somewhat shared genesis of both methodologies (see a following
message), which were both impacted (variously) by spiral and
OOSE methodologies, although UCD stayed truer to these and
Agile has explicitly drawn on a more diverse lineage.

Here's an exercise. Pick a UCD book and an Agile book. Compare
the models and directives. I stipulate that the core of both is
the transform of user needs and desires into implementation
guidance or implementation itself. And that this core is of
course a social process.

The differences lie in the margins of that core. The 'margins'
of UCD pertain first to, well, your list above: HCI,
Information Architecture, Interaction principles ... and for
good reason, of course. The 'margins' of Agile, however, are
social concerning the context of design (the social aspects
in the context of the user were stipulated to be equivalent).
Rather than being about object models or interfaces or
structures or algorithms or patterns (the approx parallels
to HCI et al) it attends to ownership, public display, rights,
trust, etc. UCD doesn't ignore these, sure ... but does it
emphasize them at the highest level? Well, no; but Agile does.

> Further, I'm not sure I buy into the assessment that we
> need 85-90% of our interaction models complete before
> development begins.

I'm not sure I buy into it either. No; I am sure I *DO NOT* buy
into it as a must-be-done or should-be-done. I was linking to
Todd's pondering of the problem. It certainly is, however, close
enough a characterization of the way it is done today.

> Ultimately, though, the individual design and development team
> must choose a process that works for them. And, IME, these
> processes tend to be a mixture of pieces from different theories.

Agree. Oh, yes, agreed.

> Also, could you better explain what you mean by "opening the social
> process"?

See Agile methods, for one. One aspect has come up before: make
design thinking (rationale) explicit ... early and often. Create
*effective* forums for open exchange about these rationale, as well
as the decisions taken from them. Measure the effectiveness of the
forums on social and organizational terms along side (above?) design
terms. Many designers believe this could stiffle design if done
too early, or too explicitly, or too openly. Pish posh.

> > Wouldn't such an opening look a lot like agile methods?
>
> It would also closely resemble a UCD approach. We would have a hybrid,
> felxible approach, which would give us a range of processes, tools,
> and artifacts. As designers we should apply the appropriate tools to the
> project. Not every tool makes sense on every project.
>
> The bottom line, here: We must use the appropriate tools,
> artifacts, and processes for each project's scope. Deciding which tools,
> artifacts, and processes are appropriate is not something we can do in
> a theoretical discussion, but we can identify our plethora of available
> tools, artifacts, and processes.
>

(Mostly agreed, but I've moved my comments here to a separate message.)

Best,
--Nick

26 Mar 2004 - 12:08am
Nick Ragouzis
2004

And part 2, on models and practices:

> discuss-interactiondesigners On Behalf Of Rick Cecil
> Subject: RE: [ID Discuss] Agile User-Centered Design
>
> Nick Ragouzis wrote:

> > Wouldn't such an opening look a lot like agile methods?
>
> It would also closely resemble a UCD approach. We would have a hybrid,
> felxible approach, which would give us a range of processes, tools,
> and artifacts. As designers we should apply the appropriate tools to the
> project. Not every tool makes sense on every project.
>
> The bottom line, here: We must use the appropriate tools,
> artifacts, and processes for each project's scope. Deciding which tools,
> artifacts, and processes are appropriate is not something we can do in
> a theoretical discussion, but we can identify our plethora of available
> tools, artifacts, and processes.
>
> -Rick
>

Well, theory and practice are partners; one cannot advance without
the other. Here's something of both.

In 1978 through 1980* this model was refined for information systems
design:

A five-phase step-wise advancement-through-prototyping model
that put the user as the crucial central actor throughout.
It included, btw, a paper prototype in the earliest iterations.

Immediately following, various forms of this model were realized in
practice. The model characterized above has been called a Neohumanism
model. It is identified as one among four paradigms of that time.

You know what ... it isn't the closest model to Interaction Design's
realization of the UCD model. No, the model that's closest, I'd say,
is the Functionalism model. Functionalism is most clearly characterized
as the expert or Platonian 'Philospher king' model. Sound familiar?
Well, here's the kicker: another characteristic and part of that
heritage is the staged-implementation model, the waterfall.

That's a heritage I think we'd want to run from. But jumping on
another isn't quite right either. We should first get a clearer
idea of what's truly unique or different about interaction
design. If there is such a difference. I think there is.

Best,
--Nick

* 1978 Earl; 1978 Keen and Scott-Morton; 1980 Courbon and Bourgois
See: Information Systems Development and Data Modeling, Conceptual
and Philosophical Foundations. Hirschheim, Klein, Lyytinen.
ISBN 0521373687

> _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

26 Mar 2004 - 1:08pm
Rick Cecil
2004

> > What about:
> > interviews,
> -- artifact & artifact-related-process bound
> > contextual inquiry,
> -- artifact & artifact-related-process bound
> > surveys?
> -- artifact & artifact-related-process bound
> > Card sorting?
> -- artifact & artifact-related-process bound
> > Task analysis,
> -- artifact & artifact-related-process bound
> > competitive analysis,
> -- artifact & artifact-related-process bound
> although the artifacts under analysis here
> may be the competitor's. (Possibly extending
> to economics and all the related social com-
> ponents, although this is rare in the ID
> business.) Further, because this often requires
> expertise (or portfolio) beyond the usual
> interaction designer's it's likely to have a
> larger social-process component than many
> others listed here
> > gap analysis,
> -- artifact & artifact-related-process bound
> > mental modeling?
> -- artifact & artifact-related-process bound
> > Usability tests at
> -- artifact & artifact-related-process bound

These aren't artifacts. They're tools. Things we use to create the sitemaps,
mental models, use cases, scenarios, personas, etc.

By "artifact-related-process bound", do you mean these tools feed into the
creation of artifacts? If so, I agree. If not, could you clarify

> > We're not programmers who produce working software that
> > we can put in front of users. What we do is more
> > nebuluous, but just as valuable.
>
> Well, by two ordinary metrics what we do would be
> considered even more potent with value. But in that
> difference (potent vs. realized) lies the true
> challenge.

Are you saying that what we do has more of an effect on the product (and
thus the people using the product?) than the engineers? If that's not what
you mean, could you please clarify?

> > And as long as businesses don't understand our value,
> > they will not spend any money for what we do.
>
> Blaming the patient ? ...
>
> > And that is our fault.
>
> ... okay, we *are* likely to carry some of the fault in our
> methods, and our practices ... and perhaps we exacerbate
> a problem or two latent in the context itself.

I really see two problems here:

1) we don't spend enough time talking to decision-makers.

2) There aren't many decision-makers who have a UE background. How many
CTOs have technology related backgrounds? How many have UE backgrounds? For
that matter, engineers have their own voice at the executive level--the CTO.
Most companies don't have Chief Experience Officeer. In fact, I've never
heard of a Chief Experience Officer.

> > We do need to spend time communicating with business
> > decision-makers who can invest more money into these
> > processes and methodologies.
>
> Well, sure ... once we've got something credible (to them)
> to say ... suffice to say that would also be something
> new to say.

I disagree. We have plenty to say that's credible. There is tons of research
and case studies out there prove that using a UCD approach creates
successful products.

> The differences lie in the margins of that core. The 'margins'
> of UCD pertain first to, well, your list above: HCI,
> Information Architecture, Interaction principles ... and for
> good reason, of course. The 'margins' of Agile, however, are
> social concerning the context of design (the social aspects
> in the context of the user were stipulated to be equivalent).
> Rather than being about object models or interfaces or
> structures or algorithms or patterns (the approx parallels
> to HCI et al) it attends to ownership, public display, rights,
> trust, etc. UCD doesn't ignore these, sure ... but does it
> emphasize them at the highest level? Well, no; but Agile does.

I don't completely agree with you and I don't completely disagree with you.

The Social Process of Agile is fundamentally flawed: it assumes that
programmers and business people understand the user needs. The user is a
complex system--more complex than a programming language or business, which
can be extremely complicated things.

And you're right, UCD focuses on the processes for creating artifacts, as I
think it should. What you are talking about is bigger than UCD.

There are three systems that work together to create a product: business,
users, and tech. Business professionals work with the business system; tech
professionals with the tech system; and user experience professionals work
with the user system.

And the things that are developed and released, given the scope of the
current phase of a project, are those that users will use, that benefit the
business, and that are feasible to implement.

UCD is just one piece of this development process--user experience
professionals *may* use it to understand user needs. But it is not the
entire approach. Business professionals will have their own approach to
determining viability, and Tech professionals will have their own approach
to determining feasibility and implementing the design.

UCD does, though, ask that all features developed be first approved through
user-testing, so it does affect the other systems, but the other ssytesm
also affect UCD; nothing that isn't business viable should be developed and
nothing that is technologically feasible, given scope, should be developed.

For the entire development process to work, a high level of interaction
among all three systems must exist--giving each system the opportunity to
suggest ideas that affect the other systems.

All ideas that flow from a system are judged by the other two systems: the
business system gets to determine if a feature is viable to their goals;
tech system gets to evaluate the feasibility of the implementation of the
feature; and user system get to determine what features people will actually
use--as well as how to implement the features so that people can understand
them.

And people from one system can make recommendatios to the other systems. It
should not be a closed process where everyone is greddily guarding their
turf.

But I do agree that authors writing about UCD do not discuss the social
process. But should they? Is this over-arching social process UCD or is it
something else that ties the three systems together?

I would say that it is something else. But saying it's something else
doesn't mean that UCD advocates shouldn't be thinking about it or writing
about it. In fact, several folks within the industry are talking about this
very thing: Cooper, Norman, the folks at Adaptive Path, me. ;)

So, to say that UCD doesn't emphasize the social processes is true. It
doesn't. But to say that UCD practitioners aren't interested or aren't
thinking about the social processes is false. It is very much in the
forefront of UCD.

> > Also, could you better explain what you mean by "opening the social
> > process"?
>
> See Agile methods, for one. One aspect has come up before: make
> design thinking (rationale) explicit ... early and often. Create
> *effective* forums for open exchange about these rationale, as well
> as the decisions taken from them. Measure the effectiveness of the
> forums on social and organizational terms along side (above?) design
> terms. Many designers believe this could stiffle design if done
> too early, or too explicitly, or too openly. Pish posh.

See, this is where you give UCD a bum rap. The purpose of the UCD approach
is to rationalize every design decision. One major benefit is that it
removes political bickering and allows us to validate what users will
actually use. It allows for debate among the three systems (as mentioned
above: users, business, tech) but ultimately holds everyone accountable
through user testing.

-Rick

29 Mar 2004 - 12:31pm
Nick Ragouzis
2004

Some scattered comments:

> Rick Cecil wrote:
> These aren't artifacts. They're tools. Things we use to
> create the sitemaps, mental models, use cases, scenarios,
> personas, etc.
>
> By "artifact-related-process bound", do you mean these tools
> feed into the creation of artifacts? If so, I agree. If not,
> could you clarify

I think we agree. To recap my earlier stab:
Agile methods are a social-process tool, not a technical tool.
By comparison on the same grounds, UCD is an artifact-process
tool.

> > Rick wrote:
> > > We're not programmers who produce working software that
> > > we can put in front of users. What we do is more
> > > nebuluous, but just as valuable.
> >
> Nick wrote:
> > Well, by two ordinary metrics what we do would be
> > considered even more potent with value. But in that
> > difference (potent vs. realized) lies the true
> > challenge.

Rick wrote:
> Are you saying that what we do has more of an effect on the
> product (and thus the people using the product?) than the
> engineers? If that's not what you mean, could you please
> clarify?

More of an effect? No, I'm not talking to the "just as valuable"
point. I'm not sure how one could support pro or con on such a
claim. In my response I was moving beyond your "just as valuable"
on some unspecified ground to a grounding in the domain of potential
value (viz "potent with value"). In doing so I thought I might
be capturing a process component of part of your "nebulous."

By comparison to software engineering, interaction design (and even
more so, user-centered design) spends more time playing in the land
"could be."

One measure of potency is the utility sought in prototypes. Both
practices use them, and in largely the same way: to explore the
solution space.

Yet there is a difference as well -- there we find engineering uses
prototypes to seek functional validation (a difference in extent),
where design uses prototypes to seek inspiration to explore the
problem space and force unlikely synthesis (a difference in kind).

This subtle difference in the extended use of prototypes can stand
as an icon for the difficulty many interaction designers have with
XP (and Agile): it seems to collapse that time or flexibility for
exploration and 'unlikely' synthesis, and the changes derived thereby.

Another measure of potency is economic. Which is more a measure of
timing, the timing of the intervention: as we've heard here interaction
designers typically (like to) get involved very early in the problem
definition. Simply put: when in this role one will typically be part
of many potential return streams. This is subject to quantification.

It is also something that organizations are structured to parse. One
such operator is inertia ... which can make futile any attempt to change
a vocabulary or integrate operations. Another is modularity ... from
divisions in organization to divisions in product. Another is fast
reuse and propagation ... early decisions (constraints or selections)
are quickly leveraged in other domains ... not waiting for the completion
of the 'main' project. Budgets and schedules are another, which bring
overriding forces to design. These and more are examples of precisely
the kind of operator that XP also applies: smaller and faster, more
focused on a part of a problem that lends itself to modular decisions.
Unfortunately it makes difficult the case for the 'big picture/whole
problem' approach.

> > > And as long as businesses don't understand our value,
> > > they will not spend any money for what we do.
> >
> > Blaming the patient ? ...
> >
> > > And that is our fault.
> >
> > ... okay, we *are* likely to carry some of the fault in our
> > methods, and our practices ... and perhaps we exacerbate
> > a problem or two latent in the context itself.
>
> I really see two problems here:
>
> 1) we don't spend enough time talking to decision-makers.
>
> 2) There aren't many decision-makers who have a UE background.
> How many CTOs have technology related backgrounds? How many
> have UE backgrounds? For that matter, engineers have their
> own voice at the executive level--the CTO. Most companies
> don't have Chief Experience Officeer. In fact, I've never
> heard of a Chief Experience Officer.
>
> > > We do need to spend time communicating with business
> > > decision-makers who can invest more money into these
> > > processes and methodologies.
> >
> > Well, sure ... once we've got something credible (to them)
> > to say ... suffice to say that would also be something
> > new to say.
>
> I disagree. We have plenty to say that's credible. There is
> tons of research and case studies out there prove that using a
> UCD approach creates successful products.

I don't know what to say, Rick ... you've strengthen both sides of
the argument ... which is good. Perhaps it suffices to remind ourselves
that the sort of change being sought takes decades, even when it's
forcefully pursued.

>
> I don't completely agree with you and I don't completely
> disagree with you.
>
> The Social Process of Agile is fundamentally flawed: it assumes that
> programmers and business people understand the user needs. The user
> is a complex system--more complex than a programming language or
> business, which can be extremely complicated things.

I'm assuming :-) that by "it assumes" you mean that it is your
conclusion is that The Social Process Agile assumes these things. Because
the Agile Methods canon does not assume this at all, but rather explicitly
assumes the opposite.

... snip of much good stuff ...

> So, to say that UCD doesn't emphasize the social processes is true. It
> doesn't. But to say that UCD practitioners aren't interested or aren't
> thinking about the social processes is false. It is very much in the
> forefront of UCD.

Aren't interested? Aren't thinking? Oh, I wasn't saying that at all. But
one can note the irony that while 'software engineering' has been growing
up (say tracing the maturation of Tom DeMarco) UCD has more recently
forked a less fertile branch ... but I'm hopeful we can jump. (Just as Tom
did, earlier.)

> > > Also, could you better explain what you mean by "opening
> > > the social process"?
> >
> > See Agile methods, for one. One aspect has come up before: make
> > design thinking (rationale) explicit ... early and often. Create
> > *effective* forums for open exchange about these rationale, as well
> > as the decisions taken from them. Measure the effectiveness of the
> > forums on social and organizational terms along side (above?) design
> > terms. Many designers believe this could stiffle design if done
> > too early, or too explicitly, or too openly. Pish posh.
>
> See, this is where you give UCD a bum rap. The purpose of the
> UCD approach is to rationalize every design decision. One major benefit
> is that it removes political bickering and allows us to validate what
> users will actually use. It allows for debate among the three systems
> (as mentioned above: users, business, tech) but ultimately holds
> everyone accountable through user testing.

Bum rap? IIRC this discussion is part of the "first we need to finish 85%
of the design, then we can get the rest of the world (e.g., development)
involved (on their own terms)" thread. You've given an interesting definition
of UCD. I would have thought that a one-sentence purpose would say something
about deriving primary design inputs from direct engagement with users.
That's rationalizing sources, but not decisions. Further, 'accountable
through user testing' blithely omits that the testing most often done is
interface-functional, which is one or two levels derivative of the inputs
from user engagements.

. . . .

I have not said that I think we are hopelessly stuck. But if I reflect
on this for a moment ... I do think we will see that the user-centered
aspects of UCD will merge with the social-process tool that is Agile
Methods. Further, this blended methodology will become a general practice,
not limited to producing software-realized artifacts. It will be supported
(is being supported, driven even) by wholesale changes in organizational
structures and tools.

In this future, user experience design would be inherently advanced, but
interaction design of the type we've seen discussed on this forum (85%
before ...) would be given limited portfolio: a kind of computer-mediated-
widget-industrial-design.

I think there's a potential for a different future. But it fully and
directly depends on defining the unique domain of interaction design,
unique from all the related disciplines. That difference can then be what
is patterned and valued. What will not work is defining that difference,
the unique domain, in terms of an uber-design full-integration practice.

Thanks for an interesting discussion.

Best,
--Nick

30 Mar 2004 - 10:04am
Rick Cecil
2004

Nick Ragouzis wrote:
> Some scattered comments:
>
>> Rick Cecil wrote:
>> These aren't artifacts. They're tools. Things we use to
>> create the sitemaps, mental models, use cases, scenarios, personas,
>> etc.
>>
>> By "artifact-related-process bound", do you mean these tools
>> feed into the creation of artifacts? If so, I agree. If not,
>> could you clarify
>
> I think we agree. To recap my earlier stab:
> Agile methods are a social-process tool, not a technical tool.
> By comparison on the same grounds, UCD is an artifact-process tool.

We are closer to being on the same page than when the discussion began.
:)

When you say Agile is a social process tool, are you referring to the
Agile Alliance mission?

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

http://www.agilemanifesto.org/

And not meaning any particular implementation of Agile, like XP or
Scrum?

>>> Rick wrote:
>>>> We're not programmers who produce working software that
>>>> we can put in front of users. What we do is more
>>>> nebuluous, but just as valuable.
>>>
>> Nick wrote:
>>> Well, by two ordinary metrics what we do would be
>>> considered even more potent with value. But in that
>>> difference (potent vs. realized) lies the true
>>> challenge.
>
> Rick wrote:
>> Are you saying that what we do has more of an effect on the
>> product (and thus the people using the product?) than the
>> engineers? If that's not what you mean, could you please
>> clarify?
>
> More of an effect? No, I'm not talking to the "just as valuable"
> point. I'm not sure how one could support pro or con on such a
> claim.

I would measure pro or con by the quality of the product and its success
in a competitive marketplace. I think that a useful product that has
been designed with the user's goals in mind will be more successful (in
a for-profit venture, this means more users, more sales, etc.) than a
similarly-useful, similar product that has not been designed with the
user's goals in mind.

> In my response I was moving beyond your "just as valuable"
> on some unspecified ground to a grounding in the domain of potential
> value (viz "potent with value"). In doing so I thought I might
> be capturing a process component of part of your "nebulous."
>
> By comparison to software engineering, interaction design (and even
> more so, user-centered design) spends more time playing in the land
> "could be."

Sure. Any process requiring any amount of documentation up-front spends
more time in "could-be" than Agile.

Sometimes the time spent in "could-be" is possible and sometimes it is
not. To reach business owners and developers,

We should develop processes that will allow us to work with developers
and business professionals in both scenarios. I think that we can make a
bigger contribution to the product the earlier we are brought in, but I
also think we can make generous contributions if we are brought in
during development. The close the product is to launch, though, the less
interaction designers (or other experience designers) can effect its
implementation.

> One measure of potency is the utility sought in prototypes. Both
> practices use them, and in largely the same way: to explore the
> solution space.
>
> Yet there is a difference as well -- there we find engineering uses
> prototypes to seek functional validation (a difference in extent),
> where design uses prototypes to seek inspiration to explore the
> problem space and force unlikely synthesis (a difference in kind).
>
> This subtle difference in the extended use of prototypes can stand
> as an icon for the difficulty many interaction designers have with
> XP (and Agile): it seems to collapse that time or flexibility for
> exploration and 'unlikely' synthesis, and the changes derived thereby.

I addressed this above. There are other concerns I have with Agile, and
I can't speak for other interaction designers. Get a good interaction
designer into a process and she can begin building enough trust with the
decision-makers so that she will be brought in earlier-and-earlier on
the development cycles.

There are other, bigger concerns with XP. The biggest ones being

1. little or no user testing

2. programmers getting direction on
development from business professionals

These are the biggest flaws I see in XP/Agile.

[snip]

> These and more are
> examples of precisely the kind of operator that XP also applies:
> smaller and faster, more focused on a part of a problem that lends
> itself to modular decisions. Unfortunately it makes difficult the
> case for the 'big picture/whole problem' approach.

And this ultimately seemed to be the crux of both Cooper's and Beck's
arguments in the article.

[snip]

> I don't know what to say, Rick ... you've strengthen both sides of
> the argument ... which is good. Perhaps it suffices to remind
> ourselves that the sort of change being sought takes decades, even
> when it's forcefully pursued.

:) And that both processes have something to learn from each other.

>> I don't completely agree with you and I don't completely disagree
>> with you.
>>
>> The Social Process of Agile is fundamentally flawed: it assumes that
>> programmers and business people understand the user needs. The user
>> is a complex system--more complex than a programming language or
>> business, which can be extremely complicated things.
>
> I'm assuming :-) that by "it assumes" you mean that it is your
> conclusion is that The Social Process Agile assumes these things.
> Because the Agile Methods canon does not assume this at all, but
> rather explicitly assumes the opposite.

I need to read up on Agile more, then.

> ... snip of much good stuff ...
>
>> So, to say that UCD doesn't emphasize the social processes is true.
>> It doesn't. But to say that UCD practitioners aren't interested or
>> aren't thinking about the social processes is false. It is very much
>> in the forefront of UCD.
>
> Aren't interested? Aren't thinking? Oh, I wasn't saying that at all.
> But one can note the irony that while 'software engineering' has been
> growing up (say tracing the maturation of Tom DeMarco) UCD has more
> recently forked a less fertile branch ... but I'm hopeful we can
> jump. (Just as Tom did, earlier.)

We need something bigger than UCD. We need something bigger than a tech
process.

The Agile Alliance is a great example of people coming together to
create a social process. Unfortunately, they consisted mostly of
programmers and software engineers. We need a defined process that
aligns business needs, user needs, and technical feasibility. And the
discussion needs to include people from all three camps, if possible. It
shouldn't be one group speculating about what the other group needs. Nor
should it be one group claiming ownership over the other groups
discipline.

> Bum rap? IIRC this discussion is part of the "first we need to finish
> 85% of the design, then we can get the rest of the world (e.g.,
> development) involved (on their own terms)" thread.

I missed this, unfortunately. We need to complete high-level
documentation before developers begin work on the project. We don't need
every last detail about the system defined.

> You've given an interesting definition of UCD. I would have thought
that a
> one-sentence purpose would say something about deriving primary
> design inputs from direct engagement with users.

My intent was not to define UCD. Rather to discuss some of its benefits.

> That's rationalizing
> sources, but not decisions. Further, 'accountable through user
> testing' blithely omits that the testing most often done is
> interface-functional, which is one or two levels derivative of the
> inputs from user engagements.

People doing interface-functional testing either

1. Are restricted by scope to do anything else

2. Do not understand the full scope of the
UCD approach

> I have not said that I think we are hopelessly stuck. But if I reflect
> on this for a moment ... I do think we will see that the user-centered
> aspects of UCD will merge with the social-process tool that is Agile
> Methods.

I think that we'll see both Agile and UCD evolve into something
greater--at least, the two processes will become part of a larger social
process--a social process that meets the deficiencies of the two
processes.

> Further, this blended methodology will become a general
> practice, not limited to producing software-realized artifacts. It
> will be supported (is being supported, driven even) by wholesale
> changes in organizational structures and tools.

Absolutely! This is what I think those on the frontiers of interaction
design, like Cooper, see happening. You survive, you evolve but changing
the organization and ensuring that your development process accounts for
business goals, user goals, and technical feasibility.

[snip]

> Thanks for an interesting discussion.

I've definitely enjoyed it.

-Rick

Syndicate content Get the feed