Thoughts on Alan Cooper's Keynote

10 Feb 2008 - 1:08am
6 years ago
65 replies
1816 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

10 Feb 2008 - 1:57am
Troy Gardner
2008

>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

Not completely, Even in the most bleeding edge, there are very few
designs that aren't built out of simpler existing interaction
parts/patterns (I call flows, as it's like a workflow but also implies
the flow state in the user when carried out effectively).

iXD is particularly challenging as it's success isn't as quantifiable
as other fields. Good design just 'feel's right, and in the flow state
people aren't paying attention and therefore can't describe it. I work
in a company know where people desire it's end goals, but don't know
the first thing about what it is that I'm doing or is called, .
Especially in cross media, going from one site, to another, to a
download to an install, to a first run etc. They actually think
creative/graphical design + marketing driven, instead of user flows.

After spending about 10 years designing applications I've come to the
conclusion that most pipelines are setup completely wrong. In
creative agencies they have graphic design be the primary. In tech
companies the tech's become the lead, in business lead it's about
feature competitiveness. Which leads to either super rich designs that
are beautiful to look at but typically keyholed with a completely
unuseable scrollbar, or a super complicated product that makes perfect
sense to the designer..but doesn't reflect any customer. Or features
for the sake of competitive comparions rather than what features
people may actually the market's need...while I know Photoshop+Word,
honestly I find paint and notepad more useful on a normal basis.

Just as it's silly to organize a banquet until one know how many
people are coming, it's silly to design graphics prior to getting
wireframes solid, and that can't happen without understanding the
interactives (that which is hidden in time and doesn't far well on
paper), and the dimensionality of the underlying data (requiring
IA...another field that most companies don't know they need on
projects).

10 Feb 2008 - 8:31am
SemanticWill
2007

To Paraphrase Alan "First to market is NOT best to market - business
managers only know first to market." He also touched upon the idea
that business managers understand the metric of "first to market"
but have no means of measuring ROI for design - which is why our jobs
are so tough. If Alan read our list here - he would have seen our
discussion about this and might have even read my reference to the
Adaptive Path report on ROI of User Experience. I wish he had read
that!

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

10 Feb 2008 - 5:26pm
Alan Cooper
2004

Will,

It's unclear to me that there is an advantage to describing our value
in terms of ROI, which is, after all, an industrial age term used to
describe the advantages of upgrading one's industrial processes. It is
not necessarily a useful metric for measuring post-industrial business
success. ROI measures efficiency and, as Peter Drucker points out,
efficiency is no longer a very effective measurement of the success of a
business.

I'm sure that it is possible to gather up a sufficiency of numbers (we
have nothing if not a sufficiency of numbers) to generate a claim for
"ROI", but then it exposes our work to attack and deconstruction on that
same basis. Maybe that's not such a good bargain.

In software, there is simply no reliable relationship between what you
spend on building it and what value you get. The appropriate measure is
quality out, not investment in.

Thanx,
Alan

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
Will Evans
Sent: Saturday, February 09, 2008 9:31 PM
To: discuss at ixda.org
Subject: Re: [IxDA Discuss] Thoughts on Alan Cooper's Keynote

To Paraphrase Alan "First to market is NOT best to market - business
managers only know first to market." He also touched upon the idea
that business managers understand the metric of "first to market"
but have no means of measuring ROI for design - which is why our jobs
are so tough. If Alan read our list here - he would have seen our
discussion about this and might have even read my reference to the
Adaptive Path report on ROI of User Experience. I wish he had read
that!

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

________________________________________________________________
*Come to IxDA Interaction08 | Savannah*
February 8-10, 2008 in Savannah, GA, USA
Register today: http://interaction08.ixda.org/

________________________________________________________________
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

10 Feb 2008 - 8:51pm
Oleh Kovalchuke
2006

> In software, there is simply no reliable relationship between what you
> spend on building it and what value you get. The appropriate measure is
> quality out, not investment in.

"Quality of experience out" is "investment in" to rephrase Warren Buffet:
http://www.youtube.com/watch?v=caFD7bwkuEc

What are the ways to demonstrate the quality of interaction?

--
Oleh Kovalchuke
Interaction Design is the Design of Time
http://www.tangospring.com/IxDtopicWhatIsInteractionDesign.htm

On Feb 10, 2008 3:26 PM, Alan Cooper <Alan at cooper.com> wrote:
> Will,
>
> It's unclear to me that there is an advantage to describing our value
> in terms of ROI, which is, after all, an industrial age term used to
> describe the advantages of upgrading one's industrial processes. It is
> not necessarily a useful metric for measuring post-industrial business
> success. ROI measures efficiency and, as Peter Drucker points out,
> efficiency is no longer a very effective measurement of the success of a
> business.
>
> I'm sure that it is possible to gather up a sufficiency of numbers (we
> have nothing if not a sufficiency of numbers) to generate a claim for
> "ROI", but then it exposes our work to attack and deconstruction on that
> same basis. Maybe that's not such a good bargain.
>
> In software, there is simply no reliable relationship between what you
> spend on building it and what value you get. The appropriate measure is
> quality out, not investment in.
>
> Thanx,
> Alan
>
>
> -----Original Message-----
> From: discuss-bounces at lists.interactiondesigners.com
> [mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
> Will Evans
> Sent: Saturday, February 09, 2008 9:31 PM
> To: discuss at ixda.org
> Subject: Re: [IxDA Discuss] Thoughts on Alan Cooper's Keynote
>
> To Paraphrase Alan "First to market is NOT best to market - business
> managers only know first to market." He also touched upon the idea
> that business managers understand the metric of "first to market"
> but have no means of measuring ROI for design - which is why our jobs
> are so tough. If Alan read our list here - he would have seen our
> discussion about this and might have even read my reference to the
> Adaptive Path report on ROI of User Experience. I wish he had read
> that!
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=25686
>
>
> ________________________________________________________________
> *Come to IxDA Interaction08 | Savannah*
> February 8-10, 2008 in Savannah, GA, USA
> Register today: http://interaction08.ixda.org/
>
> ________________________________________________________________
> 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
> ________________________________________________________________
> *Come to IxDA Interaction08 | Savannah*
> February 8-10, 2008 in Savannah, GA, USA
> Register today: http://interaction08.ixda.org/
>
> ________________________________________________________________
> 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
>

10 Feb 2008 - 9:44pm
Jenifer Tidwell
2003

Alan, I don't know about your clients, but mine have finite budgets. :-)

Call it ROI, or call it something else, but they still need to figure
out where to draw the line on UI spending. Certain features (pages,
widgets, points of interaction, etc.) are worth building, to get the
user experience up to a minimum quality -- and the rest just aren't
going to be worth it.

I'm not going to tell the one-person craft business that she needs to
spend $10,000 on an ecommerce site redesign if it's not going to earn
her that much in extra business (even though the current site
experience is mediocre). That's an ROI calculation by my definition.
And maybe that assessment doesn't lead to new business for me or any
other UX folk, but I have to be honest with my clients.

Am I misunderstanding you? My apologies for not having the full
context of your remarks; I was unable to go to Savannah this week, so
I didn't hear your keynote. (Sigh.)

- Jenifer

On 2/10/08, Alan Cooper <Alan at cooper.com> wrote:
> Will,
>
> It's unclear to me that there is an advantage to describing our value
> in terms of ROI, which is, after all, an industrial age term used to
> describe the advantages of upgrading one's industrial processes. It is
> not necessarily a useful metric for measuring post-industrial business
> success. ROI measures efficiency and, as Peter Drucker points out,
> efficiency is no longer a very effective measurement of the success of a
> business.
>
> I'm sure that it is possible to gather up a sufficiency of numbers (we
> have nothing if not a sufficiency of numbers) to generate a claim for
> "ROI", but then it exposes our work to attack and deconstruction on that
> same basis. Maybe that's not such a good bargain.
>
> In software, there is simply no reliable relationship between what you
> spend on building it and what value you get. The appropriate measure is
> quality out, not investment in.
>
> Thanx,
> Alan
>
> -----Original Message-----
> From: discuss-bounces at lists.interactiondesigners.com
> [mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
> Will Evans
> Sent: Saturday, February 09, 2008 9:31 PM
> To: discuss at ixda.org
> Subject: Re: [IxDA Discuss] Thoughts on Alan Cooper's Keynote
>
> To Paraphrase Alan "First to market is NOT best to market - business
> managers only know first to market." He also touched upon the idea
> that business managers understand the metric of "first to market"
> but have no means of measuring ROI for design - which is why our jobs
> are so tough. If Alan read our list here - he would have seen our
> discussion about this and might have even read my reference to the
> Adaptive Path report on ROI of User Experience. I wish he had read
> that!
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=25686
>
>
> ________________________________________________________________
> *Come to IxDA Interaction08 | Savannah*
> February 8-10, 2008 in Savannah, GA, USA
> Register today: http://interaction08.ixda.org/
>
> ________________________________________________________________
> 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
> ________________________________________________________________
> *Come to IxDA Interaction08 | Savannah*
> February 8-10, 2008 in Savannah, GA, USA
> Register today: http://interaction08.ixda.org/
>
> ________________________________________________________________
> 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
>

--
---------------------------------------
Jenifer Tidwell
jenifer.tidwell at gmail.com
http://designinginterfaces.com
http://jtidwell.net

11 Feb 2008 - 9:15am
Todd Warfel
2003

On Feb 10, 2008, at 5:26 PM, Alan Cooper wrote:

> [...] ROI measures efficiency and, as Peter Drucker points out,
> efficiency is no longer a very effective measurement of the success
> of a business.

If the traditional view on ROI is a measure of efficiency, then we
need to change that. I would agree that simply measuring efficiency is
not accurate for software and I've got dozens of case studies to show
that.

For me, ROI, when it comes to software, should be measured with a
number of variables, including: increased performance of the user,
decreases in error, decreases in cost, increases in revenues, etc.

When we redesign software, websites, and webaps, we establish some
initial baseline measurements for transaction processes based on time,
effort, and satisfaction. We measure the redesigned model based on
these same metrics. This is how we generally determine ROI. If it's a
site based on advertising revenues from page views, then we measure
based on these previous measurements and include things like a
reduction in the number of steps to complete the process and overall
increase in page views.

> In software, there is simply no reliable relationship between what
> you spend on building it and what value you get. The appropriate
> measure is quality out, not investment in.

While I agree with this in theory, in reality most of the businesses
we work with are still concerned about the bottom line and do
appreciate showing ROI. I don't think we can always show ROI, but when
we are able to, which is most of the time based on the variables I
discussed above, there's a great deal of satisfaction from everyone
involved.

If I'm building for myself, I'm less concerned about measuring ROI—I'm
more focused on my actual satisfaction with the end quality. When I'm
building/designing for a client, I keep their business model and goals
in mind along with a number of customer/user variables including
behavior, goals, pain points, etc. and use those to try and determine
some kind of success metric.

Cheers!

Todd Zaki Warfel
President, Design Researcher
Messagefirst | Designing Information. Beautifully.
----------------------------------
Contact Info
Voice: (215) 825-7423
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

10 Feb 2008 - 1:36pm
Lukeisha Carr
2007

This is all very interesting. I have always been a part of the
waterfall development methodology, where there is (ANALYSIS, DESIGN,
development, QA, then production). In the analysis & design phase,
that was where interaction & visual designs were created &
communicated. Overall consistency of the look & feel, and the
determination of workflow & reusable screens & components where
discussed.

However, now, there are development methodologies like Scrum & XP,
where significant amounts of time has been lopped off in the sake of
FAST development & deployment, and the analysis & design has been
lopped off with it. The screen designs are done at the developer's
desk in the simplest possible way to get the piece coded as fast as
possible. And one recent experience that I've had was a company
that used the Scrum method. They deployed a product that had very
little consistancy. Lists that provided the same or very similar
data were displayed differently throughout the app. Functionality
that was supposed to be the same was conducted in various ways in
different areas of the app, and more. But that wasn't their first
concern. Their first concern was getting the "major" new &
enhanced functionality out to their users. Basically, regardless of
how hard or how many steps it takes, it is "able" to do this for
you.

In light of what this post's concern regarding including proper IxD,
it seems it will be quite tough to convince business/product managers
that more steps & time need to be added, when just recently, they
have come up with ways to cut those very items down/out. How do
IxDer's go about reversing that way of thinking?

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

11 Feb 2008 - 6:07pm
ambroselittle
2008

Hi Lukeisha,

I'd suggest (as a software architect on an agile team that incorporates UX
process) that you don't need waterfall to build good UX. In fact, one of
the core aspects of UX--delivering what the users need--can be better
assured through agile process (IMO).

