Re: buy-in, consensus, etc.
On Jan 27, 2005, at 4:09 AM, David Heller wrote:
> Or at least I have found that the more they understand the decision
> process the easier time they have in getting the implementation of a
I would agree with this generally speaking. (And it's good to hear
Robert change his use from "consensus" to "buy-in".) It's just I find a
well made prototype to do the job of creating "buy-in" far more
effectively than any combination of research deliverables that at best
simply communicate the base research and not really "the decision
making process" whatsoever.
How does a persona communicate a design decision or the process behind
it? It doesn't in my experience. At best, it's just background
information. So much occurs, or should occur, after the research that
affects the design decision making process that the original materials
simply cannot cover it.
Also, I would clarify something here: I don't actually need anyone to
understand the "decision making process" except those that feel like
they have a vested interest in it. Direct members of the design team,
certain engineers and if I'm lucky maybe only one product manager can
fall into that category. Outside of that, the end result is really what
matters. A fully-formed prototype is the best tool for that exercise as
long as the prototype is fully formed.
A persona in my experience can be written as a very short,
non-formatted text document with the bare essentials of data. No need
for a photo, no need for "personal background" history or a short
made-up biography and very little of the pure marketing demographics.
Should take no longer than half an hour or so to write and should be
done once with very little iteration.
> 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
> in big groups, which are often x-functional and YES! They have put out
> successful products.
The most successful, well-designed products are, in my experience,
driven by strong design leads. They are not built as a committee or
unwieldy size teams. And when built by teams, they are built with a
strong sense of design leadership from one person. What tends to happen
when you get something like five very smart, talented people trying to
equally contribute to a design with none of them effectively in charge
or a manager who treats their decisions equally, you invariably weaken
those five overall. This results in a weakened product design.
Part of the role of the design lead is to get the needed buy-in from
others in the company. There should be no reason anyone on the team is
asked to do work to help get that if at all possible. Everyone on the
design team should be focused on executing and solving problems. If a
design lead is not doing getting the required buy-in, then they might
need to be replaced.
SIDENOTE: Which "big companies" have put out successful products using
large design teams? And don't forget, I said "well-made, successful..."
And what is large? More than 5 people?
> Design in isolation to me is not feasible to me when the level of
> reaches a certain zenith.
What I do is not design in isolation. When I'm charged with leading a
team, I do my best to let everyone contribute given their skills and
expertise, but at certain stages when a decision has to be made, I will
make it whether everyone on my team agrees or not. That's just the way
it goes. At the same time, I run cover for everyone on the team to make
sure they aren't distracted by unnecessary time sinks like trying to
get buy-in from other people in the company. I use prototypes to get
that buy in, as other material is not nearly as effective.
> 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
> way AND you don't include them in the research periods either. I have
> that some of my best ideas weren't even my, but rather occurred
> through the
> creation of a space where x-functional design occurred.
Not necessarily the case. When I do my work, I always leave all my work
open for anyone to review, follow, participate and engage in. I just
don't force anyone to try and keep up with me or the design team. The
folks on the team that have the most energy tend to collaborate with me
as certain problems they tend to favor come up. Further, working
through those problems is again best done with a prototype, not
> 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... Can you clarify
> more how others in your
> process get to help you form (not just critique and validate) design?
I promote a strong design lead. Someone who understands enough about
the problem and who's neck is on the line if the product fails. I
believe research can be done in a thousand different ways and designers
should spend as much time as they can get away with doing various
research activities before even attempting to design the product.
During the design, I believe in building prototypes or accurate
representations of the product and iterating over and over and over
until you run out of time. (While also hitting the major milestones you
agreed to prior to the project's start.)
The hard thing for me is working through the various ways in a which a
prototype can be done. A "fully formed" prototype in my opinion can be
a robust Flash demo or a large set of static screenshots, as long as
everything is fairly realistic and accurate to what the real product
will look like. You should attempt to go the Flash route, or a route
that lets you play with the product in some form if at all possible
though. Getting money and resources to build a realistic prototype is
the hard sell inside companies generally. Now that I have my own design
company, I'm simply spending the money to do it as I know what value it
adds to the process. What I can tell you is that a prototype can't be
simple wireframes or flow diagrams or the like.
> 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? Why does a designer need a "design communicator?"
That sounds entirely counter-intuitive considering one of the most
critical skills a designer must have is their ability to communicate.
> Last point, I too believe that prototyping is really the core DESIGN
> but I see a strong place for research data modeling to exist in the
> Task/workflow modeling
> User Environmental Maps
> Card Sorts & Thesauri
> Task Analysis maps
> Problem statement discovery
> Analog models
These things only exist, in my opinion, to the degree it helps
designers think through certain problems, not as a means to help
non-designers understand the process of design. If these deliverables
exist as a process checkpoint for the sake of keeping everyone else in
the company happy that the designers "are doing their jobs," it will
suck the creativity right out of your designers to solve problems in
unique, innovative ways as they spend more time on these deliverables
and not enough time building things.
> All these are models that help a design team communicate among each
> and with a larger x-functional team.
Not in my experience. Some can help if kept under control and not
allowed to escalate into deliverables for process sake. In the end, the
thing that holds together a design team and the larger x-functional
team is a strong design lead. A real person with skills, vision and who
can manage the nuances that is required to get the most from the team
as well as keep them working together to execute that vision.
Teams without strong leads tend to flail around and no amount of
visualization models or research deliverables or whatever will save
them from drowning eventually. These sorts of deliverables tend to feel
like some way of controlling the design process to achieve predictable
results. In that end, they can succeed, but they also can rob teams of
the freedom to solve design problems in ways that best fit the product
> 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?
This is a topic that would require me to write a book. The short answer
is: My experience at Adobe is colored by my lack of experience at
managing people due to being younger at the time I started the team
there. I was more focused on trying to solve a large product design
problem while also trying to understand how to build a design team. The
latter suffered as I was more driven as a designer by the former.
Outside of that, it would not be appropriate for me to speak openly
about the process inside Adobe for a variety of reasons. That would
have to come from someone else.
- buy-in, consensus, etc. (was RE: Powerpoint vs. "regular" slides)
- IxD deliverable and One-person show Was: buy-in, consensus, etc.
- buy-in, consensus,etc. (was RE: Powerpoint vs. "regular" slides)
- EVENT in Austin, TX: Stop, Collaborate, and Listen: A Panel about Getting Buy-In
- EVENT in Austin, TX: Stop, Collaborate & Listen: A Panel about Getting Buy-In