design by committee??

18 Jul 2006 - 9:38am
8 years ago
45 replies
742 reads
russwilson
2005

I don't believe in "design by committee". Specifically
where the committee is made up of groups outside of design
(development, product mgt., etc.)

I'm not saying that I don't believe in collaboration. But I do
not want to be in situations where I have to "compete" for design
with non-designers. I cannot see how conceptual integrity can be
achieved this way.

And yet it seems that no matter where I go, no matter what level
I reach within a company, development (and other groups) want some
authority over interface design...

Does anyone have any successful experiences to share regarding
improving synergies between design/development? I would
ultimately like to see development focus on implementation
and feasibility and let design focus on design (desirability - for
those who have seen the diagram). And this is coming from someone
with a development background!

Thanks,
Russ

Russell Wilson | Director of Product Design
NetQoS, Inc. | 5001 Plaza on the Lake, Austin, TX 78746
512.334.3725 | russell.wilson at netqos.com

NetQoS: Performance Experts
www.netqos.com

Comments

18 Jul 2006 - 10:00am
Sabine Junginger
2006

Hi Russel,

Unfortunately, the convenient solution of compartmentalizing and segmenting the design tasks and activities too often leads to products that have great components but miss the overall goal to serve their initial purpose. In the end, it leaves the responsibility to realize the design vision to the organization which may or may not have understood the design implications to begin with. And it leads to design assuming the role of icing the cake.

This is not to dismiss your concern about "designing by committee" also referred to as "designing by consensus." I think that the key to avoid this pitfall in a collaborative effort is for designers to generate a vision early in the project, to articulate this vision and to guard it. This in turn, requires designers to understand their role within the organization. Even managers often fail when they try to impose a vision onto their own organization. A designer or design team that is not even part of the business is in an even weaker position. Unless they work with an organizational champion and use design research strategically to deliver the arguments that support a new vision and persuades the organization about its feasibility and viability.

So, rather than retreat, I suggest a proactive stance for design. I am not sure what you are referring to as your "background in development." Are you talking about product development as in a PDMA sense or are you talking about organizational development? The latter might serve you better in this case. I am happy to talk to you more about the direct links between product development and organizational development.

Cheers,

Sabine
°·..·••

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> I don't believe in "design by committee". Specifically where the
> committee is made up of groups outside of design (development, product
> mgt., etc.)
>
> I'm not saying that I don't believe in collaboration. But I do not want to
> be in situations where I have to "compete" for design with non-designers.
> I cannot see how conceptual integrity can be achieved this way.
>
> And yet it seems that no matter where I go, no matter what level I reach
> within a company, development (and other groups) want some authority over
> interface design...
>
> Does anyone have any successful experiences to share regarding improving
> synergies between design/development? I would ultimately like to see
> development focus on implementation and feasibility and let design focus
> on design (desirability - for those who have seen the diagram). And this
> is coming from someone with a development background!
>
> Thanks, Russ
>
> Russell Wilson | Director of Product Design NetQoS, Inc. | 5001 Plaza on
> the Lake, Austin, TX 78746 512.334.3725 | russell.wilson at netqos.com
>
> NetQoS: Performance Experts www.netqos.com
>
>
>
> ________________________________________________________________ Welcome
> to the Interaction Design Association (IxDA)! To post to this list .......
> discuss at ixda.org List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/ (Un)Subscription
> Options ... http://subscription-options.ixda.org/ Announcements List
> ......... http://subscribe-announce.ixda.org/ Questions ..................
> lists at ixda.org Home ....................... http://ixda.org/ Resource
> Library ........... http://resources.ixda.org
>
>

18 Jul 2006 - 10:17am
John Grøtting
2006

Russel and Sabine,

We should probably explain what is meant by "design by committee".
Often, this is a term that a designer uses when their design
disappears into a group that makes decisions that aren't based on a
user-centered process. The designer is then left to implement the
changes.

I would say that any project that lacks a clear design process that
has repeatedly been used successfully will have problems.

On the other hand, I believe strongly in involving non-designers as
part of the internal team to gain feedback and guide the evolution of
a project. A collaborative process will definitely produce better
results than a designer working by himself/herself. The idea of the
lone genius designer developing a complete product design by
themselves is gone.

John Grøtting

Grøtting + Sauter
Barnerstr. 14B
22765 Hamburg
Germany

Tel +49.40.398.34342
SkypeIn +1.818.574.8440
Fax +49.40.398.34340
Mobile +49.172.4246.976
www.g-s.de
g at g-s.de

Am 18.07.2006 um 17:00 schrieb Sabine Junginger:

18 Jul 2006 - 10:54am
Robert Hoekman, Jr.
2005

> Does anyone have any successful experiences to share regarding
> improving synergies between design/development?

Always, always, always explain the *why* behind design decisions/suggestions
you make, and be able to make design decisions on a dime. Programmers are
task masters - they figure something out, build it, and move on. If you work
the same way (ar can at least provide the illusion that you do), and can
cite good reasons (based on research, testing, etc) for why your ideas are
the right way to go, then they'll see that you know what you're talking
about, that they don't understand your domain nearly as well as you do, and
start letting you do your thing.

When I started with my current employer, there was one developer in
particular that debated everything. *Everything*. So I always made my case,
tried to keep him focused on the dev side of things by discussing how the
design could be implemented, how the code could be reused, etc. Basically,
if I kept his mind on development and why my idea was good for him, he lost
interest in debating me and got more interested in implementation.
Eventually, he stopped debating me. He still does on occasion, to a much
less extreme degree, but for the most part, he's learned that I know what
I'm doing and has started accepting my decisions verbatim. Now, he comes to
me about almost everything.

In some cases, though, they'll do what they want regardless of what you say.
It's just a cold, hard fact when the inmates are allowed to run the asylum.

-r-

18 Jul 2006 - 10:58am
Robert Hoekman, Jr.
2005

> The idea of the
> lone genius designer developing a complete product design by
> themselves is gone.

Hardly. It happens every day in a lot of companies, and I'm a pretty big
advocate of it, providing the designer is genuinely that good.

-r-

18 Jul 2006 - 10:59am
Becubed
2004

> Does anyone have any successful experiences to share regarding
> improving synergies between design/development? I would
> ultimately like to see development focus on implementation
> and feasibility and let design focus on design

In my experience, the best (and maybe only?) way to achieve this is
for designers to simply produce great work. This is a politically-
charged situation and not one that can be changed through talk,
policy, or even process. But deliver top-notch designs that will help
build the business -- and you'll find people advocating for the
separation. Perhaps not in so many words, but there will be a rising
clamor for "more design!" from the development side of the shop.

--
Robert Barlow-Busch
Practice Director, Interaction Design
Quarry Integrated Communications Inc.
rbarlowbusch at quarry.com
(519) 570-2020

This e-mail message (including any attachments) is intended only for
the use of the individual to whom it is addressed and may contain
information that is privileged, proprietary, confidential or subject
to copyright. If you are not the intended recipient, you are
notified that any use, dissemination, distribution or reproduction of
this communication is strictly prohibited. If you have received this
communication in error, please notify the sender and delete this e-
mail message immediately.

18 Jul 2006 - 11:10am
John Schrag
2005

> Does anyone have any successful experiences to share regarding
> improving synergies between design/development? I would
> ultimately like to see development focus on implementation
> and feasibility and let design focus on design (desirability -
> for those who have seen the diagram). And this is coming from
> someone with a development background!

I hear you on this one.

One thing we've been doing with some success is getting all these people
together not for a 'design' meeting, but for a 'requirements' meeting.
This keeps everyone focussed on the problem they're trying to solve, and
not how to solve it. I ask questions like "what should the user be able
to do when we finish this that they can't do now? What other features
does this have to work with?". When the discussion gets to UI design
(as it always does), I say "I've noted that idea, but let's not worry
about details of the UI design until we get all the requirements down."

I find that it is useful to have developers, marketers, QA, etc involved
at this stage, because they are often aware of technical, competitive
and business requirements which are beyond what your user studies might
have shown.

We design the UI outside of that meeting, and then usability test and
refine it. Then we bring it back. We still run into debate about the
UI at this point, of course, but it's powerful to be able to say "Well,
it meets all the requirements we came up with together, and it tested
really well. Which part of that do you want to change?"

-john schrag
interaction designer
autodesk

18 Jul 2006 - 11:11am
Dan Saffer
2003

On Jul 18, 2006, at 7:38 AM, Wilson, Russell wrote:

> And yet it seems that no matter where I go, no matter what level
> I reach within a company, development (and other groups) want some
> authority over interface design...

Because everyone thinks they can do what we do. Ok-Cancel had a great
comic on this a few weeks ago:

http://www.ok-cancel.com/comic/137.html

> Does anyone have any successful experiences to share regarding
> improving synergies between design/development?

Alan Cooper in one of his books suggests that interaction designers
should have two reasons for every design decision they make. The
reason, he says, is for just this purpose: when people want authority
over your design, you have ammunition. Otherwise, your "opinion" is
just that, and everyone, right or wrong, can have one.

This is daunting, but it might be a direction to pursue.

Dan

18 Jul 2006 - 11:17am
russwilson
2005

Thanks Robert.

Always, always, always explain the *why* behind design
decisions/suggestions you make, and be able to make design decisions on
a

I agree, but sometimes given workload, it is tedious and possibly even
impossible to justify every little decision. To be honest, I don't
want to add another meeting to my already full calendar to explain why
the button has to be orange versus blue, and why the font should be
Trebuchet instead of Arial.

What we're trying to push/enforce in my company is having development
only give input about feasibility of designs (time to develop,
difficulty in implementing,
impact to existing code, etc.). No data on how successful this will
ultimately be.

When I started with my current employer, there was one developer in
particular that debated everything. *Everything*. So I always

Why is there always one (or more) of these? why, why, why... :-)

made my case, tried to keep him focused on the dev side of things by
discussing how the design could be implemented, how the code could be
reused, etc. Basically, if I kept his mind on development and why my
idea was good for him, he lost interest in debating me and got more
interested in implementation. Eventually, he stopped debating me. He
still does on occasion, to a much less extreme degree, but for the most
part, he's learned that I know what I'm doing and has started accepting
my decisions verbatim. Now, he comes to me about almost everything.

18 Jul 2006 - 11:17am
Peter Bagnall
2003

I've started describing this issue as "designer's don't come in boxes from the supermarket". It
appeals to my warped sense of humour, but the point is there appears to be a belief in some
quarters that if you have a "good methodology" and you get a "designer in a box" from the
supermarket, get the designer to follow your methodology - hey presto, you'll get good
design.

This is silly! Experience in the domain is important. For example, I'm working with older
people, and have been for a few years. I've learnt a great deal about the specific issues that
relate to deigning for older people and that experience means I can create better designs for
them on my own. The idea of a designer being an ultimate generalist is crazy. It's like asking
brain surgeon to do heart bypass! If I need a bypass I want a heart surgeon!

So my belief is that if you get a designer, designing in a domain in which they have a great
deal of experience, you often can get great design just by leaving them to it. You will almost
certainly want to to some testing to do a bit of polishing, and I still think that user research
should be part of the process even for experienced designers, but design by committee and
even sometimes by consensus won't be as good.

The rub here is that if you try to do this with a green designer its not going to work nearly as
well. And as a designer, if you hop from domain to domain all the time, you're pretty much
spending your whole life being green.

Cheers
--Pete

> [Please voluntarily trim replies to include only relevant quoted material.]
>
> > The idea of the
> > lone genius designer developing a complete product design by
> > themselves is gone.
>
>
> Hardly. It happens every day in a lot of companies, and I'm a pretty big
> advocate of it, providing the designer is genuinely that good.
>
> -r-
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>
>

18 Jul 2006 - 11:25am
russwilson
2005

Thanks Sabine.

This is not to dismiss your concern about "designing by committee" also
referred to as "designing by consensus." I think that the key to avoid
this pitfall in a collaborative effort is for designers to generate a
vision early in the project, to

[Russ]: Good point. On one product we have had the ability to do this
(define the vision early) and I've
had quite a bit of success. However, I'm encountering much more
difficult issues when redesigning existing
products where there are many problems, little to no conceptual
integrity, but developers are *defensive* of
their existing work.

So, rather than retreat, I suggest a proactive stance for design. I am
not sure what you are referring to as your "background in development."
Are you talking about product development as in a PDMA sense or are you
talking about

[Russ]: product development - specifically, programming/software
engineer many years ago

18 Jul 2006 - 12:13pm
russwilson
2005

On the other hand, I believe strongly in involving non-designers as part of the internal team to gain feedback and guide the evolution of a project. A collaborative process will definitely produce better results than a designer working by himself/herself. The idea of the lone genius designer developing a complete product design by themselves is gone.

[Russ]: I agree on most points, but then who makes the final call? In other words, I believe that design should take input and be collaborative
to a certain degree, but I don't agree that ultimately decisions should be decided through voting or some other "group" means. You have to
have someone making the final call (based on input from everyone).

18 Jul 2006 - 12:18pm
russwilson
2005

We design the UI outside of that meeting, and then usability test and
refine it. Then we bring it back. We still run into debate about the
UI at this point, of course, but it's powerful to be able to say "Well,
it meets all the requirements we came up with together, and it tested
really well. Which part of that do you want to change?"

[Russ]: Yes - I've gotten good results from that as well. It's hard to
argue against the test results. Unfortunately sometimes (only
sometimes) we don't have the time to conduct tests until later. Not
good, but reality. It may be that
we are making a very small change (relatively) that needs to go out
quick.

18 Jul 2006 - 8:24pm
Lada Gorlenko
2004

WR> it is tedious and possibly even impossible to justify every little
WR> decision. To be honest, I don't want to add another meeting to my
WR> already full calendar to explain why the button has to be orange
WR> versus blue, and why the font should be Trebuchet instead of Arial.

One thing I learned working in large teams is to pick my fights. If
someone desperately needs Arial (for whatever reason), is it *really
important* to use Trebuchet or is it because *you* want it? And if
it's not Trebuchet, what's the loss?

I've also learned that developers in particular can be your good
friends, if you listen to their "design opinions" carefully. A couple
of developers improved my designs because they knew the underlying
product technology better. Although my designs seemed optimal from the
design perspective, they were not so overall, given the technological
constraints we had to work with. I am ever so grateful to my
development teams for their help.

Think big and fight big. Separate design critical decisions from
the rest. Trade non-critical decisions, if they buy peace and
progress. Don't come across as someone who always wants to be right
about design, even if this is exactly what you are paid to do. Come
across as someone who fights only when the fight is worth it. If
someone's design decision is a politically important matter of taste
with little real impact, skip it; if it can turn into serious matter,
do stick to your expertise by all means.

On the "blue vs. orange button" (did you make up your example?), see
Telegraph's article "Baby died after untrained doctor took 50-50
gamble on pressing right button":
http://www.telegraph.co.uk/news/main.jhtml?xml=/news/2006/03/21/nhs121.xml)

Lada

18 Jul 2006 - 11:49am
Sean Voisen
2006

>
> And yet it seems that no matter where I go, no matter what level
> I reach within a company, development (and other groups) want some
> authority over interface design...

New to the list here ... I actually tend to have the opposite problem right
now. We are a small startup of five people and I'm the lone designer
working with two programmers (a la 37signals style) on a blended learning
(online and offline learning) solution. Soliciting the opinions of everyone
else on some of my design decisions usually elicits simple agreement
responses rather than constructive criticism or further suggestions. It
seems like they tend to assume that I'm going to make the best decisions
anyway because I tend to have the most ideas, and whatever I do will be
great, but of course I question myself sometimes.

Design by committee is definitely a problem as well (been there, done that),
but I think there is some sort of balance between the lone genius designer
and the overkill of the committee ...

Cheers,
- Sean
http://voisen.org

18 Jul 2006 - 12:31pm
Sabine Junginger
2006

> I'm encountering much more difficult issues when redesigning existing
> products where there are many problems, little to no conceptual integrity,
> but developers are *defensive* of their existing work.

You might have already tried this, but from my experience it is very effective to demonstrate the consequences of the conceptual *dis*integrity from a user's perspective, documenting the resulting disconnects and detours in terms of the user pathway. Many developers do not understand these consequences until they hear it directly from the people they think they know so well. Once you introduce the user, user pathways and user experience, the tension is no longer between the old "designers" (which is what most developers consider themselves to be) and the new design experts, but about the need to make it easier and more enjoyable for people external to the organization to use their products.

We did this at Carnegie Mellon during the Domestic Mail Manual Project for the United States Postal Service. Here, seasoned experts from the postal service headquarters with an incredible capacity for small print learned to view the world through the eyes of their customers. Our user research produced arguments that were difficult to ignore. The issues became visible and audible while none of the designers ever said "you guys did a terrible job and we are here to rescue the situation."

It is still important for a redesign project to establish and to agree on vision early on. As John's example beautifully shows, this allows the design team to keep things in flux--or as Gehry would say, "liquid"--for as long as possible, rather than forcing decisions on details upfront that would forestall a genuinely different approach or distract from the core purpose.

Sabine
°·..·••

> So, rather than retreat, I suggest a proactive stance for design. I am not
> sure what you are referring to as your "background in development." Are
> you talking about product development as in a PDMA sense or are you
> talking about
>
> [Russ]: product development - specifically, programming/software engineer
> many years ago
>
>
>

18 Jul 2006 - 1:55pm
bhekking
2006

> When the discussion gets to UI design
> (as it always does), I say "I've noted that idea, but let's not worry
> about details of the UI design until we get all the requirements down."
This approach has worked for me as well. Since I began focusing on design &
usability (rather than implementation...in a former life) I've had to be
vigilant about catching and deflecting the "what vs. how" tendencies of
stakeholders.

I do my best to make sure we all agree on (and write down) the problem we're
solving, for whom, and what the priorities are. Then, I'll sketch a few ideas,
get feedback if I can, *then* start scheduling design sessions.

> I find that it is useful to have developers, marketers, QA, etc involved
> at this stage
Early on, I like to invite "special guests" to design sessions - stakeholders
who are not involved with the project - for feedback. We almost always learn
something new that matters to the design.

> We design the UI outside of that meeting, and then usability test and
> refine it. Then we bring it back. We still run into debate about the
> UI at this point, of course, but it's powerful to be able to say "Well,
> it meets all the requirements we came up with together, and it tested
> really well. Which part of that do you want to change?"
I've found that partners/customers/users comments usually win the debate for
me. If I've done my homework and vetted early ideas with external stakeholders,
internal design sessions focus on users and tasks rather than peoples' personal
opinions.

Finally, your mileage will vary as each company's culture and level of
experience with "design" as part of the development process will have a major
influence on what you're able to achieve.

Bret Hekking
Sr. UX Designer
Applix, Inc.

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

18 Jul 2006 - 2:11pm
leo.frishberg a...
2005

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

18 Jul 2006 - 3:05pm
Robert Hoekman, Jr.
2005

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

You need to be careful about how you present arguments like this, however.
Design is often a pretty fun thing for a developer, and your taking it away
is not something they're going to like in a lot of cases. Be diplomatic and
graceful about how you do this.

-r-

18 Jul 2006 - 3:44pm
leo.frishberg a...
2005

Excellent advice and certainly why I qualified it in my original
posting.

However, you raise an interesting observation: "design is often a pretty
fun thing for a developer..." I think this is one of the hinge pieces
of this discussion. "Design is fun..." where their "real" job isn't? I
would propose that we all can have "fun" taking a stab at someone else's
profession, whether it be marketing, coding, hardware design, mechanical
engineering...you name it...and perhaps we should every once in awhile.
But whether we enjoy doing these other activities as "hobbies" isn't the
point.

We're about making world-class experiences and in these contexts there
is little room for amateur participation. Get the best team together,
aligned to do their jobs with passion, and let them enjoy the activity
of creating great products.

I make my analogy because I am as well suited to doing chip design as
many hardware designers are suited to thinking about behavioral aspects
of being a human. This isn't any more a slight to these professionals
than it is to my lack of technical expertise in their arena. That
historically our teams have considered the "messiness" of being human a
roadblock to creating good products (rather than the inspiration)
shouldn't be a defense for continuing to promote this belief.

Still, I appreciate your concern that sarcasm can be easily
misunderstood and should be applied sparingly.

Leo

-----Original Message-----
From: Robert Hoekman, Jr. [mailto:rhoekmanjr at gmail.com]
Sent: Tuesday, July 18, 2006 1:05 PM
To: Frishberg, Leo
Cc: discuss at ixda.org
Subject: Re: [IxDA Discuss] design by committee??

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.

You need to be careful about how you present arguments like
this, however. Design is often a pretty fun thing for a developer, and
your taking it away is not something they're going to like in a lot of
cases. Be diplomatic and graceful about how you do this.

-r-

18 Jul 2006 - 5:28pm
russwilson
2005

However, you raise an interesting observation: "design is often a pretty
fun thing for a developer..." I think this is one of the hinge pieces
of this discussion. "Design is fun..." where their "real" job isn't? I
would propose that we all can

[Russ]: The product interface receives the most attention from
non-developers. Marketing, sales, etc.,
all comment on the interface, not the underlying algorithms. So by
taking this piece "away", developers
lose some "pats on the back".

I was a programmer and I can tell you that I had a strong sense of
accomplishment
in implementing algorithms that worked (database implementation, the
networking communication to support
client-server applications, etc.). But, outside of development, there
are few if any individuals or groups
that recognize these efforts (other than the tangible results like good
performance, etc.)

So, on the one hand I keep arguing that developers should focus their
expertise and creative talents on
good *implementations* and leave design to design, and I can't
understand why that's a problem. Then on the
other, I attend meetings where product managers get visibly excited
about the "new interface" and compliment
me over and over without saying a word to the developers...

18 Jul 2006 - 6:00pm
Robert Hoekman, Jr.
2005

And bad management is not something you can overcome unless you're the
manager. :)

-r-

On 7/18/06, Wilson, Russell <Russell.Wilson at netqos.com> wrote:
>
>
> However, you raise an interesting observation: "design is often a pretty
> fun thing for a developer..." I think this is one of the hinge pieces
> of this discussion. "Design is fun..." where their "real" job isn't? I
> would propose that we all can
>
> [Russ]: The product interface receives the most attention from
> non-developers. Marketing, sales, etc.,
> all comment on the interface, not the underlying algorithms. So by
> taking this piece "away", developers
> lose some "pats on the back".
>
> I was a programmer and I can tell you that I had a strong sense of
> accomplishment
> in implementing algorithms that worked (database implementation, the
> networking communication to support
> client-server applications, etc.). But, outside of development, there
> are few if any individuals or groups
> that recognize these efforts (other than the tangible results like good
> performance, etc.)
>
> So, on the one hand I keep arguing that developers should focus their
> expertise and creative talents on
> good *implementations* and leave design to design, and I can't
> understand why that's a problem. Then on the
> other, I attend meetings where product managers get visibly excited
> about the "new interface" and compliment
> me over and over without saying a word to the developers...
>
>

18 Jul 2006 - 8:22pm
Dave Cronin
2005

This is an interesting one... and i love that ok/cancel strip. thanks for passing along ;)

My $.02 on techniques for working with the design by committee/consensus situation:

- Base your decisions on ethnographic research. I've found few things that silence critics as quickly as apt anecdotes and observed behavior patterns.

- Define (and agree on!) the problem before proposing or evaluating solutions.

- Figure out constructive ways for the whole project team to participate early enough in the process to entertain divergent thinking without it becoming counterproductive. I'm not necessarily advocating playing with legos or brainstorming (though those are both fun).

