Agile & UCD (was Thoughts on Alan Cooper'sKeynote)

14 Feb 2008 - 9:43am
6 years ago
1 reply
667 reads
Nicholas Iozzo
2007

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/

Comments

14 Feb 2008 - 10:00pm
ambroselittle
2008

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

Syndicate content Get the feed