Thoughts on Alan Cooper's Keynote

10 Feb 2008 - 1:08am
7 years ago
65 replies
3083 reads
Charlie Kreitzberg
2008

When Alan Cooper delivered the opening keynote at Interactions08 this
morning, I was once again struck by how sensible his view is. As I
understood his core argument, it was:

1. We know that the best interactive products are not the first to
market but the ones that have the best quality design.

2. Business managers often fail to understand this because they do not
know how to manage "creatives" among whom he numbers both interaction
designers and programmers.

3. The typical business approach is to develop requirements and then
build the product. A better approach would be to have an interaction
design team design the product concept and pass it on to the programming
team. The programming team would then use the design as input to its own
technical planning phase reaping a more focused and efficient build
cycle.

4. Since business management does not recognize the importance of this,
it is up to the interaction designers to begin the organizational change
process. We would accomplish this by striking an alliance with the
programmers who will value us as fellow craftspeople. This alliance
would help transform the way products are developed.

The environment that Alan describes is typical of large, non-software
corporations whose IT departments continually struggle to stay in
alignment with their business counterparts. Those who work in such
corporations will probably resonate to this description. Those who work
in Web 2.0 software companies or digital agencies may have a very
different experience.

I agree with Alan that design makes products great. But being first to
the marketplace, means you designed your product without the benefit of
examining, critiquing and learning from existing products and the
reactions of users to them. Given that useful input it is not surprising
that later entries improve on the initial ones.

I've long advocated that that it is essential to design the product
through an IxD process that largely precedes technical planning. TRhat's
a great goal. But I am less optimistic than Alan about how easily we
will be able to create an alliance with programmers. A recent survey by
Information Week found that only 5% of IT people thought that Web 2.0
was of any value to their companies. Yikes! We still have a long way to
go to educate the technical community. And I'm not sure that we won't
have another hurdle to cross in convincing the Project Management
Institute as well.

I believe the lack of management support for creativity and craft comes
less from management's being stuck in old style industrial thinking in a
post-industrial society, as Alan suggests, then from unrelenting
pressure from senior management. The price that executives pay for their
substantial compensation is constant pressure to deliver profit to
shareholders. That is pretty much their only focus and it cascades down
to all management. To shift the way that products are managed, we need
to position design activity as a revenue generator and profit enhancer
and make that case to senior management.

That is one reason that I've been arguing for the need to explain our
value in simple terms. There is still a lot of selling to do.

Charlie

Comments

13 Feb 2008 - 5:49am
SemanticWill
2007

Manifestos are beautiful - and I can't argue with these - but it's the
practice and process of any methodology carried out by real people that is
all that matters. The communist manifesto was a work of literary art. Stalin
killed 50 million people. Manifestos don't always lead to good outcomes in
reality.

On Feb 13, 2008 5:38 AM, Jeff White <jwhite31 at gmail.com> wrote:

