Skip to content

Design by Committee – Making it Work

September 7, 2010

It’s an oft repeated assertion that you can’t do good creative projects by Committee – that the needs of appeasing a large group of people leads to over-complexity and lack of a coherent vision:

Design by committee is a coined phrase to describe a collaborative approach to designing and, as I experience way to much, is bound to produce suboptimal results. Best described by the maxim “A camel looks like a horse that was planned by a committee”, I firmly believe this approach is severly handicapped.

I have to say that I think the whole idea that a ‘camel is a horse planned by committee’ is a bit simplistic – a camel is an animal adapted by nature to live in desert conditions.  It has loads of cool adaptations such as nostrils you can close that horses don’t.  Let’s not hate on the camels?

That is not to say there is no truth here:  I’ve been on a fair few projects were mass opinions were forced into the project and ruined the end result.  A better analogy than the camel thing is; when you mix too many colours, you always end up with grey.  That is to say, when you adopt too many people’s opinions, you always end up with a messy compromise.  This can be a good thing in politics as it means you can get consensus on something and move on to action.  It’s often a bad thing in creative processes as you chop out the interesting bits during the consensus portion of the process.

That aside another author took a shot at the idea – and used Open Source software as an example of something designed by committee;

It comes down to the deep paradox at the heart of design (whether for interface, architecture, product, etc.). We are trying to create a subjective experience that scales—a single personal scenario that can be multiplied repeatedly to fit a wide array of changing needs by a vast majority of users. The thing is, subjectivity cannot be scaled—that’s what makes it subjective—therefore, the attempts to create a one-size-fits-all solution are bound to fail, along with the attempts to customize the solution to each individual user in each individual use case.

Which is a fair point and something that I think all designers feel.  But then I think that the Open Source is no different from other projects as on the front-line of the wor at any one time I suspect there is only one or two people doing design…. and even then I bet they are doing other things too. (There is also a good rebuttal of this article here.)

But I also need to point out that even in closed-source processes, design is still a part committee activity.  In games for example you will need to negotiate with the people who will implement that vision (code, art, audio departments) and they will do a much better job if they feel you are listening to their concerns and ideas that just ploughing ahead regardless.  Then there is the publisher – via your producer – who can be delivering opinion from a personal view to the massed feedback of a huge cross-territory planning meeting.  So how do you make this work?  A few ideas might be…

  1. Before anything else, be certain that you know who is the final arbitrator in the decision making process. .. and be certain all in the process know.  Find out where your own authority extends too.
  2. During any committee process, make sure you take the time to separate out ‘opinion’ from ‘demands’ – not every bit of feedback has a requirement to be implemented!
  3. Use committees as a means of gathering ideas, be honest in making sure they know that, while you will consider suggestions, they may not get added.
  4. Measure each proposed change against the vision of the project as a whole – does it add too or distract from that vision.  Those that don’t add, bin.
  5. Then take those that do add to the vision and consider against the development resources you have.  Rank into easy, medium and hard to implement.
  6. Then take the same list and rank according to your own feelings as to if they are a good/important ideas to add – good, medium and poor ideas.
  7. Now you can start working on adding the proposed changes from the committee starting at the cross over between easy to implement and good for the project ideas and work from there…

In essence any group can be a resource of diverse opinions that help improve a project by giving creative friction to the design – or it can be a swamp that kills creativity. Being part of the committee and using good communication skills is the best route to the former and away from the latter.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: