[IxDA Discuss] design by committee??

[Todd Warfel]

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.