- Depersonalize solutions by focusing on serving the needs of personas/user models/roles/whatever you like to use (i.e. it's not about "my idea" versus "your idea," but about serving the needs of "nancy.") This also helps with the defining the problem bit.

- Be willing to throw your ideas out. If you're a good designer, and you've got a strong solution to a complex problem, my experience is that nothing is going to freak the team out more than going back to a blank slate. After about 5 minutes they usually come running back to what you proposed (though whether they give you credit for it is another question ;).

[my apologies if i'm repeating stuff that's already been said; I just read through the thread at once and might have missed something.]

-dave

__

Cooper | Product Design for a Digital World

David Cronin
Director of Interaction Design
dave at cooper.com

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com on behalf of Wilson, Russell
Sent: Tue 7/18/2006 7:38 AM
To: discuss at ixda.org
Subject: [IxDA Discuss] design by committee??

[Please voluntarily trim replies to include only relevant quoted material.]

I don't believe in "design by committee". Specifically
where the committee is made up of groups outside of design
(development, product mgt., etc.)

I'm not saying that I don't believe in collaboration. But I do
not want to be in situations where I have to "compete" for design
with non-designers. I cannot see how conceptual integrity can be
achieved this way.

And yet it seems that no matter where I go, no matter what level
I reach within a company, development (and other groups) want some
authority over interface design...

Does anyone have any successful experiences to share regarding
improving synergies between design/development? I would
ultimately like to see development focus on implementation
and feasibility and let design focus on design (desirability - for
those who have seen the diagram). And this is coming from someone
with a development background!

Thanks,
Russ

Russell Wilson | Director of Product Design
NetQoS, Inc. | 5001 Plaza on the Lake, Austin, TX 78746
512.334.3725 | russell.wilson at netqos.com

NetQoS: Performance Experts
www.netqos.com

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

18 Jul 2006 - 10:26pm
John Grøtting
2006

While we can discuss how the UX designer can improve the situation a
bit, this is really a management issue. That may sound odd, but the
ability to put in place good teams with good processes is the role of
management. If everyone understands their roles and how they can
contribute to a common vision, then these issues seldom come up.

In one team it may be less of an issue what typeface is chosen for a
menu, whereas in another the product may live and die by the
typography. If the whole team doesn't have a common understanding of
the underlying goals that drive design decisions, then we run into
conflict.

John Grøtting
Grøtting + Sauter
Barnerstr. 14
22605 Hamburg
Germany

MOBILE +49.0172.4246976
TEL +49.40.398.34342
FAX +49.40.398.34340
www.g-s.de

18 Jul 2006 - 11:10pm
Joshua Gross
2006

> Date: Tue, 18 Jul 2006 09:38:28 -0500
> From: "Wilson, Russell" <Russell.Wilson at netqos.com>
> Subject: [IxDA Discuss] design by committee??

> Does anyone have any successful experiences to share regarding
> improving synergies between design/development? I would

I can heartily recommend Bringing Design to Software, an edited book by
Terry Winograd. In particular, you may want to look at chapter 8, "The
Designer's Stance". This book is an excellent followup to Norman's
DoET.

-Josh

19 Jul 2006 - 7:44am
Todd Warfel
2003

First and foremost, when faced with design by committee, data is your
best defense and offense. If you have the data to back up your design
decisions, then it becomes more difficult for the committee to
challenge. They'll still try, but data typically beats out opinion.

A few practices we live by at Messagefirst that have helped over the
years:
1. Base decisions on data, not opinion.
2. Use multiple research methods to gather data (e.g. interviews,
ethnography, card sorting, usability testing)
3. Create a set of personas based on multiple inputs. We always use
three: the business unit, customers (or customer advocates), and
someone we know personally that fits the profile - this helps keep us
grounded.
4. Discuss design decisions around the personas, not around anyone's
opinion at the table or "the average user." The average user
translates to "Here's what I think, based on my experience..."
5. Have a plan B. Having a plan B enables you to compromise when
necessary, but still come up with a good design decision.
6. Design. Test. Adjust.

As a quick example, earlier this year, when working on the redesign
for a financial research firm, we insisted on doing usability testing
up front on the existing site to gather data on what worked and what
didn't, and more importantly to what extent things were broken
(severity). The partnering firm we worked with didn't sell usability
testing up front as they should have because "They didn't think the
client wanted to do it."

Several weeks later, when we were discussing some innovative design
ideas, something very different from what they had done in the past,
something that nobody else in their space was doing yet, but
something we've done in another space, tested and which performed
incredibly well, the client wouldn't bite. We could back it up with
data from the other space we'd done it in, but they were concerned
that it wouldn't work in their space and we didn't have any testing
data for them to back up our claims.

After the meeting, our partnering firm told said, "Well, let that be
a lesson to us. Todd, I should have listened to you and insisted that
we do testing up front. In the future, we'll make sure we make that
part of the proposal."

Data. It makes a real difference.

On Jul 18, 2006, at 9:22 PM, Dave Cronin wrote:

> - Base your decisions on ethnographic research. I've found few
> things that silence critics as quickly as apt anecdotes and
> observed behavior patterns.
>
> - Define (and agree on!) the problem before proposing or evaluating
> solutions.
>
> - Figure out constructive ways for the whole project team to
> participate early enough in the process to entertain divergent
> thinking without it becoming counterproductive. I'm not necessarily
> advocating playing with legos or brainstorming (though those are
> both fun).
>
> - Depersonalize solutions by focusing on serving the needs of
> personas/user models/roles/whatever you like to use (i.e. it's not
> about "my idea" versus "your idea," but about serving the needs of
> "nancy.") This also helps with the defining the problem bit.

Cheers!

Todd R. Warfel
Partner, Design & Usability Specialist
Messagefirst | designing and usability consulting
--------------------------------------
Contact Info
Voice: (607) 339-9640
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.

19 Jul 2006 - 8:11am
Dave Malouf
2005

Does anyone else feel that all this talk of data is a but problematic.

It kinds feel like the best designs are from passionste creativity more than from data. Maybe this speaks to Chris' thread from last week.

Dave

Sent from my Verizon Wireless BlackBerry

19 Jul 2006 - 9:15am
bhekking
2006

> - Base your decisions on ethnographic research. I've found few things that
> silence critics as quickly as apt anecdotes and observed behavior patterns.
That is, if you can get some. I've had to rely a lot on user surrogates,
'assumption personas', and prior research since I don't yet have the green
light to venture into the field to get real data.

> - Define (and agree on!) the problem before proposing or evaluating
> solutions.
By now, this should be obvious...but I have plenty of evidence to the contrary.
In almost every meeting I attend, my first words are: "What are our objectives
for this meeting?" This also speaks to the tendency most requirements
docs/discussions have to focus on "how" instead of "what".

> - Figure out constructive ways for the whole project team to participate
> early enough in the process to entertain divergent thinking without it
> becoming counterproductive. I'm not necessarily advocating playing with legos
> or brainstorming (though those are both fun).
One method I've used is to be the official scribe during design sessions. I
take copious notes, record decisions made, then iterate the design and bring it
back for another round. Typically, no one else wants to do this, so it enables
me to steer the discussion, or at least its content.

> - Depersonalize solutions by focusing on serving the needs of personas/user
> models/roles/whatever you like to use (i.e. it's not about "my idea" versus
> "your idea," but about serving the needs of "nancy.") This also helps with
> the defining the problem bit.
Yes - this is critical. I believe that design cannot even begin without
identifying personas/user profiles. When design becomes an opinion battle, it's
time to refocus the discussion or revisit your assumptions about users.

> - Be willing to throw your ideas out. If you're a good designer, and you've
> got a strong solution to a complex problem, my experience is that nothing is
> going to freak the team out more than going back to a blank slate. After
> about 5 minutes they usually come running back to what you proposed (though
> whether they give you credit for it is another question ;).
This is probably the toughest part of being a designer (or an engineer as I
once was), especially with higher-fidelity work. I've tried hard lately to
avoid using software for concepting for just this reason.

Best to all of you,
Bret Hekking
Sr. UX Designer, Applix, Inc

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

19 Jul 2006 - 9:26am
Dan Saffer
2003

On Jul 19, 2006, at 6:11 AM, Dave at ixda.org wrote:

> Does anyone else feel that all this talk of data is a but problematic.

Semantics: Data is probably the wrong word, because it implies fact,
which can be hard to "prove" when it comes to interaction design.
"Justification" and/or "reasoning" might be better terminology.

Dan

19 Jul 2006 - 9:27am
russwilson
2005

I think that data can be used successfully to backup
functional design decisions. You can test different interaction
methods on users and measure efficiency, effectiveness, etc.
(e.g. sequence of screens to support taskflow)

But it's more difficult to test whether or not "orange" is
better than "blue" (my made up example). This is the area that
sparked my original email because it's a little more subjective,
and in my opinion should be left up to the design team without
requiring extensive justification and committee approval.
(note that I say "extensive")

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
Dave at ixda.org
Sent: Wednesday, July 19, 2006 8:11 AM
To: Todd Warfel; discuss-bounces at lists.interactiondesigners.com
Cc: discuss at ixda.org
Subject: Re: [IxDA Discuss] design by committee??

[Please voluntarily trim replies to include only relevant quoted
material.]

Does anyone else feel that all this talk of data is a but problematic.

It kinds feel like the best designs are from passionste creativity more
than from data. Maybe this speaks to Chris' thread from last week.

Dave

Sent from my Verizon Wireless BlackBerry
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org List Guidelines
............ http://listguide.ixda.org/ List Help ..................
http://listhelp.ixda.org/ (Un)Subscription Options ...
http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org Home .......................
http://ixda.org/ Resource Library ........... http://resources.ixda.org

19 Jul 2006 - 9:33am
Sabine Junginger
2006

Hi Dave,

Passion can both inspire and guide designers. The skill of a good designer is to know when to let go and when to reign in again. I am not saying abandon passion. "Data" can aid designers directing their passion towards a useful, usable and desirable solution. Perhaps you are using the term data too strictly and are not aware of the kinds of data that you are already using when you are designing? The best designs are often those that have to deal with the biggest constraints. Constraints are data that have been interpreted by someone as a restriction, no? Denying data a role in design is to reduce design to a random, accidental exercise.

I read once that you can get away with murder in France as long as you can make a case that you did it out of passion
The French, the book said, understand how passion can drive you to do crazy things. I guess this calls for a study on French design?

Sabine
°·..·••

>
> Does anyone else feel that all this talk of data is a but problematic.
>
> It kinds feel like the best designs are from passionste creativity more
> than from data. Maybe this speaks to Chris' thread from last week.
>
> Dave
>
> Sent from my Verizon Wireless BlackBerry
> ________________________________________________________________ Welcome
> to the Interaction Design Association (IxDA)! To post to this list .......
> discuss at ixda.org List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/ (Un)Subscription
> Options ... http://subscription-options.ixda.org/ Announcements List
> ......... http://subscribe-announce.ixda.org/ Questions ..................
> lists at ixda.org Home ....................... http://ixda.org/ Resource
> Library ........... http://resources.ixda.org
>
>

19 Jul 2006 - 9:39am
John Grøtting
2006

I agree. I like think of testing as a way of ensuring that the
designer is making "informed decisions", when he/she is working. The
benefit to having multiple people around is to help interpret testing
and getting a better understanding of what feedback was relevant.

John Grøtting

Grøtting + Sauter
Barnerstr. 14B
22765 Hamburg
Germany

Tel +49.40.398.34342
SkypeIn +1.818.574.8440
Fax +49.40.398.34340
Mobile +49.172.4246.976
www.g-s.de
g at g-s.de

Am 19.07.2006 um 16:27 schrieb Wilson, Russell:

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> I think that data can be used successfully to backup
> functional design decisions. You can test different interaction
> methods on users and measure efficiency, effectiveness, etc.
> (e.g. sequence of screens to support taskflow)
>
> But it's more difficult to test whether or not "orange" is
> better than "blue" (my made up example). This is the area that
> sparked my original email because it's a little more subjective,
> and in my opinion should be left up to the design team without
> requiring extensive justification and committee approval.
> (note that I say "extensive")
>
>

19 Jul 2006 - 9:49am
Dave Malouf
2005

> On Jul 19, 2006, at 6:11 AM, Dave at ixda.org wrote:
>
> > Does anyone else feel that all this talk of data is a but
> problematic.
>
> Semantics: Data is probably the wrong word, because it implies fact,
> which can be hard to "prove" when it comes to interaction design.
> "Justification" and/or "reasoning" might be better terminology.

While I understand the thread is about how to break "design by committee"
type situations and what ammunition can we bring to these situations to help
us "defend" our designs so I see how data of any type can be useful
ammunition in that regard.

To fill in a bit more, now that I'm not on a blackberry ...

Design by committee to me is a failure of organization first, and then a
failure of communication second.

It is about not having the right relationships in place before a project
begins, about not having clear roles and responsibilities set up, and not
working in a collaborative manner through the design process.

Often design is seen as a black box. Stakeholders are not included through
the design process. They may be included through research and even included
through the analysis of that research, but they are seldom included past
that.

Inclusion does not mean:
1. people doing design
2. people reviewing design

It is a very tricky and sometimes slippery slope, but finding that right
balance between real inclusion into the design process, design by committee,
and reviewer shock is tough to find.

What people want is that they are are being listened to. Too often this is
interpretted to mean, "Ok, I'll do your suggestion literally." It is really
up to you as designer to find empathy with your stakeholders and deconstruct
the goals of the suggestions being made.

Do not concede to design decisions in a meeting. Listen in meetings, but
don't design or decide in meetings. Hold onto your ownership of the design.

But as I said, the real dilemna is in the relatioships. If you get to this
point where you feel that stakeholders are doing your job you really already
lost. I have had full specific data in meetings like these and still a sr.
stakeholder said, "I want it 'white on white' because I said so." To me this
is just lost confidence in the designer.

On a tangent but related, the best thing you can do to help people feel you
are on their side and listening, is to do many many small concenssions
around those issues that are unimportant. The class line of "pick your
battles" is important, but also the best relationships are built on guided
compromise. If you have a clear articulated vision, get buy-in on that
vision, and constantly and accurrately and consistently reference that
vision with your design decisions, you will gain so much confidence in your
stakeholders. It is also important to concede where you make mistakes, and
even allow others to bring their own thinking into the design when their
ideas are appropriate.

The latter piece should not be done in the meeting. It should be done
outside the meeting. 1) it shows that you have a reflection process. 2)
people will get that you listen and will learn that you are not an
ego-maniac.

Anyway, I'm sorta going all over the place.

I'm not saying that data is the devil. I'm just saying that if you are
"relying" on data to stop design by committee, you are possibly already too
late. Relationships, articulated and consistently adhered to design
vision/direction with proper buy-in, collaborative design processes, etc.
are all much stronger, repeatable, and longer lasting at avoiding the
"design by committee" problems that started this thread.

-- dave

19 Jul 2006 - 12:05pm
Dave Cronin
2005

I don't see that being informed about the human beings you are working
to serve is at all at odds with being passionate and creative.

In my experience, spending time upfront with users feeds my intuition
and sparks my imagination in ways that nothing else does.

I agree with Dan's comment about the use of the word "data." While there
is certainly some quantitative market research and usability data that
can be useful in ideation and justification, I'm really more interested
in qualititative data: *how* rather than *how many.*

-dave

> Dave at ixda.org:
>
> Does anyone else feel that all this talk of data is a but
> problematic.
>
> It kinds feel like the best designs are from passionste
> creativity more than from data. Maybe this speaks to Chris'
> thread from last week.

19 Jul 2006 - 12:25pm
leo.frishberg a...
2005

<Dave wrote>

Anyway, I'm sorta going all over the place.

I'm not saying that data is the devil. I'm just saying that if you are
"relying" on data to stop design by committee, you are possibly already
too
late. Relationships, articulated and consistently adhered to design
vision/direction with proper buy-in, collaborative design processes,
etc.
are all much stronger, repeatable, and longer lasting at avoiding the
"design by committee" problems that started this thread.

-- dave </Dave wrote>

I agree completely with everything you wrote in your expanded post, and
I understand your focus around data in this snippet.

In my context, a "test and measurement" company, data is king. All of
the Electronic Engineers (EEs) here are so data driven that the very
first interview I had for the job emphasized that if I was to sway
anyone about anything, I better have the "data to back it up."

Now, enough has been said about when and how data can be leveraged. My
point is that in my context at least, Data turns out to be ::the::
primary means I have of improving people's confidence in my proposals.
"Design" is not well understood in my context ( a thread I don't want to
start right now), and any proposals that rest on "design" as a metric
have no mutually understandable framework.

Leo

19 Jul 2006 - 12:29pm
Rajesh Sidharthan
2005

"Assumption Personas".. Yes I have had to work with that a lot.
When you are in such a situation, make sure that the whole team agrees on the same set of assumptions before you start design.

Even when you are very clear about "what" your design is supposed to address, there could be a few ways to achieve that.
I have seen the dev teams and the PM's constructively suggesting different but compelling ideas during this phase.

The best approach is to evaluate these ideas just like one of yours.
Prototype and test them if needed.

To be a successful designer is not to be the only person who comes up with bright design ideas.
But also to be a moderator who can evaluate any ideas against the need.

~Raj

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com]On Behalf Of Bret
Hekking
Sent: Wednesday, July 19, 2006 7:16 AM
To: discuss at ixda.org
Subject: Re: [IxDA Discuss] design by committee??

[Please voluntarily trim replies to include only relevant quoted material.]

> - Base your decisions on ethnographic research. I've found few things that
> silence critics as quickly as apt anecdotes and observed behavior patterns.
That is, if you can get some. I've had to rely a lot on user surrogates,
'assumption personas', and prior research since I don't yet have the green
light to venture into the field to get real data.

> - Define (and agree on!) the problem before proposing or evaluating
> solutions.
By now, this should be obvious...but I have plenty of evidence to the contrary.
In almost every meeting I attend, my first words are: "What are our objectives
for this meeting?" This also speaks to the tendency most requirements
docs/discussions have to focus on "how" instead of "what".

> - Figure out constructive ways for the whole project team to participate
> early enough in the process to entertain divergent thinking without it
> becoming counterproductive. I'm not necessarily advocating playing with legos
> or brainstorming (though those are both fun).
One method I've used is to be the official scribe during design sessions. I
take copious notes, record decisions made, then iterate the design and bring it
back for another round. Typically, no one else wants to do this, so it enables
me to steer the discussion, or at least its content.

> - Depersonalize solutions by focusing on serving the needs of personas/user
> models/roles/whatever you like to use (i.e. it's not about "my idea" versus
> "your idea," but about serving the needs of "nancy.") This also helps with
> the defining the problem bit.
Yes - this is critical. I believe that design cannot even begin without
identifying personas/user profiles. When design becomes an opinion battle, it's
time to refocus the discussion or revisit your assumptions about users.

> - Be willing to throw your ideas out. If you're a good designer, and you've
> got a strong solution to a complex problem, my experience is that nothing is
> going to freak the team out more than going back to a blank slate. After
> about 5 minutes they usually come running back to what you proposed (though
> whether they give you credit for it is another question ;).
This is probably the toughest part of being a designer (or an engineer as I
once was), especially with higher-fidelity work. I've tried hard lately to
avoid using software for concepting for just this reason.

Best to all of you,
Bret Hekking
Sr. UX Designer, Applix, Inc

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

19 Jul 2006 - 12:48pm
Dave Malouf
2005

> Now, enough has been said about when and how data can be
> leveraged. My
> point is that in my context at least, Data turns out to be ::the::
> primary means I have of improving people's confidence in my proposals.
> "Design" is not well understood in my context ( a thread I
> don't want to
> start right now), and any proposals that rest on "design" as a metric
> have no mutually understandable framework.

Hi Leo,

I've been at the engineering world.
I think the long term mission (if you choose to take it) is to evangelize
design for design's sake.
I'm sure using data will be a HUGE part of that evangelism.
I also think bringing people into your process outside of the #'s gathering
will go a long way towards that evangelism and towards the end of design by
committee. I think that long term, constantly having to fall back on data is
a double-edged sword for designers. *Sometimes* the right design goes
against the data. Leaps of faith is what makes design really exciting and
break to the next level.

-- dave

19 Jul 2006 - 12:48pm
Cindy Alvarez
2004

>
> I'm not saying that data is the devil. I'm just saying that if you are
> "relying" on data to stop design by committee, you are possibly already
> too
> late. Relationships, articulated and consistently adhered to design
> vision/direction with proper buy-in, collaborative design processes, etc.
> are all much stronger, repeatable, and longer lasting at avoiding the
> "design by committee" problems that started this thread.

True, but folks who work with external stakeholders are less likely to have
control over that. Internally, I work with great org structure and
processes. When working with clients, it's usually one of two extremes -
total "design by committee" or total "design anarchy" (designers making
pretty screens with zero knowledge of the product/business goals).

