[IxDA Discuss] design by committee??

[Pabini Gabriel-Petit]

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