> I realize I'm the wrong Jeff, but here are the values:
>
> Manifesto for Agile Software Development
>
> 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://agilemanifesto.org/
>
> On Feb 12, 2008 11:34 PM, David Malouf <dave at ixda.org> wrote:
> > Jeff, can you please lay out these "values" you speak of?
> > The reason I ask is that every agile method I have been acquainted with
> (and
> > quite a few) have real processes and methods to them, not values.
> > I do realize there are differences among them at a granular level but
> there
> > are many repeat processes.
> >
> > 1. small iterations
> > 2. don't document
> >
> > Those 2 seem to jump to mind.
> > Almost all have a point where they "consider" users.
> > But then again, I know many design processes that don't do that much.
> >
> > But this is doing design.
> >
> > If you are going to quote Bill, to try to support agile, that is really
> a
> > leap, don't ya think. Since his talk was fully grounded to talk about
> > "design up front" to the point of getting a green light, considered with
> > collaboration throughout both pre and post-greenlight. Doesn't seem very
> > agile to me?
> >
> > In the end, my problem has always been, one of forced assimilation. Tell
> me
> > a designer centered agile process and I will rescind what I've been
> saying.
> > But the values associated with agile all derive from engineering
> concerns,
> > and in themselves are a protectionist reaction to businesses deep upset
> with
> > "time to market" (a concept that Alan tried to tell us was flawed).
> >
> > Maybe there is a way to do design centric agile product lifecycles, or
> > better to Jared's point, just holistic agile processes. I have not seen
> them
> > yet.
> > To be honest, I'm not in a rush.
> >
> > BTW, the end result of both software and hardware is the same. A
> product.
> > The difference is that one is done with a factory of machines and the
> other
> > is done with a factory of human beings. A single product is made in
> either
> > case. I also think that my comment about the fungeability of software
> has
> > not been addressed. That is to say that software no matter the platform
> is
> > not really as cheap and quick as we think and this basic flaw is why we
> need
> > more up front (a whole lot).
> >
> > -- dave
> >
> >
> > On Feb 12, 2008 5:02 PM, Jeff Patton <jpatton at acm.org> wrote:
> >
> > > All, please excuse the quick message pecked out with my thumbs.
> > >
> > > I'm struggling with the broad generalizations about designers and
> > > agile. Projects and products vary wildly in their goals, users,
> > > number of user goals, and breadth of scope. Teams and companies vary
> > > wildly as well. I'm a proponent of good design and allowing design
> > > thinking to cross into the development process with the ultimate goal
> > > of getting something valuable into the hands of people.
> > >
> > > Agile development isn't a process, it's a value system. That value
> > > system motivates people to construct specific processes - but the
> > > agile manifesto only describes the values. At the ixda conference I
> > > saw a presentation from the dopplr guy. The process he described
> > > himself following any agile person would identify as "agile". He's
> > > working directly with developers, collaborating, and releasing
> > > software regularly. It seems a nice rewarding worklife to strive for.
> > >
> > > Finally, it's difficult to compare the process used to design a
> > > manufactured product like a phone, car, or vacuum cleaner with a
> > > product like software where we make only one. Without knowing much
> > > about the design process of these sorts of products, my guess is they
> > > end with at least one full working product (the prototype) + a
> > > manufacturing process for it. Software just needs to end up with the
> > > full working product. Didn't Alan say everything's a prototype until
> > > it ships?
> > >
> > > Finally, I love Bill's comment on prototype fidelity. "there's only
> > > right and wrong fidelity" the moment you stop learning from paper,
> > > powerpoint, or photoshop, it's time to go to code. Some leap to code
> > > sooner than they should, some designers leap for photoshop when they
> > > should be leaping for a pencil. When all you have is a hammer,
> > > everything looks like a nail. If you're suspicios of hammers, then
> > > when all you have is a hammer, everything looks like a thumb.
> > >
> > > Cool discussion
> > >
> > > Thanks
> > >
> > > Jeff
> > >
> > >
> > >
> > > Sent from my iPhone
> > >
> > > On Feb 12, 2008, at 3:58 PM, "Alan Cooper" <Alan at cooper.com> wrote:
> > >
> > > > Dave,
> > > >
> > > > You are a very insightful person.
> > > >
> > > > Thanx,
> > > > Alan
> > > >
> > > > __________
> > > > cooper | Product Design for a Digital World
> > > > Alan Cooper
> > > > alan at cooper.com | www.cooper.com
> > > > All information in this message is proprietary & confidential.
> > > > "Kipling was right: leaders and talkers and theorists forget how
> they
> > > > depend on oily hands and long apprenticeships." -Libby Purves
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: discuss-bounces at lists.interactiondesigners.com
> > > > [mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
> > > > David Malouf
> > > > Sent: Tuesday, February 12, 2008 11:08 AM
> > > > To: IxDA Discuss
> > > > Subject: Re: [IxDA Discuss] Thoughts on Alan Cooper's Keynote
> > > >
> > > > hmmm?
> > > >
> > > > This is actually been shown politically to be the cause of middle
> east
> > > > conflicts, not the other way around.
> > > > It is b/c we have ignored differentiation among "similar" peoples
> that
> > > > we
> > > > end up with many many a conflict.
> > > > Acculturation and assimilation, and worse generalization, lead to
> > > > problems
> > > > such as disrespect, devaluation, and erosion.
> > > >
> > > > This is what Bill was alluding to in his little motion graphic bits.
> > > >
> > > > I think the assertion that acknowledging distinctiveness and
> > > > uniqueness
> > > > of
> > > > team members leads to prejudice feels a tad absurd.
> > > > Even if you are on "the same" team. Not all team members own all
> > > > aspects
> > > > of
> > > > the project. There are time contextual roles and responsibilities
> that
> > > > take
> > > > place fluidly throughout a project and it is through understanding
> and
> > > > acknowledging these moments or pieces that allows for smoother, more
> > > > appropriate transitions.
> > > >
> > > > This does not in any way counter the other important argument of
> > > > Bill's
> > > > about "not whining". Of course, you have to learn more about your
> > > > other
> > > > team
> > > > members and in so doing you will most likely be creating an
> > > > environment
> > > > where those same team member will want to learn more about you. But
> > > > learning, and melting into are 2 different things.
> > > >
> > > > So I stand by what I said about engineering culture vs. design
> culture
> > > > and
> > > > how that envalues or devalues agile methods.
> > > >
> > > > Maybe there is a way to integrate true design methods (not research
> > > > methods,
> > > > but design methods) into a software agile methodology, but I haven't
> > > > seen or
> > > > heard of it, nor have I really seen anyone attempt to design such a
> > > > system--one where no single culture dominates the team.
> > > >
> > > > I also think that software agile methods are based on a flawed
> > > > assumption.
> > > > That is to say, it presupposes that software is malleable and
> > > > changeable
> > > > to
> > > > such a degree where "agility" can take place. I don't believe this
> is
> > > > true
> > > > as much as people would like to think. It was the underlying flaw of
> > > > the
> > > > first bubble, where we thought web=cheaper & faster. We all learned
> > > > that
> > > > wasn't true once you hit a certain level of complexity. To do
> software
> > > > correctly requires deep strategic and tactical planning with a
> > > > holistic
> > > > and
> > > > deeply forward thinking view.
> > > >
> > > > -- dave
> > > >
> > > >
> > > >
> > > > On Feb 12, 2008 1:37 PM, Christian Crumlish <xian at pobox.com> wrote:
> > > >
> > > >> I have to agree with Jared. In fact us vs. them (no matter how
> > > >> informed by experience) treads close to prejudice very easily. One
> > > >> thing I have always loved about this digitally mediated experience
> > > >> space we work in is that it's by its very nature
> cross-disciplinary.
> > > >> It represents, in fact, a remixing of older guildlike practices.
> I'm
> > > >> wary of trying to simply redraw the lines as quickly as possible.
> > > >> That's kinda like what the English and French did in the middle
> east.
> > > >>
> > > >> -xian-
> > > >>
> > > >>
> > > >> On Feb 12, 2008 6:58 AM, Jared M. Spool <jspool at uie.com> wrote:
> > > >>>
> > > >>> WHOA!
> > > >>>
> > > >>> Us?!? THEM?!?
> > > >>>
> > > >>> There's a whole lotta us vs. them coming out these days.
> > > >>
> > > >>
> > > >> --
> > > >> Christian Crumlish http://xianlandia.com
> > > >> Yahoo! pattern detective http://developer.yahoo.com/ypatterns
> > > >> IA Institute director of technology http://iainstitute.org
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > David Malouf
> > > > http://synapticburn.com/
> > > > http://ixda.org/
> > > > http://motorola.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
> > > > ________________________________________________________________
> > > > 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
> > >
> >
> >
> >
> > --
> > David Malouf
> > http://synapticburn.com/
> > http://ixda.org/
> > http://motorola.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
> >
> ________________________________________________________________
> 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
>

--
~ will

"No matter how beautiful,
no matter how cool your interface,
it would be better if there were less of it."
Alan Cooper
-
"Where you innovate, how you innovate,
and what you innovate are design problems"
-------------------------------------------------------
will evans
user experience architect
wkevans4 at gmail.com
-------------------------------------------------------

13 Feb 2008 - 6:10am
Scott McDaniel
2007

Is this close enough to Godwin's Law to call it?

On Feb 13, 2008 5:49 AM, W Evans <wkevans4 at gmail.com> wrote:
> Manifestos are beautiful - and I can't argue with these - but it's the
> practice and process of any methodology carried out by real people that is
> all that matters. The communist manifesto was a work of literary art. Stalin
> killed 50 million people. Manifestos don't always lead to good outcomes in
> reality.
>

--
'Life' plus 'significance' = magic. ~ Grant Morrison

13 Feb 2008 - 6:49am
White, Jeff
2007

Ha!

On Feb 13, 2008 6:10 AM, Scott McDaniel <scott at scottopic.com> wrote:
> Is this close enough to Godwin's Law to call it?
>
> On Feb 13, 2008 5:49 AM, W Evans <wkevans4 at gmail.com> wrote:
> > Manifestos are beautiful - and I can't argue with these - but it's the
> > practice and process of any methodology carried out by real people that is
> > all that matters. The communist manifesto was a work of literary art. Stalin
> > killed 50 million people. Manifestos don't always lead to good outcomes in
> > reality.
> >
>
> --
> 'Life' plus 'significance' = magic. ~ Grant Morrison
>
> ________________________________________________________________
> 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
>

13 Feb 2008 - 6:58am
SemanticWill
2007

I made no reference to the nazis!

On Feb 13, 2008 6:49 AM, Jeff White <jwhite31 at gmail.com> wrote:

> Ha!
>
> On Feb 13, 2008 6:10 AM, Scott McDaniel <scott at scottopic.com> wrote:
> > Is this close enough to Godwin's Law to call it?
> >
> > On Feb 13, 2008 5:49 AM, W Evans <wkevans4 at gmail.com> wrote:
> > > Manifestos are beautiful - and I can't argue with these - but it's the
> > > practice and process of any methodology carried out by real people
> that is
> > > all that matters. The communist manifesto was a work of literary art.
> Stalin
> > > killed 50 million people. Manifestos don't always lead to good
> outcomes in
> > > reality.
> > >
> >
> > --
> > 'Life' plus 'significance' = magic. ~ Grant Morrison
> >
> > ________________________________________________________________
> > 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
> >
> ________________________________________________________________
> 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
>

--
~ will

"No matter how beautiful,
no matter how cool your interface,
it would be better if there were less of it."
Alan Cooper
-
"Where you innovate, how you innovate,
and what you innovate are design problems"
-------------------------------------------------------
will evans
user experience architect
wkevans4 at gmail.com
-------------------------------------------------------

13 Feb 2008 - 6:59am
White, Jeff
2007

On Feb 13, 2008 5:49 AM, W Evans <wkevans4 at gmail.com> wrote:
> Manifestos are beautiful - and I can't argue with these - but it's the
> practice and process of any methodology carried out by real people that is
> all that matters.

Well, that's kind of the thing. There are real interaction designers
out there inserting their culture into agile practices and making them
design centric, not engineering centric. Just because it hasn't worked
for some of us in the past doesn't mean that a blanket statement
saying any approach/value system or methodology is always bad no
matter what. There is no doubt that agile was created largely by
engineers, for engineers. The customer touchpoints within agile are
often based on weak research practices, which (and this is strictly my
opinion) encourage and maybe cause some of the change agile wants to
embrace.

I disagree with others on this list who think agile sucks just because
a bunch of designers didn't create it. It doesn't mean that as
designers, we can't be innovative, creative and insert *our* values &
culture into an existing one, to make things better for everyone
involved.

What's supremely ironic about this whole debate is that as interaction
designers, we're concerned with, well, human interactions. Yet many of
us can't seem to figure out how to interact with engineers to get the
stuff we designed implemented correctly.

Jeff

13 Feb 2008 - 8:00am
Luis de la Orde...
2007

2008/2/13, W Evans <wkevans4 at gmail.com>:
> Manifestos are beautiful - and I can't argue with these - but it's the
> practice and process of any methodology carried out by real people that is
> all that matters.

What that manifesto really means in practice:

*1. Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software. *

Customer satisfaction is definitely the aim of anything, no arguments
against it. Nevertheless, of all the things that could be chosen as
satisfaction factors how come this one in specific became the glorified
foundation of Agile development? Did we give up educating customers of the
value of planning, researching and prototyping and are trying to make our
lives easier by just conceding to the fact that many projects are built on
reaction and firefighting?

*2. Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage. *

- Thank God for all those hard-working Indians and Pakistanis working 18
hours a day to satisfy every unplanned turn of direction for two pennies an
hour.

*3. Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.*

- Again, thank God for the Indians and good riddance we are not
manufacturing cars, although the level of complexity can be the same some
times.

*4. Business people and developers must work
together daily throughout the project. *

- This is a good and logical principle although it transpires that Agile
is still a glove too small for graphical designers and front-end developers.

*5. Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done. *

- Does that include signing off hardware upgrades and software necessary to
get the job done straight away, or just tell developers and designers to use
a demo version until it expires whilst the accountancy team goes through the
process of signing off the expenses? Does motivation mean a willingness to
deliver the best of your potential or just accumulate unpaid overtime?

*6. The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation. *

- That is great when you are developing a Contact Us form or everyone is in
the same cosy room and the workload is distributed fairly and evenly amongst
the members of the team. What I have seen is that this kind of environment
generates a good amount of lack of ownership and misunderstanding.
Information doesn't get transferred evenly in all corners of the
organisation and one spends most of the time repeating the same thing to
every person they meet. Kudos if you work on the go or in an office in some
unknown dark corner of the room adn your face can only be seen every 10
days. What is with Agile companies asking you to use your own mobile phone
to take and make calls?

*7. Working software is the primary measure of progress.*

- Definitely, it doesn't matter that in the inital phase of your project,
half of your team already left the company whilst the overall turnover is as
high as the rate the planet's natural resources are being depleted. Once
again, thank God for India for providing all those young graduates every
year.

*8. Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.*

- This is cute, but what does it mean?

*9. Continuous attention to technical excellence
and good design enhances agility.*

- What??? Dude, first of all, thanks for restricting the excellence bit to
the *technical* realm, I am also taking it that we are talking about
*technical* design, but unfortunately I know one too many graphical
designers, usability engineers, front-end developers that wish their
excellence also shone amidst this technical paradise Agile seems to be (and
by the way stop telling the HTMLer that he can repurpose or refactor his CSS
as quickly as the overworked Java remunerated slaves, coz' Java is platform
independent whereas CSS and HTML are still not).

Secondly, in the real world this doesn't happen, mostly when we overworking
them to death, if you don't believe me then produce your benchmark showing
how much more usable, fast, accessible, standardised applications built with
Agile are.

*10. Simplicity--the art of maximizing the amount
of work not done--is essential.*

- Yeah, ok, it is a millennium old Zen principle. Knowing how hard
developing with Agile is, believe me, maximizing the amount of work not done
goes down very well.

*11. The best architectures, requirements, and designs
emerge from self-organizing teams.*

- If you manage to have the whole Apple engineering team or similar, yes
definitely. Nevertheless, this used to be called "virtual teams" and it was
out there even at the age of waterfall development.

*12. At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.*
- Unless it is something that is outside the scope, in this case if the
darned thing works that will do. Most of the time, the team reflects how
their lives have become a sleep-deprived journey, wondering how their kids
are and how to make the current project look good in a CV. Sometimes they
will reflect on why the IA is delaying them with those wireframes and user
c**p.

Luis

13 Feb 2008 - 8:45am
Luis de la Orde...
2007

> What's supremely ironic about this whole debate is that as interaction
> designers, we're concerned with, well, human interactions. Yet many of
> us can't seem to figure out how to interact with engineers to get the
> stuff we designed implemented correctly.
>
> Jeff
>

Hi Jeff, I don't think the issue revolves around a communication problem
with developers only and whether a project has taken Agile or the Waterfall
approach. It is about how well the project is implemented in first place,
how skilled the team is and how busy they are. If these factors are
mismatched there is no approach that will be more UxD friendly than the
other. Add a bit of internal politics from either the client's side or ours
and then things start to get a bit more like they are.

I believe that Agile does indeed have the theoretical frame that makes more
sense for the client, it is the practice of it that is still short to prove
it is effective in large teams, crossing expertise areas.

I really don't buy methodologies, but I buy people who get them done well
and effectively.

Cheers,

Luis

13 Feb 2008 - 8:46am
Scott McDaniel
2007

This is all getting petty and silly.

Without experience, I can see how the Agile bit doesn't map fully to a
desirable design process.
I'm a bit flummoxed by the bit-by-bit hostility and unwillingness to
heed the wise words of Egg Chen:
"We take what we like and leave the rest...like your salad bar!"

I frequent gaming forums...I know unproductive snippiness!

Is there nothing to be gained or learned from Agile, at least in the
critique of the development process?

Scott

--
'Life' plus 'significance' = magic. ~ Grant Morrison

13 Feb 2008 - 2:38pm
Christopher Fahey
2005

On Feb 12, 2008, at 3:53 PM, Alan Cooper wrote:
>> I'd love to hear what people think of this approach, especially if
>> you've tried something like it. I'm pretty confident in it, at least
>> for now.
>
>
> Christopher,
>
> Which one do you throw away?
>
> Thanx,
> Alan

I wouldn't throw any of them away. I'm not sure what you're asking, I
guess.

-Cf

Christopher Fahey
____________________________
Behavior
biz: http://www.behaviordesign.com
me: http://www.graphpaper.com

13 Feb 2008 - 2:59pm
Christopher Fahey
2005

Peirre Roberge wrote:
>> 2) Engineering-Focused (4 months): Agile programming team develops
>> the product using the prototype as a target, with occasional light
>> input from the design team but mostly focusing on solving and
>> innovating tech solutions. ****Expose the development product
>> regularly to a small user test base and collect feedback.****
>> Meanwhile, the design team begins conceptualizing the version 2.0
>> product.
>
>
> My question:
> Could you tell me more about the type of feedback the developers
> were getting from the users to which they were showing the product
> being developed?