You need to plug the UX pros into the agile process. Have your UX folks
work with the devs throughout the process, just like they're working with
the domain experts and other business interests. If interface design needs
to be refactored as part of the process, you guys should be there.

Agile does not equate to anarchy. The chief goal of Agile is less
to get RAD and more to build quality software that actually succeeds,
actually meets the business needs. Agile also does not mean you do no
design--the design is baked into the process. You do a lot less up-front,
monolithic design, yeah, but that by no means equates to no design.

In short, I wouldn't generalize too much from your experience on the project
you mention. It sounds like that org has other problems based on your
description, such as lack of understanding of agile and/or the importance of
UX in general.

--Ambrose

J. Ambrose Little
UXG Lead & Codemunicator
infragistics.com
On Sun, 10 Feb 2008 10:36:28, lukeisha carr <lukeisha.carr at yahoo.com> wrote:

> This is all very interesting. I have always been a part of the
> waterfall development methodology, where there is (ANALYSIS, DESIGN,
> development, QA, then production). In the analysis & design phase,
> that was where interaction & visual designs were created &
> communicated. Overall consistency of the look & feel, and the
> determination of workflow & reusable screens & components where
> discussed.
>
> However, now, there are development methodologies like Scrum & XP,
> where significant amounts of time has been lopped off in the sake of
> FAST development & deployment, and the analysis & design has been
> lopped off with it. The screen designs are done at the developer's
> desk in the simplest possible way to get the piece coded as fast as
> possible. And one recent experience that I've had was a company
> that used the Scrum method. They deployed a product that had very
> little consistancy. Lists that provided the same or very similar
> data were displayed differently throughout the app. Functionality
> that was supposed to be the same was conducted in various ways in
> different areas of the app, and more. But that wasn't their first
> concern. Their first concern was getting the "major" new &
> enhanced functionality out to their users. Basically, regardless of
> how hard or how many steps it takes, it is "able" to do this for
> you.
>
> In light of what this post's concern regarding including proper IxD,
> it seems it will be quite tough to convince business/product managers
> that more steps & time need to be added, when just recently, they
> have come up with ways to cut those very items down/out. How do
> IxDer's go about reversing that way of thinking?
>
>
>

11 Feb 2008 - 9:06pm
Dave Malouf
2005

At the postmortem dinner for the conference on sunday night. Myself &
Greg Petroff when off on a debate about Agile being good or bad. I
find it interesting that BOTH of our pre-eminent keynotes are both
talking down agile, YET we as a UX community believe it is still
valuable. Yikes! It screams to me the horrible influences we have
been forced to assimilate towards (taking some of Bill's juices and
running with it) around being under the thumb of engineering all
these decades.

Through the discussion what became clear was that the term
"waterfall" is associated with RUP (or RUP like processes) and for
some reason is equated to "documentation". However, the meaning of
waterfall to me means ... define before build as per Bill's
discussion. Know what you are doing before you green light spending
production dollars. What follows that design period does not need to
be reams of useless and often mindless paper.

On another point.
I really disagree with this:

> In fact, one of the core aspects of UX%u2014delivering
> what the users need%u2014can be better assured through
> agile process (IMO) .

B/c I think it shows a lack of understanding to what UX is all
about--telling a story. A lot of people have already highlighted
"story telling" as a major theme of the conference and I couldn't
agree more, but the way to creatively write a story, or create a
drama, or event, is to do it through deconstruction. I never really
understood what that meant till this conference, and this
conversation, but for now at least, it means for me, that I create a
vision and then deconstruct it through value statements and other
criteria used to make choices.

The example is ... The theatrical version of a movie vs. a
director's cut. Almost always in process, the director's cut is
made first and then it is cut down to fit the theater.

If I just build in iterations, there is never a whole, guiding light
or prototype from which I can cut away at.

It seems that unless there is a distinct design phase where this
visioning process can happen owned by design for design with
collaboration and consultation from engineering and business, we are
NOT *designing* user experiences, but just building them.

Now, Agile development processes seem GREAT after designs are "green
lighted". There are lots of advantages to engineers in those
processes, but assimilating to them seems like a grave mistake at
this point to me.

- dave

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

12 Feb 2008 - 2:15am
White, Jeff
2007

Out of curiosity, have you or Greg ever practiced agile? Not trying to
be a pain, but really would like to hear what your experience was if
so.

Also, one of the sponsors of Interaction08, Autodesk, has been
designing award winning user experiences in a very complex product
space with agile for more than half of a decade. It can work, and it
can fail, just like any other process/approach/methodology. They also
enjoy a really positive and happy work environment, and have very
little turnover. I've had the opportunity to meet & collaborate with
Lynn Miller and Desiree Sy - both interaction designers at Autodesk,
and they are really doing great design work.

What's interesting is that in both of those keynotes, the relationship
between designers and engineers was also highlighted. Even when there
is time for deconstruction as you mention, that doesn't mean it
actually gets built and implemented in the right way. I'm sure this is
very different across different types of organizations - boutique
design shops vs corporate workplaces comes to mind. My experience with
agile has been that if you embrace certain aspects of it, you can
really improve that relationship. I've worked in waterfall and I have
worked in agile. Quite frankly, each one has its pros and cons. I feel
part of our job as designers is to accept that there will be always be
less than perfect situations, and learn how to deal with them in
innovative and positive ways that result in good user experiences.

As a shameless plug, Jim Ungar and I presented on just this Sunday
afternoon. I disagree with you that user experiences are not being
designed, but just built when it comes to agile. There are ways to do
real design in agile - incorporating user research, concept ideation,
exploration & critique, and true iteration based on things like
usability testing and design leadership. It just requires letting go
of some old practices and embracing new ones.

Jeff

On Mon, 11 Feb 2008 18:06:15, dave malouf <dave at ixda.org> wrote:
> At the postmortem dinner for the conference on sunday night. Myself &
> Greg Petroff when off on a debate about Agile being good or bad. I
> find it interesting that BOTH of our pre-eminent keynotes are both
> talking down agile, YET we as a UX community believe it is still
> valuable. Yikes! It screams to me the horrible influences we have
> been forced to assimilate towards (taking some of Bill's juices and
> running with it) around being under the thumb of engineering all
> these decades.
>
> Through the discussion what became clear was that the term
> "waterfall" is associated with RUP (or RUP like processes) and for
> some reason is equated to "documentation". However, the meaning of
> waterfall to me means ... define before build as per Bill's
> discussion. Know what you are doing before you green light spending
> production dollars. What follows that design period does not need to
> be reams of useless and often mindless paper.
>
> On another point.
> I really disagree with this:
>
> > In fact, one of the core aspects of UX%u2014delivering
> > what the users need%u2014can be better assured through
> > agile process (IMO) .
>
> B/c I think it shows a lack of understanding to what UX is all
> about--telling a story. A lot of people have already highlighted
> "story telling" as a major theme of the conference and I couldn't
> agree more, but the way to creatively write a story, or create a
> drama, or event, is to do it through deconstruction. I never really
> understood what that meant till this conference, and this
> conversation, but for now at least, it means for me, that I create a
> vision and then deconstruct it through value statements and other
> criteria used to make choices.
>
> The example is ... The theatrical version of a movie vs. a
> director's cut. Almost always in process, the director's cut is
> made first and then it is cut down to fit the theater.
>
> If I just build in iterations, there is never a whole, guiding light
> or prototype from which I can cut away at.
>
> It seems that unless there is a distinct design phase where this
> visioning process can happen owned by design for design with
> collaboration and consultation from engineering and business, we are
> NOT *designing* user experiences, but just building them.
>
> Now, Agile development processes seem GREAT after designs are "green
> lighted". There are lots of advantages to engineers in those
> processes, but assimilating to them seems like a grave mistake at
> this point to me.
>
> - dave
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=25686
>
>
> ________________________________________________________________
>
> 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
>

12 Feb 2008 - 7:38am
Mark Schraad
2006

What is rarely said explicitly, is that agile is a development
process. It borrows heavily from design in its use of iterations,
early prototypes and review cycles. This becomes pretty apparent when
you speak to agile consultants, who lately have found that, and I
quote, "our clients really like it when we pair design on the front
end with our process".

Mark

On Feb 12, 2008, at 2:15 AM, Jeff White wrote:

> There are ways to do
> real design in agile - incorporating user research, concept ideation,
> exploration & critique, and true iteration based on things like
> usability testing and design leadership

12 Feb 2008 - 9:43am
Dave Malouf
2005

Wow! where to begin here.

Jeff,
Yup, I've had way too many hours in agile. Yup, they could definitely run
better and they can produce results. I'm not saying that they can't produce.

Mark hit it on the head, it is a developer/engineering inspired and valued
process. It is for THEM! It is not about us, for us, by us, or valuable to
us. This is my #1 issue with agile. And all the things you say below about
getting design into agile, are hacks! They are not the best of what we can
do, but what we can do in THEIR framework.

Yes, I've done research, I've done sketching, I've done all the design you
can in an agile framework.
When it's worked best is when I did it before the product development team
launched their agile program and then integrated my validation cycles into
iteration periods.

I also think that we might have different ideas about what design is or
isn't. Design is cultural to me. not in the sense that it is culturally
relative, which it is, but in the sense that design has its own culture.
That culture if you will is part of the value (and values) that it brings
into the world and when you try to force it into another cultural model, you
are degrading its value.

Your laundry list of tasks, itself, speaks to that degradation. What I do as
a designer is not a list of tasks. It is much more than that list, but is
part of a whole and part of a relationship with others who are focused on
that whole.

Bill's talk this weekend (I can't wait for people to see it), shored up my
zeal in this regard so much more.

Unless you can first see the whole of what you are building, you shouldn't
start building.

As for Autodesk. Fine company, great sponsor. I don't know much of their
software, but when you say "success" you have to say what you mean. I know
for my part that I would never put Autodesk in the same league when it comes
to design as say Um! Apple, BMW, EA, Google, Lexus, IDEO, frog, etc. (though
many of those companies use Autodesk products).

As I said in my first post. Story telling is really important. Modeling a
whole including its production, distribution and evaluation really needs air
to happen.

-- dave

On Feb 12, 2008 7:38 AM, mark schraad <mschraad at gmail.com> wrote:

> What is rarely said explicitly, is that agile is a development process. It
> borrows heavily from design in its use of iterations, early prototypes and
> review cycles. This becomes pretty apparent when you speak to agile
> consultants, who lately have found that, and I quote, "our clients really
> like it when we pair design on the front end with our process".
> Mark
>
>
> On Feb 12, 2008, at 2:15 AM, Jeff White wrote:
>
> There are ways to do
>
> real design in agile - incorporating user research, concept ideation,
>
> exploration & critique, and true iteration based on things like
>
> usability testing and design leadership
>
>
>

--
David Malouf
http://synapticburn.com/
http://ixda.org/
http://motorola.com/

12 Feb 2008 - 9:58am
Jared M. Spool
2003

On Feb 12, 2008, at 9:43 AM, David Malouf wrote:

> Mark hit it on the head, it is a developer/engineering inspired and
> valued
> process. It is for THEM! It is not about us, for us, by us, or
> valuable to
> us. This is my #1 issue with agile. And all the things you say
> below about
> getting design into agile, are hacks! They are not the best of what
> we can
> do, but what we can do in THEIR framework.

WHOA!

Us?!? THEM?!?

There's a whole lotta us vs. them coming out these days.

While our own research on what makes successful experiences is still
young and rough around the edges, one strong pattern that emerged
immediately was that the most successful teams are actually TEAMS.
None of this "They don't get it" and "We need a process that works
for us" stuff.

I'd be real careful promoting this us vs. them sentiment. I don't see
it leading to long term successful design practices.

Just sayin'

Jared

Jared M. Spool
User Interface Engineering
510 Turnpike St., Suite 102, North Andover, MA 01845
e: jspool at uie.com p: +1 978 327 5561
http://uie.com Blog: http://uie.com/brainsparks

12 Feb 2008 - 10:01am
Mark Schraad
2006

---------- Forwarded message ----------
From: mark schraad <mschraad at gmail.com>
Date: Feb 12, 2008 10:00 AM
Subject: Re: [IxDA Discuss] Thoughts on Alan Cooper's Keynote
To: David Malouf <dave at ixda.org>

On Feb 12, 2008 9:43 AM, David Malouf <dave at ixda.org> wrote:

> Design is cultural to me. not in the sense that it is culturally
> relative, which it is, but in the sense that design has its own culture.
> That culture if you will is part of the value (and values) that it brings
> into the world and when you try to force it into another cultural model,
> you
> are degrading its value.
>

Bamm... absolutely. And I will take culture over a specific process any
time.

>
> Bill's talk this weekend (I can't wait for people to see it), shored up my
> zeal in this regard so much more.
>

Can't wait. I have been reading nearly everything I can find from Bill (a
slight exaggeration as he written a LOT) in the last few weeks. Great stuff.
He nicely blends strategy, design, business, brand and about 10 other things
in his 'sketching' book. The title is deceiving and frankly, kept me from
reading it until now.

12 Feb 2008 - 10:46am
jrrogan
2005

Not being privvy to the IxDA Summit and Keynote speakers, I think Agile can
work very well with Design embedded in, and I've worked in 4 places that did
it welll and 2 that did it like crap.

The companies that did it well were not "Agile Maniacs", meaning they took
what worked with the process and modified it where necessary. The companies
that failed were dogmatic to Agile process, (Scrum can be incredibly
inflexible).

Most, (all?), of the Agile processes I worked in were Engineering centric,
and had little to no formal integration with design, but that doesn't mean
design couldn't be easily gimmy'd in the process.

Successes I've experienced are when design was done as follows, (lets say
it's a new enterprise app):

1. Rough the "Big Picture" UI/UX in totality - (generalizing
functionality/guestimate what will probably be needed) - Pre Agile

2. Create template libraries of the usual "Interface Widget Suspects" - Pre
Agile

3. Use these libraries in/imedaitely after "Feature/Req" discovery meetings,
to rapidly prototype - focus on interations during Agile, (most of the time
your one iteration ahead of engineering)

4. Work with engineering to negotiate delta's as the build is rolling - In
the thick of Agile

Are these 4 steps "Agile"? Who cares, it works well with Agile in my
experience. Note the "Upfront" steps 1 and 2 are often done while Agile is
rolling, as GUI teams often have a little wiggle room upfront when
"Architecture Eng" issues are being worked out, which generally take the
first few iterations, leaving the GUI alone for a bit.

All in all design can jump on the Agile bandwagon, and be a good team
player, one key ingredient is the rest of the team needs to be flexible as
to the inherent baggage design brings with it.

--
Joseph Rich Rogan
President UX/UI Inc.
http://www.jrrogan.com

12 Feb 2008 - 10:53am
Dave Malouf
2005

Jared,

Teams does not mean same.
Unique contributions and respect of individuality is in my experience a core
success criteria for cross-functional teams.

Understanding differences of culture, process, methods, thinking, theory,
language, etc. is required.
Being that they currently set the tone, they are pretty well understood by
us (that is my take). What is not well understood, is them of us. And for
that matter from conversations like these us of us.

I loved the historical perspectices of Chris Bernard's and Bill Buxton's
talks. We need more of that. Maybe you can help. ;-)

But I do believe that uniqueness is something to be cherished and while we
work towards common goals we need to respect and understand and envalue our
differences. There is a distinct US and a distinct THEM and to deny that,
feels fake to me.

Kumbaya is not going to get us anywhere, especially in terms of this
discussion.

-- dave

On Feb 12, 2008 9:58 AM, Jared M. Spool <jspool at uie.com> wrote:

>
> On Feb 12, 2008, at 9:43 AM, David Malouf wrote:
>
> Mark hit it on the head, it is a developer/engineering inspired and valued
>
> process. It is for THEM! It is not about us, for us, by us, or valuable to
>
> us. This is my #1 issue with agile. And all the things you say below about
>
> getting design into agile, are hacks! They are not the best of what we can
>
> do, but what we can do in THEIR framework.
>
>
> WHOA!
>
> Us?!? THEM?!?
>
> There's a whole lotta us vs. them coming out these days.
>
> While our own research on what makes successful experiences is still young
> and rough around the edges, one strong pattern that emerged immediately was
> that the most successful teams are actually TEAMS. None of this "They don't
> get it" and "We need a process that works for us" stuff.
>
> I'd be real careful promoting this us vs. them sentiment. I don't see it
> leading to long term successful design practices.
>
> Just sayin'
>
> Jared
>
> Jared M. Spool
> User Interface Engineering
> 510 Turnpike St., Suite 102, North Andover, MA 01845
> e: jspool at uie.com p: +1 978 327 5561
> http://uie.com Blog: http://uie.com/brainsparks
>
>

--
David Malouf
http://synapticburn.com/
http://ixda.org/
http://motorola.com/

12 Feb 2008 - 11:04am
vcagwin
2007

David and Jared, I agree with you both. I'm rolling onto my second agile
project, after 3 years of learning what worked well, failed and how to
recover quickly to still get the product completed, but not on time. We
are using Feature Driven Development (FDD) method.

Like David mentioned, interaction design must come first. It's the only
way I found a project to work successfully. Otherwise we start
developing "coping mechanisms" like Alan described.

Jared is right about working as a team. I sit in the same room as the
developers, QA, and the project manager. The collaboration is what
everyone loves about the project. It's my role to help "them" understand
why they cannot succeed without me. I've been so successful at this,
that the developers now come to me before any code is written.

Maybe I'm naive, but I do think that progress is being made. There are
always lessons learned on each project. Design has to come first and how
we choose to build the product to get it out the door is up to "them". I
just want to make sure I'm present to help along the way.

What I work like to learn more about is how these design engineers work
with interaction designers. I really didn't get a good grasp of the
process from Alan's article or presentation.

12 Feb 2008 - 11:17am
Jared M. Spool
2003

I'm just saying that when we use language like "Their process is
broken" instead of saying "Our team's process is broken", we are
communicating that we don't have any ownership in the problems.

I'm sure that most people here are great team members. We should
continue that language when we're talking amongst ourselves in this
forum. I fear by creating a language where the non-IxD folks who are
part of our teams become the THEMs, we'll not get the results we're
looking for long-term and community-wide.

Jared

On Feb 12, 2008, at 10:53 AM, David Malouf wrote:

> Jared,
>
> Teams does not mean same.
> Unique contributions and respect of individuality is in my
> experience a core success criteria for cross-functional teams.
>
> Understanding differences of culture, process, methods, thinking,
> theory, language, etc. is required.
> Being that they currently set the tone, they are pretty well
> understood by us (that is my take). What is not well understood, is
> them of us. And for that matter from conversations like these us of
> us.
>
> I loved the historical perspectices of Chris Bernard's and Bill
> Buxton's talks. We need more of that. Maybe you can help. ;-)
>
> But I do believe that uniqueness is something to be cherished and
> while we work towards common goals we need to respect and
> understand and envalue our differences. There is a distinct US and
> a distinct THEM and to deny that, feels fake to me.
>
> Kumbaya is not going to get us anywhere, especially in terms of
> this discussion.
>
> -- dave
>
>
> On Feb 12, 2008 9:58 AM, Jared M. Spool <jspool at uie.com> wrote:
>
> On Feb 12, 2008, at 9:43 AM, David Malouf wrote:
>
>> Mark hit it on the head, it is a developer/engineering inspired
>> and valued
>> process. It is for THEM! It is not about us, for us, by us, or
>> valuable to
>> us. This is my #1 issue with agile. And all the things you say
>> below about
>> getting design into agile, are hacks! They are not the best of
>> what we can
>> do, but what we can do in THEIR framework.
>
> WHOA!
>
> Us?!? THEM?!?
>
> There's a whole lotta us vs. them coming out these days.
>
> While our own research on what makes successful experiences is
> still young and rough around the edges, one strong pattern that
> emerged immediately was that the most successful teams are actually
> TEAMS. None of this "They don't get it" and "We need a process that
> works for us" stuff.
>
> I'd be real careful promoting this us vs. them sentiment. I don't
> see it leading to long term successful design practices.
>
> Just sayin'
>
> Jared
>
> Jared M. Spool
> User Interface Engineering
> 510 Turnpike St., Suite 102, North Andover, MA 01845
> e: jspool at uie.com p: +1 978 327 5561
> http://uie.com Blog: http://uie.com/brainsparks
>
>
>
>
> --
> David Malouf
> http://synapticburn.com/
> http://ixda.org/
> http://motorola.com/

12 Feb 2008 - 11:25am
Todd Warfel
2003

On Feb 12, 2008, at 11:17 AM, Jared M. Spool wrote:

> I'm just saying that when we use language like "Their process is
> broken" instead of saying "Our team's process is broken", we are
> communicating that we don't have any ownership in the problems.

I couldn't agree with this more. I have a bad taste in my mouth for
Six Sigma, not because the SS process is broken, but because the
implementations that I've seen broad and deep have been flawed, or
implemented for the wrong thing—it's not great for web development.

Methods are just a means to an end and a methodology or process is
only as good as it's implemented. If it breaks, 9 times out of 10 are
"we" simply didn't implement it correctly.

Cheers!

Todd Zaki Warfel
President, Design Researcher
Messagefirst | Designing Information. Beautifully.
----------------------------------
Contact Info
Voice: (215) 825-7423
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

12 Feb 2008 - 11:34am
Christopher Fahey
2005

On Feb 12, 2008, at 11:04 AM, Cagwin, Virginia wrote:
> Like David mentioned, interaction design must come first. It's the
> only
> way I found a project to work successfully.

Interestingly, I am about to begin Phase 3 of a major project with
the following phases, each of which slightly overlaps the others. For
context, the whole process is overseen by a small product management
team while the design and programming teams are largely specialized
consultant firms (including my team at Behavior).

1) Strategy- and Design-Focused (4 months): Thoroughly design a
version 1.0 prototype and test it with real users. No tech
development. Just collect requirements and design something that
meets a business strategy and delivers an awesome user experience.
Identify the technological needs, but don't code anything.

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.

3) Close Collaboration (4 months): Design team ramps up again, using
the lessons learned and opportunities identified during the tech
progress, plus the prototype and product user testing feedback, to
work alongside the tech team to finalize the UX and implement the fit
and finish of the product. Much triage is anticipated.

It's a little more complex than this when you drill down a little bit
(there are design cycles that are heavily focused on branding and
larger corporate integration issues and that have little to do with
the features and functionality), but this is the basic idea. Design
first, code it halfway, then collaborate closely down the home stretch.

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.

Cheers,
-Cf

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

>

12 Feb 2008 - 11:37am
Andrew Sandler
2006

I spent most of last year at Salesforce.com as the UI Manager trying to
understand Agile, and how UCD fits in to it. There was a lot to like about
the methodology, and a lot to dislike. I think that at it's core, Agile
tries to recreate the best of what we all aspire to at startups or on small
team projects: openness, transparency, collaboration, communication, and
fast implementation. However, as everyone identified, it hasn't
traditionally been used/useful in product development organizations as much
as IT specific ones.

After 5+ years of purely deterministic waterfall process at eBay, I continue
to feel that Agile methodologies are a way to allow UX to have a seat at the
product table, incorporating user needs early in the process, and
incrementally improving existing features each release.