In either case, the tactic that works well for me is to always ask why. Is
there a specific concern you're trying to address? What is the problem
you're looking to solve? It tends to diffuse the personal opinion
clutter, and helps people feel listened-to. I've often found that a
stakeholder demand is a bad solution to a valid problem, and opening up that
discussion gives me an opportunity to find a better solution that is a
win-win. Sometimes a stakeholder is locked-in ("we already have similar
pages in our website/webapp and have to be consistent") and I have no room
to negotiate, but at least everyone knows where they stand in that case.

Cindy

19 Jul 2006 - 12:55pm
Dave Malouf
2005

HI Cindy, there is no contradiction here to what I'm saying and you are
saying. In fact, I think you elaborate on an important piece of what I was
trying to communicate as well, that is the piece about collaborating and
deconstructing. Your asking Why is a great example of how to do just that.
Thanx!
-- dave

_____

In either case, the tactic that works well for me is to always ask why. Is
there a specific concern you're trying to address? What is the problem
you're looking to solve? It tends to diffuse the personal opinion
clutter, and helps people feel listened-to. I've often found that a
stakeholder demand is a bad solution to a valid problem, and opening up that
discussion gives me an opportunity to find a better solution that is a
win-win. Sometimes a stakeholder is locked-in ("we already have similar
pages in our website/webapp and have to be consistent") and I have no room
to negotiate, but at least everyone knows where they stand in that case.

19 Jul 2006 - 1:02pm
bhekking
2006

A resource I turn to often for 'design process' guidance is Scott Berkun's "The
Art of Project Management".
I find it's essential as a 'gut check' for how a healthy product
planning/design process is 'supposed to' work.

http://tinyurl.com/hxylu

- Bret

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

19 Jul 2006 - 7:16pm
Dave Cronin
2005

> Raj said:
>
> To be a successful designer is not to be the only person who
> comes up with bright design ideas.
> But also to be a moderator who can evaluate any ideas against
> the need.

This is so true!

By being a facilitator rather than a director, you help the rest of the
team get invested in the solution. Who cares whose idea it was
orginally?

-d

21 Jul 2006 - 3:44am
dszuc
2005

Agree.

Are you designing for yourself or for the greater good of the products and
its business success? Its all too easy to get locked into thinking you have
the best & only solution.

Suggest its important to not only communicate your own design but to
facilitate openly to improve it & understand constraints.

Rgds,

Daniel Szuc
Principal Usability Consultant
Apogee Usability Asia Ltd
www.apogeehk.com
'Usability in Asia'

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Dave
Cronin
Sent: Thursday, July 20, 2006 8:16 AM
To: rajesh.sidharthan at oracle.com; Bret Hekking; discuss at ixda.org
Subject: Re: [IxDA Discuss] design by committee??

[Please voluntarily trim replies to include only relevant quoted material.]

> Raj said:
>
> To be a successful designer is not to be the only person who
> comes up with bright design ideas.
> But also to be a moderator who can evaluate any ideas against
> the need.

This is so true!

By being a facilitator rather than a director, you help the rest of the team
get invested in the solution. Who cares whose idea it was orginally?

-d

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/ (Un)Subscription
Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

21 Jul 2006 - 8:53am
russwilson
2005

I think this "sounds good" in theory, but is difficult to
do well in practice.

Communicate, facilitate, elaborate, collaborate... (can you feel
the time slipping by?)

And I'm really not sure how you facilitate an award-winning design?
If you're "facilitating", you're not designing, right? Unless you're
thinking that there is a "facilitator" (or "decider" in Bush-speak) that
isn't really a designer, but manages a team of designers?

If several people skilled in different areas provide input
to guide the design process (constraints, use cases, etc.),
that's one thing.

But, if several people skilled in different areas collaborate
on the design and vote democratically on the ultimate design,
I believe you have a problem.

This is not ego based; I am not the best designer in the world.
But, I do believe that ultimately one person needs to have authority
over design for conceptual integrity, along with the standard
checks and balances (so that your new enterprise portal is not based
on the infamous hotdog stand color scheme)

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
Daniel Szuc
Sent: Friday, July 21, 2006 3:44 AM
To: discuss at ixda.org
Subject: Re: [IxDA Discuss] design by committee??

[Please voluntarily trim replies to include only relevant quoted
material.]

Agree.

Are you designing for yourself or for the greater good of the products
and its business success? Its all too easy to get locked into thinking
you have the best & only solution.

Suggest its important to not only communicate your own design but to
facilitate openly to improve it & understand constraints.

Rgds,

Daniel Szuc
Principal Usability Consultant
Apogee Usability Asia Ltd
www.apogeehk.com
'Usability in Asia'

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
Dave Cronin
Sent: Thursday, July 20, 2006 8:16 AM
To: rajesh.sidharthan at oracle.com; Bret Hekking; discuss at ixda.org
Subject: Re: [IxDA Discuss] design by committee??

[Please voluntarily trim replies to include only relevant quoted
material.]

> Raj said:
>
> To be a successful designer is not to be the only person who comes up
> with bright design ideas.
> But also to be a moderator who can evaluate any ideas against the
> need.

This is so true!

By being a facilitator rather than a director, you help the rest of the
team get invested in the solution. Who cares whose idea it was
orginally?

-d

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org List Guidelines
............ http://listguide.ixda.org/ List Help ..................
http://listhelp.ixda.org/ (Un)Subscription Options ...
http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org Home .......................
http://ixda.org/ Resource Library ........... http://resources.ixda.org

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org List Guidelines
............ http://listguide.ixda.org/ List Help ..................
http://listhelp.ixda.org/ (Un)Subscription Options ...
http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org Home .......................
http://ixda.org/ Resource Library ........... http://resources.ixda.org

21 Jul 2006 - 1:42pm
Dave Cronin
2005

> Wilson, Russell said:
>
> Communicate, facilitate, elaborate, collaborate... (can you
> feel the time slipping by?)

Yup. You have to plan for it. And I agree, schedule often limits the
amount of time available for collaboration. We often timebox the amount
of time we spend on this (though are typically quite generous: about 1
day/week).

But getting quickly to a solution that isn't viable (for political,
technical or usability reasons) doesn't serve anyone. Plus I'm more
worried about making clients, customers and users happy than winning
awards. It usually takes a team's worth of knowledge and insight to
achieve that.

When you're working in a complex domain (e.g. medical or financial), it
is very difficult for a designer to know all the details about the usage
context, and collaboration is a good way to get help filling in the
specifics.

> But, I do believe that ultimately one person needs to have
> authority over design for conceptual integrity, along with
> the standard checks and balances (so that your new enterprise
> portal is not based on the infamous hotdog stand color scheme)

Not to get overly philosophical, but the way I see it, there are 3 kinds
of authority in the world: by force (either physical or by threat of
action like firing); by fiat (programmers often have authority by fiat
because the have to build it); or by moral authority (people want to do
what you're suggesting because you've convinced them that it's right).

My experience is that this last one is ideal for making product design
and defintion decisions. Even Steve Jobs, who is a bit notorious for the
first type, also has the last type in spades.

My $.02,

-dave

22 Jul 2006 - 3:50pm
Cindy Alvarez
2004

On 7/21/06, Dave Cronin <dave at cooper.com> wrote:
>
> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> Not to get overly philosophical, but the way I see it, there are 3 kinds
> of authority in the world: by force (either physical or by threat of
> action like firing); by fiat (programmers often have authority by fiat
> because the have to build it); or by moral authority (people want to do
> what you're suggesting because you've convinced them that it's right).
>
> My experience is that this last one is ideal for making product design
> and defintion decisions.

Exactly! So the real question is, how does one earn moral authority?

- Be passionate about your project. It's hard to resist.

- Don't be defensive. Some input IS designed to undermine you rather than
towards making a good project, but you're always better off assuming the
best intentions from others.
"Why did you do THAT? I was expecting THIS."
"It meets project goals X and Y and has advantage Q - if there are other
concerns or product goals, let's sit down and discuss them offline"

- Be open with your reasons. I've worked with a lot of designers who keep
their decisions veiled in mystery, and it makes other stakeholders feel like
they can't provide input (or makes them wonder if this person really is
competent)

- Be willing to change your mind with good reason. (or, "strong opinions,
weakly held")
New information or changed project goals *should* be changing design - it's
not admitting weakness to say "I've revised these screens based on results
from our usability testing / Jen's new product goal / our new deadlines"

- Take some time before responding. When people blurt out ideas or
comments, I usually say "let me think about that" - then write it down -
then get back to them later.
"Hey, remember your comment earlier about the registration process? I think
this is why it will/won't work better..." This takes a lot of time, but
you know what? After a while, people start making BETTER SUGGESTIONS.

Obviously, proven success with past designs doesn't hurt. But it also
doesn't seem to earn moral authority in the same way that "wow, this person
really wants to produce the best solution and is willing to adapt and listen
to others and work hard to make it so" does.

Cindy

25 Jul 2006 - 7:47pm
pabini
2004

Interesting discussion you've initiated, Russ.

I heartily concur with what Dave Malouf has said. My recent keynote address
at
Interaction Frontiers was on just this topic:

"Getting From Concept to Realization: The Role of UX in Product Development"

http://www.idearium.org/frontiers/archives/2006/06/le_presentazion.html

Design by Committee usually starts with Product Management. How many times
do we receive Marketing Requirements Documents that comprise screen images
rather than descriptions of actual requirements for a product? When a
Product Manager does this, I let him know that he hasn't effectively
communicated the requirements. I ask: Why do we need to offer specific
capabilities? What's the data on which these requirements are based? As Don
Norman has stated in his latest Interactions article, user research has more
bearing on product definition and conceptual modeling than design. I let the
PM know that the UX will probably be very different from what he's depicted,
so if he wants to ensure the product designed meets his requirements on the
first go, he needs to communicate them clearly. PMs hate delays in product
schedules.

I prefer to work collaboratively with the leads in both Product Management
and Development from the very beginning of a project. During product
definition, we all contribute ideas, but the PM owns the decisions. This
sets a good precedent for people in specific roles having clear
responsibilities before we even get to design. I own usability requirements
and design. Development informs me about engineering constraints and
contributes ideas. Development owns the architecture and implementation. But
again, I often contribute ideas for software architecture, and they often
get implemented, but it's the developer's decision whether they do. Each is
responsible for fulfilling the vision and documented requirements and/or UX
design set down by people in the roles upstream from them.

The remarks people have made about having a clear design vision are so true.
On the other hand, it's important to listen to good ideas and understand
design problems posed by all members of a broader team. In the end though,
it's the designer's role to set the design vision and design the UX. Nobody
gets everything right all of the time, so if you're wrong about something,
admit it immediately. Then your team members will know you're sure of your
position when you fight for something. Developers are very good at
identifying problems. We need to address those problems in the solutions we
provide. Often a remark from a developer will lead me to a realization
that's way beyond the scope of the original remark.

You can often turn a pesky developer who challenges every design decision
into your greatest ally by being willing to dialogue with him and listening
to his ideas and using them when appropriate and by having sound reasons for
your design decisions--not necessarily based on specific data. Many years of
experience can often substitute for data gathered for a specific project.
Winning over the toughest developer on a team often wins over the entire
development team.

Pabini Gabriel-Petit

Principal UX Architect
Spirit Softworks LLC
www.spiritsoftworks.com

Publisher and Editor
UXmatters
www.uxmatters.com

Syndicate content Get the feed