It was primarily feature and usability feedback (not bug or
performance testing, if that's what you're asking, although that was
happening too). We learned more about what they found useful and not
useful, what they understood conceptually and what was confusing,
patterns of usage and learning. Things that influence the product and
UX design itself.

Anjali R Arora wrote:
> This does sound like a dream project: getting 4 months to research
> & design!

The way I see it, this is an ideal process even from an economic
point of view: The customer gets to play a key role in influencing
exactly what they're going to get before any coding is done -- they
can actually see a simulation of the final product months ahead of
time -- without having to deal with a lot of "but we can't do that"
backtalk from the programmers ;-). The prototype can be used to earn
additional buy-in, feedback, and funding in the organization.
Usability testing can be done on a prototype. And the engineers don't
have a lot of abstract "requirements" to either collect or to try to
fulfill. The extra time planning the UX saves tons of coding and
testing time later.

W Evans wrote:
> My baggage? I have gone to 2 conferences and have has 3 all day
> workshops on
> Agile + UCD. My money would have been better spent on Beer. All
> were either
> conducted by either Agile centric software architects with little
> or no
> understanding or experience with real UCD - another was from a UCD
> guru who
> lectured for a day on the process - but had never actually been the UX
> Architect on an Agile project.

Hear hear. Many tech-focused Agile people think Agile+UXD means "hire
a good designer to slap a UI on the product at the end", while much
of the UX-focused literature is "it would be great if I someday had a
chance to help those poor Agile developers".

