Agile & UCD (was Thoughts on AlanCooper'sKeynote)

14 Feb 2008 - 9:52am
6 years ago
2 replies
548 reads
Nicholas Iozzo
2007

Ugh, that last part was worded wrong:

____
You could do this pre-work in time it takes to do 2-3 development sprints. But, you have explored more designs then you ever would have been able to in over a dozen development sprints.
____

That should have sad:
You could do this pre-work in time it takes to do 2-3 development sprints. Without this prework, it would take you over a dozen development sprints to explore the same design space.

Comments

15 Feb 2008 - 12:30pm
Zachary Sam Zaiss
2008

Hi Ambrose,

I've been following this thread with a lot of interest... as I mentioned
in a similar thread with Brian Hoffman (Overall Web Development
Process), I'm currently working with my company to create a
User-Centered Agile process. I agree with you - finding the right way to
incorporate UCD talent into the Agile process is really the way to go.

One thing I mentioned in the other thread is the importance of hooking
into the up-front vision - which, while a documented part of the Agile
process, gets very little coverage from what I can tell. I think it's
de-emphasized because requirements will always change, but a solid
vision is still needed to know what it is you're going to build.

I'm curious - have you seen (or do you have) any thoughts on what
interaction designers can do in partnership with management or
architects to proactively clarify the vision, rather than design around
whatever vision they receive?

While I like the ideas for how the various disciplines plug in to the
agile process, it still strikes me as passive. Someone tells interaction
designers what the product vision is, and they design around it. Maybe
these are decisions of the architects - and I agree that they're smart
people capable of making these decisions on their own - but a
partnership with interaction designers and usability folks can only
serve to arrive at a better, user-centered vision, right?

Cheers,
-Sam

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of J.
Ambrose Little
Sent: Thursday, February 14, 2008 10:00 PM
To: Nick Iozzo
Cc: IxDA Discuss
Subject: Re: [IxDA Discuss] Agile & UCD (was Re: Thoughts on
AlanCooper'sKeynote)

Hi Nick,

Thanks for jumping in with your thoughts.

I was reading the thread about prototypes and now reading this, and in
both
cases, the thing that jumps to mind is patterns. Patterns are a way to
both
learn and communicate good design. I won't debate the experience is
highly
valuable, particularly experience guided by a "master." At the same
time,
when masters are in short supply, we may need to look to other, more
scalable options. I think that's where patterns can do a lot of good;
they
can help you avoid a lot of bad design in the first place and, in
theory,
help you pick the right one the first time. They also help you
understand,
rationalize, and communicate why certain designs are good in certain
scenarios and others are good in others.

So if we have these patterns, are under the guidance of a master, or are
a
master ourselves, we really shouldn't need to go through a lot of design
iterations to get the right thing in most situations. What it comes
down
to, then, is getting it mostly right the first time, and the iterations
serve to refine and tweak to really tailor the solution to the problem.
So
being agile is not about completely changing a design several times over
but
tweaking a mostly right design.

The core problem with waterfall-like approaches is the wrong-headed
assumption that we can figure out the right thing up front, document
that
right thing, and, via that documentation, sufficiently communicate that
right thing to the folks who actually build it. Let's say you, as the
UX
pro, are able to figure out the right thing to build up front (which I
find
a dubious proposition), you still have to somehow communicate that to
the
folks who have to build it. Then they have to figure out how to make it
happen (assuming it is technically feasible), understand your design
from
your documentation, and then execute upon it based on that.

Granted, there is a higher chance of success with your help than if we
skip
the UX stuff and stick with the old-fashioned requirements gathering by
the
biz and bulid from that, but we're still left with this essentially
flawed
idea that the needs of the business can be sufficiently communicated
through
design artifacts. You're still in that boat where you're upset with the
devs because you feel they didn't execute on your vision, when the
problem
likely lies more in the flawed process that assumes you can sufficiently
communicate your vision through design artifacts.

Even software architects who are (or were), generally speaking, master
developers can make mistakes in their design or leave things out that
leave
developers hanging, having to work around them or come up with solutions
on
their own. We architects have an intimate, experiential knowledge of
what
it takes to build software, yet even we don't always make the right
design
choices up front, often leave out necessary details, and often fail to
communicate our right ones.

It's not fair to expect that UX pros should anticipate and address the
difficulties in implementing their desired designs who lack (as a rule)
the
knowledge of how to make designs become reality with technology.
Further,
it's not fair to expect them to be able to sufficiently communicate
their
design through design artifacts, especially when they lack the common
language and context that even devs and architects share. Similarly,
it's
not fair to expect developers to make the "right" decisions when they
run
into difficulties (or missing details) or always correctly interpret
design
artifacts and translate them into running code. That this is true is
confirmed in my own experience, anecdotal evidence, and even the latent
hostility there seems to be in the creative community towards developers
(and to some extent vice-versa).

In short, the addition (or expansion/specialization) of UX
professions doesn't change the fundamental flaws of the waterfall
process.
You guys bring very important talents and skills that we *need *to make
great software, but that doesn't mean we can go back to waterfall
approaches. We need to incorporate you into agile processes. You need
to
be there to see your vision through to completion, and it is good for
the
business in that we can minimize the costly design artifacts that have
limited practical value and focus on getting the right thing up and
running. The value proposition of agile, as I see it, holds true even
with--especially with--the incorporation of UX professionals.

Architects and devs are not dumb people. We take pride in what we do
just
as much as UX folks do. We want to build great stuff. We've been doing
software for many decades now, and we've figured out that waterfall
doesn't
work well to build great software (or even to build software that just
works). Learn from what we've learned; don't go through the painful
process
to figure it out yourself.

Some of us are also recognizing that we need more focus on UX in our
software design. Businesses are also realizing that value, and thus
these
specializations are emerging to meet that need. I'd say we have a duty
not
to forget what we've learned, to learn from each other, and come up with
new
and better ways to build the best software possible. Let's put our
collective brains and imagination together and do this thing. :)

Cordially,

--Ambrose
On Thu, Feb 14, 2008 at 9:43 AM, Nick Iozzo <niozzo at tandemseven.com>
wrote:

> Ambrose, glad to see someone with you background actively
participating
> in these discussions. This is what we need.
>
> From your description, what I see missing the time to explore the
design
> space. Bill Buxton had a great slide (and simple one) showing the
design
> process. In words: Design is about choice.
>
> You need to generate a lot of GOOD options so that you can then make a
> GOOD choice.
>
> Hypothetically. Maybe one good interaction metaphor for your product
is a
> step-by-step process over several pages. Maybe another good
interaction
> metaphor is a simple form where the detail is reveal through
progressive
> disclosure.
>
> To want to build each one of these in a sprint in order to evaluate
this
> would be a waste of time. It is better to have a design exploration
phase
> prior to any development sprint.
>
> I have had experience in projects like this. Where you start out the
> design exploration phase with a collaborative design workshop. You
follow
> this with a series of rapid iterations over the next ~2 weeks. I would
> expect to be able to explore over 10 different good interaction
metaphors in
> that time.
>
> Ideally, I would then take 2 or 3 of the best interaction metaphors
and do
> some testing with end-users on them. I do not ask them to pick which
one
> they like, I use this to understand how well they can interact with
each
> one.
>
> I could use this information to then design the screens for the first
> sprint.
>
> You could do this pre-work in time it takes to do 2-3 development
sprints.
> But, you have explored more designs then you ever would have been able
to in
> over a dozen development sprints.
>
> *Nick Iozzo
> *Principal User Experience Architect
>
> tandemseven
>
> 847.452.7442 mobile
>
> niozzo at tandemseven.com
> http://www.tandemseven.com/
>
>
> ------------------------------
>
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

16 Feb 2008 - 1:16pm
ambroselittle
2008

Hi Sam,

Interesting you should bring up the ownership/partnership question. There
is a related thread going on right now ("Who does design engineering"). This
is precisely where the agile approach to software really shines--it requires
regular, repeated collaboration to sort of keep each other in check with
reality as well as help each other see how we can do better.

In fact, there is a particular technique within the agile umbrella called
domain-driven design that I believe shares a lot of the values that UCD has,
but perhaps we approach it with a bit more humility than is suggested in the
"insurrection" that Alan Cooper advocated. One of the things you do in
domain-driven design is to establish the "ubiquitous language" that is used
throughout (all the way from the business to the code).

The thing is that doing this facilitates a clarification (not just
exposition) of domain concepts with the business. Business folks tend to
take a lot for granted (not a bad thing necessarily; it just is), and this
is often where the difficulties in building software for them comes into
play. In order to automate some portion of the business, we have to help
them comb out the intricacies of what they do in a sufficiently definite way
that software can be made based upon the language without a lot
of interpretation, translation, and subsequent breakdown.

Granted, the focus is on domain concepts and object oriented design to
automate the core domain of the business, but clarifying domain concepts can
only help the overall UX. I would think a similar process would be
effective in terms of designing the interfaces, and it seems to me that this
is in large part where personas can help in that they, too, provide a sort
of common language, at least a common referent, to help focus the interface
design efforts. Discovering and establishing the personas with the business
is a great opportunity to collaborate with the business at an early
enough stage to get the sort of early influence over vision that I think
you're driving at. In both cases, the key is that we're working with the
business stakeholders to help clarify the business in a way that can be
translated into great software the meets the business needs.

I can see how my descriptions seem passive. That's largely due to the way I
see most businesses operating in terms of software today, but it is
dangerous to generalize about how businesses run. :) I agree that we need
an active partnership in order to be effective in making great software. I
tend to think that the business stakeholders ultimately "own" the product
and product vision. My hope, though, is that by increasing the lines of
communication and understanding between UX folks and devs/architects, we
will be more understanding and open to each others' input and challenges so
that no matter who is "in charge" on a particular project, we work together
to come to the best solution.