Agile also removes an awful lot of the CYA aspect of waterfall. You tend
not to hear "The requirements weren't clear, so we didn't build it" or "Why
can't you just implement it the way I spec'ed it" as much when you have to
face each other every day to give status. If a spec is blocking
implementation, you know about it that day. If a developer isn't
implementing correctly, you should be able to catch it early.

That being said, Agile gets thrown around a lot, and is used to excuse some
very bad behavior. Agile doesn't mean that you don't plan. In fact, I'd
argue that you need a much clearer idea of what you're aiming for, because
the iterations come so much faster. If you don't have a product roadmap,
how can you possibly prioritize you backlog?
Agile doesn't mean that you ignore doing research. Every quality project
I've worked on needed an upfront investigative component to uncover user
needs and market opportunities - no matter what the methodology. In Agile,
this tends to be a Phase or Sprint Zero.

There seems to be an emerging consensus around parallel, asynchronous
development within Agile between the developers and UX folks. Design and
Development run side by side feeding forward concepts and prototypes for
future sprints, and testing implemented code as needed. Lynn Miller and
Mark Detweiler have both written about this methodology in some peer
reviewed journals. I encourage everyone to read them.

This year at CHI there's going to be quite a bit on Agile and UCD, including
a workshop run by the Autodesk folks: http://agileucd.editme.com/, and a
panel by the Salesforce.com team: http://www.chi2008.org/ap/57.html.

12 Feb 2008 - 11:40am
Christopher Fahey
2005

On the subject of Alan Cooper's keynote, did he provide any clarity
on his assertion a few months ago that it is the norm for engineers
to start coding without having done even one second of thinking about
design? Not just neglecting to do any interaction or UX design, but
not doing any code planning/design or any design of any sort whatsoever.

I was really confused by that, and I think the thread on this list
about that topic kind of fizzled out.

Cheers,
-Cf

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

12 Feb 2008 - 11:19am
Scott McDaniel
2007

This reflects my view on it as well. After all, we did have a seminar
called "User Interface Design in an Agile Environment",
which my limited understanding seemed to speak to including engineers
earlier in the process, if only for 'buy in', 'ownership'
and other buzzwords. The designer in question would still hold the
design-authority, but allowing for the other eyes seems to
hold incredible potential. This is hardly kum-bah-yah - there's no
doubt I'd thinking some of the engineers are stuffy dorks,
and I wasn't entirely convinced this is The New Way to Go, but it does
seem to speak to possibilities.

Every author I know has their own way of writing, after all.

I love that this list is so vigorously alive :)

Scott

On Feb 12, 2008 11:04 AM, Cagwin, Virginia <Virginia.Cagwin at turner.com> wrote:
> David and Jared, I agree with you both. I'm rolling onto my second agile
> project, after 3 years of learning what worked well, failed and how to
> recover quickly to still get the product completed, but not on time. We
> are using Feature Driven Development (FDD) method.
>
> Like David mentioned, interaction design must come first. It's the only
> way I found a project to work successfully. Otherwise we start
> developing "coping mechanisms" like Alan described.
>
> Jared is right about working as a team. I sit in the same room as the
> developers, QA, and the project manager. The collaboration is what
> everyone loves about the project. It's my role to help "them" understand
> why they cannot succeed without me. I've been so successful at this,
> that the developers now come to me before any code is written.
>
> Maybe I'm naive, but I do think that progress is being made. There are
> always lessons learned on each project. Design has to come first and how
> we choose to build the product to get it out the door is up to "them". I
> just want to make sure I'm present to help along the way.
>
> What I work like to learn more about is how these design engineers work
> with interaction designers. I really didn't get a good grasp of the
> process from Alan's article or presentation.
>
> ________________________________________________________________
> 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
>

--
If we don't believe in freedom of expression for people we despise, we
don't believe in it at all.
Noam Chomsky

12 Feb 2008 - 11:51am
Dante Murphy
2006

<snip>
1) Strategy- and Design-Focused (4 months): Thoroughly design a version
1.0 prototype and test it with real users. No tech development. Just
collect requirements and design something that meets a business strategy
and delivers an awesome user experience. Identify the technological
needs, but don't code anything.

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.

3) Close Collaboration (4 months): Design team ramps up again, using the
lessons learned and opportunities identified during the tech progress,
plus the prototype and product user testing feedback, to work alongside
the tech team to finalize the UX and implement the fit and finish of the
product. Much triage is anticipated.
</snip>

When I read this, here's what I see:

1. Design
2. Build
3. Fix

Looks a lot like waterfall to me, and the "Fix" phase looks awfully
vulnerable out there, with budgets dwindling and time to market ebbing
away. If you really think that your team will adhere to the whole
process, then I think there's reason to be optimistic; you're getting
the maximum value from design and the maximum efficiency from
development. But most product/project managers lack the discipline (or
clout) to follow the "Fix" phase all the way through until a really
great solution is ready.

Personally, I love the idea of spending 4 months on design. That would
be 3.5 more than I usually get.

Dante Murphy | Director of Information Architecture | D I G I T A S H E
A L T H
229 South 18th Street | Rittenhouse Square | Philadelphia, PA 19103 |
USA
Email: dmurphy at digitashealth.com
www.digitashealth.com

12 Feb 2008 - 12:06pm
Pierre Roberge
2005

Dan 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?

Thanks

Bonne Journée!

Pierre Roberge
User Experience Designer - Business Analyst
etfs

819)-566-2901 #2193
1-800-465-8602 #2193
http://www.etfsinc.com/

----------
etfs inc. The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential and/or
privileged material. Any review, retransmission, dissemination or other
use of, or taking of any action in reliance upon this information by
persons or entities other than the intended recipient, is prohibited. If
you have received this in error, please contact the sender and delete
the material from any computer. Unless otherwise stated, opinions
expressed in this e-mail are those of the author and are not endorsed
by the author's employer.

etfs inc. L'information transmise ne s'adresse qu'au particulier ou à
l'organisme à qui il est dirigé. Il peut contenir des renseignements de
nature privilégiée et/ou confidentielle . Si le lecteur de ce message
n'est pas le destinataire visé, ni l'employé ou le mandataire chargé de
la livraison au destinataire visé, il est par la présente avisé que
toute dissémination, distribution ou transcription de cette
communication est strictement interdite. Si vous avez reçu la présente
communication par erreur, veuillez nous en aviser immédiatement par
courriel et détruire le document de tout ordinateur le contenant. À
moins d'avis contraire, toute opinion exprimée dans le présent courriel
est celle de son auteur et n'est pas endossée par l'employeur de la
personne qui l'exprime.

12 Feb 2008 - 12:30pm
Anjali Arora, NYU
2004

This does sound like a dream project: getting 4 months to research & design!

Within the agile discussion here, I did not read about how important it is that the build-in-progress be seen by all the team-members from the start. I am now in a situation where I find that what has been built in the past three months is a complete & random rehash of developer-designed screens ( a very large component) & my designs (small component). The primary philosophy appears to be: launch on time, & ready-to-use code dictates all else: use what you have, & all else will follow! At this late stage, I am finding that there is very little change one can make except for some cosmetic ones.

In doing a post-mortem, I am inclined to think all of the following may have contributed to this:

- Not being able to see the product-in-progress in time.

- Territory issues where developers have gotten used to completely owning the product, no matter that all previous products launched have been failures.

- The teams being too large & geographically dispersed. I now think that where the teams have to be large, 1-2 members from each should be owning the product, communicating frequently, & shepherding it through.

- I am also exploring how my design documents can be enriched to provide more detail, especially since folk were remote & there was no face-to-face.

-Anjali
www.artbrush.net

----- Original Message -----
From: Christopher Fahey <chris.fahey at behaviordesign.com>
Date: Tuesday, February 12, 2008 11:35 am
Subject: Re: [IxDA Discuss] Fwd: Thoughts on Alan Cooper's Keynote
To: discuss at ixda.org

> On Feb 12, 2008, at 11:04 AM, Cagwin, Virginia wrote:
> > Like David mentioned, interaction design must come first. It's the
>
> > only
> > way I found a project to work successfully.
>
>
> Interestingly, I am about to begin Phase 3 of a major project with
> the following phases, each of which slightly overlaps the others. For
>
> context, the whole process is overseen by a small product management
>
> team while the design and programming teams are largely specialized
>
> consultant firms (including my team at Behavior).
>
> 1) Strategy- and Design-Focused (4 months): Thoroughly design a
> version 1.0 prototype and test it with real users. No tech
> development. Just collect requirements and design something that
> meets a business strategy and delivers an awesome user experience.
> Identify the technological needs, but don't code anything.
>
> 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.
>
> 3) Close Collaboration (4 months): Design team ramps up again, using
>
> the lessons learned and opportunities identified during the tech
> progress, plus the prototype and product user testing feedback, to
> work alongside the tech team to finalize the UX and implement the fit
>
> and finish of the product. Much triage is anticipated.
>
> It's a little more complex than this when you drill down a little bit
>
> (there are design cycles that are heavily focused on branding and
> larger corporate integration issues and that have little to do with
>
> the features and functionality), but this is the basic idea. Design
>
> first, code it halfway, then collaborate closely down the home stretch.
>
> 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.
>
> Cheers,
> -Cf
>
> Christopher Fahey
> ____________________________
> Behavior
> biz: http://www.behaviordesign.com
> me: http://www.graphpaper.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
>