-Cf

Christopher Fahey
____________________________
Behavior
biz: http://www.behaviordesign.com
me: http://www.graphpaper.com

13 Feb 2008 - 4:23pm
Christopher Fahey
2005

J. Ambrose Little wrote:
> What I see here in terms of what is disliked about agile is this
> perceived concept that agile means lack of coherent design. I
> shudder to
> think of anyone ("engineer" or "designer") jumping headfirst into a
> project
> without any sort of coherent vision that has at least been fleshed
> out at a
> high level. I hope we can all agree that this is bad.
> I suggest you take a look at Scott Ambler's Agile Modeling site;
> this is a
> good intro <http://www.agilemodeling.com/essays/
> initialArchitectureModeling.htm>
> to how initial modeling fits in. (Ambler is about the most
> authoritative you
> can get with agile, so if you want to gain an understanding of what
> agile
> "should" be, he's a good source.) You'll note that he includes UI
> design in
> this up front modeling (calls it UI flow models). That's where it
> seems interaction designers would do well to plug in to do their up
> front
> modeling. Then as you go through the iterations, you flesh out and
> refactor
> your designs along with the engineers.

Applying the "design-it-first" philosophy to Agile seems to be a
recent, and happy, development, but it is not part of Agile's core DNA.

Much of the canonical Agile literature, unfortunately, still
recommends this process:
1) Gather requirements while coding the product.
2) Slap on a UI