A big first step in this is helping devs and architects to understand the
importance and value of UX, how they can incorporate it into what they do
today, and how they can work with UX folks when they're available. I
actually just recently prepared a talk on this very thing and will be giving
it to developer groups throughout the year (I'm an
INETA<http://ineta.org/DesktopDefault.aspx?tabindex=6&tabid=11>speaker,
which gives me lots of opportunities).

Another big part will be UX folks being understanding and flexible. As I
said before, I'd warn against coming into a dev organization and trying to
change the processes (particularly trying to push back to waterfall, which
has become a byword for many). If the org is using agile, figure out how
you can work with it. I'm making suggestions here, but they're just
suggestions on how/where I think UX folks can plug in.

All this and a healthy dose of patience, patience, patience. :)

--Ambrose

On Fri, Feb 15, 2008 at 12:30 PM, Sam Zaiss <zszaiss at worldlearn.com> wrote:

> Hi Ambrose,
>
> I've been following this thread with a lot of interest... as I mentioned
> in a similar thread with Brian Hoffman (Overall Web Development
> Process), I'm currently working with my company to create a
> User-Centered Agile process. I agree with you - finding the right way to
> incorporate UCD talent into the Agile process is really the way to go.
>
> One thing I mentioned in the other thread is the importance of hooking
> into the up-front vision - which, while a documented part of the Agile
> process, gets very little coverage from what I can tell. I think it's
> de-emphasized because requirements will always change, but a solid
> vision is still needed to know what it is you're going to build.
>
> I'm curious - have you seen (or do you have) any thoughts on what
> interaction designers can do in partnership with management or
> architects to proactively clarify the vision, rather than design around
> whatever vision they receive?
>
> While I like the ideas for how the various disciplines plug in to the
> agile process, it still strikes me as passive. Someone tells interaction
> designers what the product vision is, and they design around it. Maybe
> these are decisions of the architects - and I agree that they're smart
> people capable of making these decisions on their own - but a
> partnership with interaction designers and usability folks can only
> serve to arrive at a better, user-centered vision, right?
>
> Cheers,
> -Sam

Syndicate content Get the feed