AGREED: Avoid Designing by Committee
August 26, 2006 by Glenn R. Cochran
Checking in on several favorite blog sites tonight I spent about an hour or so surfing the web in search of new material to read. While doing so I found a great site containing a key piece of advice which I whole-heartedly agree with. An article called "Rethinking Application Design" written by Dirk Knemeyer for Digital Web Magazine.
Dirk Knemeyer Is Right!
In this article Dirk discusses his ideas on application design and makes a few key recommendations. One near and dear to my heart is simply, "At all costs, avoid design by committee". Here is what Dirk had to say:
"Everyone has an opinion about design. That’s because people see design as form: something sharing more with style and layout than behavior and interaction. But design is about function as much as form, and suggestions to change one aesthetic thing or another can have a huge impact on the cohesion of the design and even undermine the conceptual model. Create an environment that is open to feedback and input, but ultimately let the experts make the decisions and control the design."
I thought to myself, this man is a genious. I've been saying exactly this for months now at my new job and here it is again, literally stating my feelings exactly, and I couldn't have said it better myself.
Emotion Runs High
A common problem, in my humble opinion, is that in the software industry people become emotionally attached to the things they help create. There is a tendency by engineers that write code at the user interface layer to lay claim to specific screen elements, on screen text, or a unique layout which they deem reasonable and hold on for dear life. Never mind what user research shows or the input from a senior designer type, making a change in code that would be like admitting failure somehow. Because of this emotional attachment some engineers want to rope in as many additional opinions as possible simply to validate their own ideas and appear correct. This behaviour is what I've been calling design by committee.
Baseball vs. Software Development
When discussing this exact issue with engineers I like to use the sport of baseball as my analogy. I believe that players on a baseball team are highly specialized, serve a specific purpose in the game, and are not readily interchangable. The pitcher is a highly specialized player with a specific set of skills. The same can be said of the first baseman or any other position a baseball player holds on the team.
The software development game is literally no different. You have user interface engineers, back-end engineers, product managers, qa engineers, interaction designers, technical writers, marketing folks, usability researchers, sales men and women, product consultants, and a variety of other specialists. Each group has a specific purpose and function which makes the larger team whole.
In Conclusion
It literally is that black and white to me. Each member of the team adds value to the greater whole and should be trusted to do their specific job. As designers we'd never tell engineers how to write code or optimize an algorithm. That would be like telling them they don't understand how to write code. It would be great if we could cut out all the design by committee and let designers do their job.
As this very intelligent man Dirk once said:
"Successful design—not surprisingly—is best led by someone with design skills."
I agree completely. Thanks Dirk!