Even the "initial modeling" article you link to seems to be written
for an audience for whom a "plan it first" process is abnormal. Most
of the planning it recommends is technical, not UX focused. With one
excellent exception: The following paragraph is one of the funniest
development understatements I've read in a while, and while it is
written for an audience who apparently doesn't already understand the
importance of UX, it does make a strong and simple case:

> "...you will architect the UI of your system by exploring the flow
> between major UI elements, including both screens/pages and
> reports. This is critical to your system's success because the
> user interface is the system to your stakeholders. Not the
> technology. Not the data. Not really cool frameworks that you're
> working with. If you do not architect the user interface
> effectively you run the risk that you will build a system that your
> stakeholders aren't interested in working with. "

When working with an Agile team, or reading Agile literature, it's
important to determine if when they say "design" they mean UX design
or tech design, because usually they will mean the latter.

-Cf

Christopher Fahey
____________________________
Behavior
biz: http://www.behaviordesign.com
me: http://www.graphpaper.com

13 Feb 2008 - 7:54pm
Luis de la Orde...
2007

Hi Scott,

The point that seemed to have been highlighted was that user experience
processes have happened successfully in Waterfall projects in the past, and
although Agile has a flexible frame that is theoretically ideal for
inserting UxD processes, if badly implemented will generate the same
constraints as badly implemented Waterfall projects.

