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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>
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
>
> [EMAIL PROTECTED]
> http://www.tandemseven.com/
>
>
> ------------------------------
>
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... [EMAIL PROTECTED]
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... [EMAIL PROTECTED]
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help