12 Feb 2008 - 1:37pm
Christian Crumlish
2006

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

12 Feb 2008 - 2:08pm
Dave Malouf
2005

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/

12 Feb 2008 - 2:33pm
David Armano
2007

There were a couple of things about Alan's talk that didn't sit well
with me. I understood the argument of "Best to market" but I wonder
if stressing that limits the spirit of invention. Can we still
invent?

Also, while I respect and believe in rigorous methods%u2014I've seen
the "fuzzy" front end be a very effective way to drive effective
solutions. The rigor can still be injected in the process. I may
have misunderstood the spirit of the talk%u2014but I do believe that
sometimes we can confuse rigor for rigid (as I mentioned in my talk).

And where does the community come into the picture. Apple's
community wants a more "open" iPhone environment. We want more
choice and personalization of our experience with the iPhone. Where
does this fit into what Alan was saying?

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

12 Feb 2008 - 3:00pm
jrrogan
2005

Whoa there Dave,

While not getting into all you've stated, but ...

It seems there's 3 or 4 examples in this single thread of teams successfully
integrating "true design" with Agile methodologies, (with "true design"
meaning solutions design, not research or academic theory).

And as far as "one culture dominating" you stated it well indicating that
certain team members have more say at certain junctures in the SDLC. Why
would it not be optimal to have certain parts of the team dominate when
their stage of the process is the central focus?

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

>To do software
>correctly requires deep strategic and tactical planning with a holistic and
>deeply forward thinking view.

-- dave

Agreed totally with your last statement, but this in no way negates "Design"
working with "Agile methodologies".

--
Joseph Rich Rogan
President UX/UI Inc.
http://www.jrrogan.com

12 Feb 2008 - 3:28pm
Andrei Herasimchuk
2004

I'm mostly with Dave on the issue, although I wouldn't go so far to
bring into geopolitical metaphors. Here's how I think of it:

Designer's have process, but designer's don't use process.

What does that mean? "Using" process often devolves into a paint by
numbers type of way to solve problems for a designer. And in that
regard, it's a waste of time and money to force designers to solve a
particular problem in a particular way based on methods that are
largely about construction or engineering. It doesn't matter to me
what process it is, waterfall or agile, all of them push me to work
in a way that limits my flexibility as a designer to solve problems
however I need to solve them.

But the truth is, I do have processes. The difference though is that
I own a variety of processes much like I own lots of paintbrushes,
hammers, saws, pencils and rulers. Processes don't own me, I own
them. And I use whichever one I need to given the problem I'm
presented with.

That is often a hard pill for most executives or managers to swallow,
and I can't blame because it feels to them like a random approach to
work that often needs more methodology, like schedules and deadlines
with so much on the line business-wise. To compensate for that, I
push prototypes as the means to make it easier for people to let me
use whatever tools/processes I need to in order to solve the problem
at hand. With a real prototype to interact with, see and evaluate,
all that often matters in the end game for managers is that prototype
is delivered in a timely and iterative manner. How I actually got
there is often left to me to do, giving me the flexibility to use all
the various tools and processes I have at my disposal.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

12 Feb 2008 - 3:53pm
Alan Cooper
2004

Christopher,

Which one do you throw away?

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

12 Feb 2008 - 3:56pm
Jared M. Spool
2003

On Feb 12, 2008, at 3:28 PM, Andrei Herasimchuk wrote:

> Designer's have process, but designer's don't use process.
>
> What does that mean? "Using" process often devolves into a paint by
> numbers type of way to solve problems for a designer.

For the record, our research over the years shows consistently that
few knowledge workers (designers, lawyers, developers, sales people)
follow a process in a paint-by-numbers fashion.

"Using process" seems to be an outsiders view (aka managers or folks
from other disciplines) of how the magic of a discipline is
accomplished.

Jared

Jared M. Spool
User Interface Engineering
510 Turnpike St., Suite 102, North Andover, MA 01845
e: jspool at uie.com p: +1 978 327 5561
http://uie.com Blog: http://uie.com/brainsparks

12 Feb 2008 - 3:58pm
Alan Cooper
2004

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

12 Feb 2008 - 4:12pm
Christine Boese
2006

I can't really speak directly to the issue being discussed, but I just
wanted to add a plug for Desiree Sy's article on this subject in the Journal
of Usability Studies, which I read, I think, from a link posted to this
list. Took me a while to get to it, but I found it a very interesting
discussion.

The approach she outlines also would appear to be a lot of hard work to
"make" it work, a lot of juggling, and really dependent on a team being able
to keep the overall big vision in mind all the time, as well as consistency
issues, while plugging away at the small chunked bits. But in terms of a
model of how to try to make it work, there's one possible model (from
Autodesk, as mentioned below).

Here's the link, in case you missed it the last time it was posted, I forget
by whom.

http://www.usabilityprofessionals.org/upa_publications/jus/2007may/agile-ucd.html

Chris

On Feb 12, 2008 2:15 AM, Jeff White <jwhite31 at gmail.com> wrote:

> Out of curiosity, have you or Greg ever practiced agile? Not trying to
> be a pain, but really would like to hear what your experience was if
> so.
>
> Also, one of the sponsors of Interaction08, Autodesk, has been
> designing award winning user experiences in a very complex product
> space with agile for more than half of a decade. It can work, and it
> can fail, just like any other process/approach/methodology. They also
> enjoy a really positive and happy work environment, and have very
> little turnover. I've had the opportunity to meet & collaborate with
> Lynn Miller and Desiree Sy - both interaction designers at Autodesk,
> and they are really doing great design work.
>
> What's interesting is that in both of those keynotes, the relationship
> between designers and engineers was also highlighted. Even when there
> is time for deconstruction as you mention, that doesn't mean it
> actually gets built and implemented in the right way. I'm sure this is
> very different across different types of organizations - boutique
> design shops vs corporate workplaces comes to mind. My experience with
> agile has been that if you embrace certain aspects of it, you can
> really improve that relationship. I've worked in waterfall and I have
> worked in agile. Quite frankly, each one has its pros and cons. I feel
> part of our job as designers is to accept that there will be always be
> less than perfect situations, and learn how to deal with them in
> innovative and positive ways that result in good user experiences.
>
> As a shameless plug, Jim Ungar and I presented on just this Sunday
> afternoon. I disagree with you that user experiences are not being
> designed, but just built when it comes to agile. There are ways to do
> real design in agile - incorporating user research, concept ideation,
> exploration & critique, and true iteration based on things like
> usability testing and design leadership. It just requires letting go
> of some old practices and embracing new ones.
>
> Jeff
>
> On Mon, 11 Feb 2008 18:06:15, dave malouf <dave at ixda.org> wrote:
> > At the postmortem dinner for the conference on sunday night. Myself &
> > Greg Petroff when off on a debate about Agile being good or bad. I
> > find it interesting that BOTH of our pre-eminent keynotes are both
> > talking down agile, YET we as a UX community believe it is still
> > valuable. Yikes! It screams to me the horrible influences we have
> > been forced to assimilate towards (taking some of Bill's juices and
> > running with it) around being under the thumb of engineering all
> > these decades.
> >
> > Through the discussion what became clear was that the term
> > "waterfall" is associated with RUP (or RUP like processes) and for
> > some reason is equated to "documentation". However, the meaning of
> > waterfall to me means ... define before build as per Bill's
> > discussion. Know what you are doing before you green light spending
> > production dollars. What follows that design period does not need to
> > be reams of useless and often mindless paper.
> >
> > On another point.
> > I really disagree with this:
> >
> > > In fact, one of the core aspects of UX%u2014delivering
> > > what the users need%u2014can be better assured through
> > > agile process (IMO) .
> >
> > B/c I think it shows a lack of understanding to what UX is all
> > about--telling a story. A lot of people have already highlighted
> > "story telling" as a major theme of the conference and I couldn't
> > agree more, but the way to creatively write a story, or create a
> > drama, or event, is to do it through deconstruction. I never really
> > understood what that meant till this conference, and this
> > conversation, but for now at least, it means for me, that I create a
> > vision and then deconstruct it through value statements and other
> > criteria used to make choices.
> >
> > The example is ... The theatrical version of a movie vs. a
> > director's cut. Almost always in process, the director's cut is
> > made first and then it is cut down to fit the theater.
> >
> > If I just build in iterations, there is never a whole, guiding light
> > or prototype from which I can cut away at.
> >
> > It seems that unless there is a distinct design phase where this
> > visioning process can happen owned by design for design with
> > collaboration and consultation from engineering and business, we are
> > NOT *designing* user experiences, but just building them.
> >
> > Now, Agile development processes seem GREAT after designs are "green
> > lighted". There are lots of advantages to engineers in those
> > processes, but assimilating to them seems like a grave mistake at
> > this point to me.
> >
> > - dave
> >
> >
> > . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> > Posted from the new ixda.org
> > http://www.ixda.org/discuss?post=25686
> >
> >
> > ________________________________________________________________
> >
> > 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
>

