[IxDA Discuss] design by committee??

[leo.frishberg at exgate.tek.com]

Russ,

What a wonderfully charged topic!

You asked for examples/experiences in which design/development worked
well together.

So, let me start by using my favorite counter-argument to the notion
that the embedded software and hardware team should have an opportunity
to opine on the UXD:  "Would you like my input on the chip layout?
Would you like my opinion about your object classes?"  This usually
causes them to pause, laugh nervously and we move on.

But more to the positive side of things.  There is a rich history here
of "design by consensus" which took root as a result of lack of
expertise in IxD.  So, as a survival mechanism, the teams batted about
every possible solution they could think of until they all agreed on
one.  Note, that the "user" was never included in this process.  

I have had inordinate success here in wrenching "design" (specifically
UXD) from the development team for several reasons:

1) The group tried several different strategies prior to my arrival
(this took many years of different trials-by-error) before they figured
out that they really didn't know what they were doing
2) The group also determined, through these experiments, that they
needed a professional immersed in the science and art of IxD/UXD.
3) They also figured out that they couldn't do this with part-timers
(either contractors or individuals from our central engineering team)
because of the need for deep domain knowledge.

My "success" results not so much from my own "genius" or "great design"
work (I haven't really had the time to show off anything that would
cause anyone to gasp in astonishment), but instead from the team's
active engagement in sincerely trying to improve their
design/development process and failing with every attempt to date.

With that said, however, I haven't been sitting idle for two years.
Instead of rushing in and attempting to revolutionize the application
interface, I suggested that we needed a solid body of user-centered
research to help guide us.  Note the 1st person plural.  While it was
primarily ::me:: doing the research, I made sure that development /
marketing team members accompanied me whenever possible.  

During the very frequent feedback sessions to the team about the
research progress, I revealed to them patterns of use that they found
simultaneously familiar and surprising.  An odd mixture, but one that
helped establish my credibility:  "Our users are doing such-and-such -
sound familiar?  But we aren't providing an interface to support that
activity....why not?"  I suppose that this dovetails with the discussion
about requirements gathering mentioned so far.   But it goes beyond that
- it is changing the culture of the development team from focusing on
::me:: and focusing instead on bona fide ::users:: a critical shift if
I'm going to get them to stop opining about what the UI ::should:: do.

With that foundation established, it has been relatively smooth sailing
to begin changing the interface; in some cases radically.  The
conversations I have with development are predominately around what is
technically feasible, where the big infrastructure "gotchas" are and so
forth - exactly the rich discussion that should be going on.  In
addition, the marketing and development teams are required reviewers of
the UIS, and I'm very glad for it.  Both functions have found holes in
the spec, seeming contradictions, apparent violations of O/S standards,
etc. which only numerous pairs of eyes can find.  Thankfully, in all of
the reviews, very little discussion about what the UI "should do" have
come up; instead the presumption is that the proposed UI is good for the
user and we need to make it even better.

Hoping that helps,

Leo