Unfortunately, in some professional projects it is not a question of only
picking and choosing what works for you or not, mostly when you are one of
the other 100 guys putting together a massive booking system in several
languages, with the added pressure that at the end of the iteration the
system has to be valued high enough to be sold to a financial group. What is
chosen to be the method is what one has to follow (including the priority
that has been assigned for accessibility, web standards and HCI).
Unfortunately in real life not everyone can take the ideal, one-sided stand
as not every project is as simple as a salad.

Cheers,

Luis

13 Feb 2008 - 8:38pm
Charlie Kreitzberg
2008

Just a brief comment about "agile vs waterfall."

I don't think that the distinction is always as clear as one might
think.

Often projects have a waterfall structure within which you can have
agile moments.

For example, an (oversimplified) product development framework might
look like a waterfall structure:

1. business case
2. design
3. build
4. release

but the design phase might be highly agile.

In addition, while the structure above shows a single design phase,
there are likely to be design elements in all the phases.

Charlie

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=25686

13 Feb 2008 - 10:32pm
Scott McDaniel
2007

I get that, really, and never meant to indicate that I'd expect
anything to be universally applicable
- even or especially my salad bar quote. Especially in this Real
World thing people keep
telling me about.

I felt the distinction was being stated in fairly absolutist terms, and wanted
to ask for things that could possibly be drawn from the methodology, and
applied. While I know there are distinct reasons for processes and methods,
I couldn't see why lessons couldn't be learned from disparate or even
opposing sources -
I draw inspiration for design from sculpture, food recipes from music and the
world would seem a shallow place to me if we couldn't look at the stars
and see gods.