12 Feb 2008 - 3:16pm
ambroselittle
2008

Hi folks,

Wow, quite the little hornet's nest this has stirred up. Here's my
(further) take on this question of agile w/ UX.

First off, it seems to me that a lot of folks (devs included) have baggage
and multifarious connotations with the term "agile." I don't see a lot of
value in debating those. Nor do I think much more anecdotal evidence will
help--software projects (with good UX) can succeed or fail with any process,
as has been noted. The
evidence<http://www.ambysoft.com/surveys/agileMarch2007.html>in
business software, at least, is that agile lends itself to greater
success.

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.

For my part, I think a huge part of the success of a project depends upon
the actual usefulness of the thing being designed and built. You can make a
product as usable, desirable, interactive, and rich as you want, but if in
the end it doesn't actually do what needs to be done, it doesn't matter.
The goal of agile is to tackle this important facet of UX--usefulness--in a
more successful manner than "waterfall" has.

Based on my experience and knowledge of the ways devs think, making the
case for UX is already an uphill battle with a lot of dev shops. If you, as
the UX advocate, try to force a particular methodology down their throats,
you're only going to make your job harder. Instead of calcifying and
arguing about methodologies, as UX pros, I'd suggest you simply ensure that
you make your needs clear to the biz and devs you'll be working with. Try
to figure out how to work your needs into the process they have in place and
be flexible (adapt).

--Ambrose

J. Ambrose Little
UXG Lead & Codemunicator
infragistics.com

12 Feb 2008 - 1:37pm
Scott McDaniel
2007

In a strict display sense, this is the single most common phrase I've heard from
engineers/programmers about design:
"Why not just throw it in a data table and be done with it?"

Scott

On Feb 12, 2008 11:40 AM, Christopher Fahey
<chris.fahey at behaviordesign.com> wrote:
> On the subject of Alan Cooper's keynote, did he provide any clarity
> on his assertion a few months ago that it is the norm for engineers
> to start coding without having done even one second of thinking about
> design? Not just neglecting to do any interaction or UX design, but
> not doing any code planning/design or any design of any sort whatsoever.
>
> I was really confused by that, and I think the thread on this list
> about that topic kind of fizzled out.
>
> Cheers,
> -Cf
> --
If we don't believe in freedom of expression for people we despise, we
don't believe in it at all.
Noam Chomsky

12 Feb 2008 - 4:57pm
SemanticWill
2007

"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."

Where does User Research, Abductive brainstorming (from Design Thinking);
conceptual modeling and prototyping fit into his model? Does his methodology
call for requirements up front? How can this method possibly create new
innovations if it is essentially the same old requirements>design>develope>
test process?

My take is simple - and I do have baggage. I worked for a few years at a
company and was afforded almost a year to do user research, personas,
wireframes, flows - for a thick client application. Then I spent another 3
months prototyping ideas from brainstorming in MS Expressions Blend -- after
all this was over - all of it was handed over to a development team that was
adopting Agile. Sounds good? Kind of, I guess - we'll see what they produce
since I left to work in the most truly agile of all environments - 3 guys
working in a garage.

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.

If UCD is allowed upfront - then handed off to an Agile development team -
it could work - I just have not seen/heard of one successful case study of
the two integrated.

~ w. (the baggage guy)

On Feb 12, 2008 3:16 PM, J. Ambrose Little <ambrose at aspalliance.com> wrote:

> Hi folks,
>
> Wow, quite the little hornet's nest this has stirred up. Here's my
> (further) take on this question of agile w/ UX.
>
> First off, it seems to me that a lot of folks (devs included) have baggage
> and multifarious connotations with the term "agile." I don't see a lot of
> value in debating those. Nor do I think much more anecdotal evidence will
> help--software projects (with good UX) can succeed or fail with any
> process,
> as has been noted. The
> evidence<http://www.ambysoft.com/surveys/agileMarch2007.html>in
> business software, at least, is that agile lends itself to greater
> success.
>
> 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.
>
> For my part, I think a huge part of the success of a project depends upon
> the actual usefulness of the thing being designed and built. You can make
> a
> product as usable, desirable, interactive, and rich as you want, but if in
> the end it doesn't actually do what needs to be done, it doesn't matter.
> The goal of agile is to tackle this important facet of UX--usefulness--in
> a
> more successful manner than "waterfall" has.
>
> Based on my experience and knowledge of the ways devs think, making the
> case for UX is already an uphill battle with a lot of dev shops. If you,
> as
> the UX advocate, try to force a particular methodology down their throats,
> you're only going to make your job harder. Instead of calcifying and
> arguing about methodologies, as UX pros, I'd suggest you simply ensure
> that
> you make your needs clear to the biz and devs you'll be working with. Try
> to figure out how to work your needs into the process they have in place
> and
> be flexible (adapt).
>
> --Ambrose
>
> J. Ambrose Little
> UXG Lead & Codemunicator
> infragistics.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
>

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

12 Feb 2008 - 5:01pm
SemanticWill
2007

True Scott - which is why brainstorming and prototyping by IxD people should
be done first!

If everything was thrown in a data table - we would never have the 3-d
flip-book carousel to page through our CDs on our iPhones. Lotus 1-2-3 came
out 25 years ago - we might think about innovating once in a while :-)

On Feb 12, 2008 1:37 PM, Scott McDaniel <scott at scottopic.com> wrote:

> In a strict display sense, this is the single most common phrase I've
> heard from
> engineers/programmers about design:
> "Why not just throw it in a data table and be done with it?"
>
> Scott
>
> On Feb 12, 2008 11:40 AM, Christopher Fahey
> <chris.fahey at behaviordesign.com> wrote:
> > On the subject of Alan Cooper's keynote, did he provide any clarity
> > on his assertion a few months ago that it is the norm for engineers
> > to start coding without having done even one second of thinking about
> > design? Not just neglecting to do any interaction or UX design, but
> > not doing any code planning/design or any design of any sort whatsoever.
> >
> > I was really confused by that, and I think the thread on this list
> > about that topic kind of fizzled out.
> >
> > Cheers,
> > -Cf
> > --
> If we don't believe in freedom of expression for people we despise, we
> don't believe in it at all.
> Noam Chomsky
> ________________________________________________________________
> 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
-------------------------------------------------------

12 Feb 2008 - 5:06pm
White, Jeff
2007

On Feb 12, 2008 1:37 PM, Scott McDaniel <scott at scottopic.com> wrote:
> In a strict display sense, this is the single most common phrase I've heard from
> engineers/programmers about design:
> "Why not just throw it in a data table and be done with it?"
>
> Scott
>

What's the issue with that? Kidding...

How have you handled the situation?

Jeff

12 Feb 2008 - 5:02pm
Jeff Patton
2007

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

12 Feb 2008 - 5:09pm
Kevin Silver1
2006

Scott,

Too funny and timely. A few unlucky souls over the weekend in Savannah
had to endure my rant against Data-Grids. I just reviewed a flex
application for a client that relies heavily on data-grids, we're
going to be fixing that because it just doesn't work in their
situation. To top it off I recently heard the Adobe Flex evangelist
speak about the upcoming release of Flex 3 and the biggest feature he
talked about was the new advanced data-grid. Though it has some cool
features, I was left thinking and incoherently mumbling to myself
"data-grids" to myself over and over again.

My issue against data-grids is that in most situation when I have seen
it use (and as I must admit have used it in my very distant past with
Access) it does nothing more than just expose the implementation model
(a table in the database or a result set from a query) to the user.
Data-grids are used effectively in many places, but my gripe is that
just displaying the data doesn't mean you have an application. Where's
the design?

Kevin

On Feb 12, 2008, at 11:37 AM, Scott McDaniel wrote:

> In a strict display sense, this is the single most common phrase
> I've heard from
> engineers/programmers about design:
> "Why not just throw it in a data table and be done with it?"
>
> Scott
>
> On Feb 12, 2008 11:40 AM, Christopher Fahey
> <chris.fahey at behaviordesign.com> wrote:
>> On the subject of Alan Cooper's keynote, did he provide any clarity
>> on his assertion a few months ago that it is the norm for engineers
>> to start coding without having done even one second of thinking about
>> design? Not just neglecting to do any interaction or UX design, but
>> not doing any code planning/design or any design of any sort
>> whatsoever.
>>
>> I was really confused by that, and I think the thread on this list
>> about that topic kind of fizzled out.
>>
>> Cheers,
>> -Cf
>> --
> If we don't believe in freedom of expression for people we despise, we
> don't believe in it at all.
> Noam Chomsky
> ________________________________________________________________
> 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

Kevin Silver
Clearwired Web Services

10899 Montgomery, Suite C
Albuquerque, NM 87109

office: 505.217.3505
toll-free: 866.430.2832
fax: 505.217.3506

e: kevin at clearwired.com
w: www.clearwired.com

