buy-in, consensus, etc. (was RE: Powerpoint vs. "regular" slides)
27 Jan 2005 - 6:09am
> I'll be honest and say that I tend to dislike deliverables whose > purpose seem to be "driving consensus." I find very little innovation > or creativity in team exercises aimed at creating consensus > for design > decisions. I fully understand that due to corporate politics some > amount of consensus driving is required, but I see no need in fueling > that monster that tends to lead down the path of committee-based > design.
I found this part of Andreie's response interesting for its own thread ...
In my life, I have found that "buy-in" is what I'm trying to achieve, not
consensus. What is the difference? Consensus is about "agreement", "buy-in"
is about understanding. I don't need a developer to agree with me when I'm
trying to get them to implement my design, I need to get them to understand.
Or at least I have found that the more they understand the decision making
process the easier time they have in getting the implementation of a design
But is this design by committee? AND with all the talk of x-functional
design going on, so what if it is? I have heard Andrei and others talk
poorly about "design by committee", but many big design organizations design
in big groups, which are often x-functional and YES! They have put out
Design in isolation to me is not feasible to me when the level of complexity
reaches a certain zenith.
> I find that prototypes do all my work for me. When done > properly, they > communicate the design (for obvious reasons), put all the > issues out in > the open in front of engineers, execs and end users, and allow me to > iterate over and over to evolve a design solution.
I like prototypes, too ... But it sounds like you only ask these groups for
validation and you don't include them in the formation processes along the
way AND you don't include them in the research periods either. I have found
that some of my best ideas weren't even my, but rather occurred through the
creation of a space where x-functional design occurred.
Andrei, I don't want to assume, since this is just an e-mail list and I
could never know the entire process that you use. I mean, I'm sure Dirk does
something, but it sounds like you are describing the classic ego-driven
designer who feels that they along must be the sole dr. frankenstein of
their design. Even if this isn't what you actually do, it does sound like
this is what you are promoting. Can you clarify more how others in your
process get to help you form (not just critique and validate) design?
As a side note, one of my favoriate pieces of the cooper process is not
personas but the buddy system approach of having a designer and a design
communicator. There is so much to the cooper approach outside of personas. I
feel it is a shame that personas are the only things people can concentrate
on about them.
Last point, I too believe that prototyping is really the core DESIGN tool,
but I see a strong place for research data modeling to exist in the process:
User Environmental Maps
Card Sorts & Thesauri
Task Analysis maps
Problem statement discovery
All these are models that help a design team communicate among each other
and with a larger x-functional team.
That's another interesting point ... How do DESIGNERS communicate among each
other? I know Andrei you worked at Adobe, which has a host of designers. How
did communication between designers on the same project, on related but
separate projects communicate their research findings?