Folks on the list have been cool enough to go further with their ideas, even if
not changing their positions. It's all I wanted for my satisfaction,
as well as
for my imaginary constituency.

Scott
(tried to clip as much as I could and keep context, dear listserv)

On Feb 13, 2008 7:54 PM, Luis de la Orden Morais <luis at webalorixa.net> wrote:
> Hi Scott,
...
> Unfortunately, in some professional projects it is not a question of only
> picking and choosing what works for you or not, mostly when you are one of
> the other 100 guys putting together a massive booking system in several
> languages, with the added pressure that at the end of the iteration the
> system has to be valued high enough to be sold to a financial group. What is
> chosen to be the method is what one has to follow (including the priority
> that has been assigned for accessibility, web standards and HCI).
> Unfortunately in real life not everyone can take the ideal, one-sided stand
> as not every project is as simple as a salad.
...

--
'Life' plus 'significance' = magic. ~ Grant Morrison

16 Feb 2008 - 7:10pm
Luis de la Orde...
2007

Aha! Thanks Charlie, I believe this is what I have seen, you distilled the
idea very well.

Luis

===========================
Charlie Kreitzberg said

For example, an (oversimplified) product development framework might
look like a waterfall structure:

1. business case
2. design
3. build
4. release

but the design phase might be highly agile.

In addition, while the structure above shows a single design phase,
there are likely to be design elements in all the phases.

Syndicate content Get the feed