12 Feb 2008 - 5:15pm
Kevin Silver1
2006

exactly!

On Feb 12, 2008, at 3:01 PM, W Evans wrote:

> True Scott - which is why brainstorming and prototyping by IxD
> people should
> be done first!
>
> If everything was thrown in a data table - we would never have the 3-d
> flip-book carousel to page through our CDs on our iPhones. Lotus
> 1-2-3 came
> out 25 years ago - we might think about innovating once in a while :-)
>
> On Feb 12, 2008 1:37 PM, Scott McDaniel <scott at scottopic.com> wrote:
>
>> In a strict display sense, this is the single most common phrase I've
>> heard from
>> engineers/programmers about design:
>> "Why not just throw it in a data table and be done with it?"
>>
>> Scott
>>
>> On Feb 12, 2008 11:40 AM, Christopher Fahey
>> <chris.fahey at behaviordesign.com> wrote:
>>> On the subject of Alan Cooper's keynote, did he provide any clarity
>>> on his assertion a few months ago that it is the norm for engineers
>>> to start coding without having done even one second of thinking
>>> about
>>> design? Not just neglecting to do any interaction or UX design, but
>>> not doing any code planning/design or any design of any sort
>>> whatsoever.
>>>
>>> I was really confused by that, and I think the thread on this list
>>> about that topic kind of fizzled out.
>>>
>>> Cheers,
>>> -Cf
>>> --
>> If we don't believe in freedom of expression for people we despise,
>> we
>> don't believe in it at all.
>> Noam Chomsky
>> ________________________________________________________________
>> 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
> -------------------------------------------------------
> ________________________________________________________________
> 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

Kevin Silver
Clearwired Web Services

10899 Montgomery, Suite C
Albuquerque, NM 87109

office: 505.217.3505
toll-free: 866.430.2832
fax: 505.217.3506

e: kevin at clearwired.com
w: www.clearwired.com

12 Feb 2008 - 5:19pm
Scott McDaniel
2007

On Feb 12, 2008 5:06 PM, Jeff White <jwhite31 at gmail.com> wrote:
> On Feb 12, 2008 1:37 PM, Scott McDaniel <scott at scottopic.com> wrote:
> > "Why not just throw it in a data table and be done with it?"
> >
> > Scott
> What's the issue with that? Kidding...
>
> How have you handled the situation?
>
> Jeff

Earlier on in my career, I just wept softly to myself because I didn't
have the knowledge and words to back up
what my instincts were telling me - and then just design as best as I could.*

Now - thanks to self-education, experience, peoplegroups like this
list, and books written by
lovely, talented and passionate people give me more traction - both in
highlighting principles of user-
centered design and showing them how the very gadgets, applications
and widgets that enrich their lives
are all what they are due to the 'floaty disciplines'.

As things have gone further (such as with the ideas and hopes that
have been ignited by interaction08),
and I'm more than just some weird amalgamation of graphics guy and
programmer with
a liberal arts degree, I can persuade people and hell, get them
outright on board - both at lunch and during the process.

When there is process. I still find in particular places that call
themselves 'software shops', design beyond "give me a good
color theme" is the first corner(stone) that gets cut.

Scott

*(Follow-up barbs would include "You just do HTML, right?" and "Just
make it like Amazon.")

--
If we don't believe in freedom of expression for people we despise, we
don't believe in it at all.
Noam Chomsky

12 Feb 2008 - 5:48pm
Jared M. Spool
2003

On Feb 12, 2008, at 5:06 PM, Jeff White wrote:

> On Feb 12, 2008 1:37 PM, Scott McDaniel <scott at scottopic.com> wrote:
>> In a strict display sense, this is the single most common phrase
>> I've heard from
>> engineers/programmers about design:
>> "Why not just throw it in a data table and be done with it?"
>>
>> Scott
>>
>
> What's the issue with that? Kidding...
>
> How have you handled the situation?

He threw the programmers into a data table and was done with it.

:)

Jared

12 Feb 2008 - 5:51pm
SemanticWill
2007

Datagrids are the evil demonic spawn of feable minds and people of
small souls!!!

Time to design a data grid. Maybe they will let me alternate row
colours!

will evans
user experience architect
wkevans4 at gmail.com
617.281.1281

On Feb 12, 2008, at 5:09 PM, Kevin Silver <kevin at clearwired.com> wrote:

> Scott,
>
> Too funny and timely. A few unlucky souls over the weekend in Savannah
> had to endure my rant against Data-Grids. I just reviewed a flex
> application for a client that relies heavily on data-grids, we're
> going to be fixing that because it just doesn't work in their
> situation. To top it off I recently heard the Adobe Flex evangelist
> speak about the upcoming release of Flex 3 and the biggest feature he
> talked about was the new advanced data-grid. Though it has some cool
> features, I was left thinking and incoherently mumbling to myself
> "data-grids" to myself over and over again.
>
> My issue against data-grids is that in most situation when I have seen
> it use (and as I must admit have used it in my very distant past with
> Access) it does nothing more than just expose the implementation model
> (a table in the database or a result set from a query) to the user.
> Data-grids are used effectively in many places, but my gripe is that
> just displaying the data doesn't mean you have an application. Where's
> the design?
>
> Kevin
>
> On Feb 12, 2008, at 11:37 AM, Scott McDaniel wrote:
>
>> In a strict display sense, this is the single most common phrase
>> I've heard from
>> engineers/programmers about design:
>> "Why not just throw it in a data table and be done with it?"
>>
>> Scott
>>
>> On Feb 12, 2008 11:40 AM, Christopher Fahey
>> <chris.fahey at behaviordesign.com> wrote:
>>> On the subject of Alan Cooper's keynote, did he provide any clarity
>>> on his assertion a few months ago that it is the norm for engineers
>>> to start coding without having done even one second of thinking
>>> about
>>> design? Not just neglecting to do any interaction or UX design, but
>>> not doing any code planning/design or any design of any sort
>>> whatsoever.
>>>
>>> I was really confused by that, and I think the thread on this list
>>> about that topic kind of fizzled out.
>>>
>>> Cheers,
>>> -Cf
>>> --
>> If we don't believe in freedom of expression for people we despise,
>> we
>> don't believe in it at all.
>> Noam Chomsky
>> ________________________________________________________________
>> 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
>
> Kevin Silver
> Clearwired Web Services
>
> 10899 Montgomery, Suite C
> Albuquerque, NM 87109
>
> office: 505.217.3505
> toll-free: 866.430.2832
> fax: 505.217.3506
>
> e: kevin at clearwired.com
> w: www.clearwired.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

12 Feb 2008 - 6:04pm
White, Jeff
2007

Then if you're able to educate your colleagues, get them on board as
you say, you're doing the right thing. We heard a lot over the weekend
about relationships between designers and engineering. I feel this is
way more important than what methodology is used. Simply throwing
things over the wall to "them", etc just doesn't work, in my
experience. Relationship building has always worked for me, and I feel
that true design can or cannot happen in any type of development
approach. It's all in how you establish yourself, and design culture
into the organization.

Jeff

On Feb 12, 2008 5:19 PM, Scott McDaniel <scott at scottopic.com> wrote:
> On Feb 12, 2008 5:06 PM, Jeff White <jwhite31 at gmail.com> wrote:
> > On Feb 12, 2008 1:37 PM, Scott McDaniel <scott at scottopic.com> wrote:
> > > "Why not just throw it in a data table and be done with it?"
> > >
> > > Scott
> > What's the issue with that? Kidding...
> >
> > How have you handled the situation?
> >
> > Jeff
>
> Earlier on in my career, I just wept softly to myself because I didn't
> have the knowledge and words to back up
> what my instincts were telling me - and then just design as best as I could.*
>
> Now - thanks to self-education, experience, peoplegroups like this
> list, and books written by
> lovely, talented and passionate people give me more traction - both in
> highlighting principles of user-
> centered design and showing them how the very gadgets, applications
> and widgets that enrich their lives
> are all what they are due to the 'floaty disciplines'.
>
> As things have gone further (such as with the ideas and hopes that
> have been ignited by interaction08),
> and I'm more than just some weird amalgamation of graphics guy and
> programmer with
> a liberal arts degree, I can persuade people and hell, get them
> outright on board - both at lunch and during the process.
>
> When there is process. I still find in particular places that call
> themselves 'software shops', design beyond "give me a good
> color theme" is the first corner(stone) that gets cut.
>
> Scott
>
> *(Follow-up barbs would include "You just do HTML, right?" and "Just
> make it like Amazon.")
>
> --
>
> If we don't believe in freedom of expression for people we despise, we
> don't believe in it at all.
> Noam Chomsky
> ________________________________________________________________
> 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
>

12 Feb 2008 - 6:57pm
Gabriel White
2005

For those of you on the list who missed Alan's keynote, there's a transcript
here: http://ajaxian.com/archives/interaction08-ixds-in-savannah-alan-cooper

-g

12 Feb 2008 - 11:34pm
Dave Malouf
2005

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/

13 Feb 2008 - 5:38am
White, Jeff
2007

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
>

Syndicate content Get the feed