The stories of Doggie and Pussycat are very well-known in Czech Republic and children usually love them. But there is one particulary great story – How Doggie and Pussycat made a cake.
In this story, Josef Capek nicely describes the pitfalls of the design by committee.
It’s Doggies birthday so Doggie and Pussycat decide to make a cake.
They want to make the cake as tasty as possible, so they decide to throw in all things they love.
Milk, butter, nuts, egg, sugar, salt, onion, cabbage, fat, vinegar, goose’s head, cinnamon, few sausages and some other tasty ingredients.
Obviously, the result is not-that-great and even the bypassing naughty dog that stole the cake in the end of the story ends up with terrible stomach ache.
Unfortunately, not every client understands the simple truth that many different things (however great they may seem to be) thrown together may end up as a disaster.
“Design by committee is a term referring to a style of design and its resultant output when a group of entities comes together to produce something”- Wikipedia
Sooner or later, every designer will end up in situation, when he will have to take a feedback from the committee, be it customer’s stakeholders or in-house team of directors. Sometimes, the committee members are trying to bring their best ideas to the table, others just wanting to leave some fingerprint on the product development just for the sake of it.
Deal with it as designer
Ultimately, as designers, we need to deal with a design by committee as we would deal with any other design problem: we have to listen carefully, and read between the lines. If necessary, we have to bring an order to the decision-making process and possibly work as mediator.
We have to realise that anyhow awkward some design requests from the committee members may seem to be, there is (almost) always a good intention and some underlying logic behind. The requests are (usually) not random, but are based on what the stakeholders think will be best for their business. They simply want to save the design and believe their opinion is somehow more important than anybody else’s.
Your goal is to listen and ask questions to identify real goals and stakeholders’ intentions. You need to find out why are the committee members suggesting particular design decisions.
Literally, you need to find out why the stakeholders think making that button small and yellow instead of big and red will improve the product.
When you gather all answers, you can start evaluating proposed solutions and provide committee members with relevant solutions, rooted in research and experience. Use storytelling, examples of successful patterns and state returns of investments these decisions brought.
Because the committee is often not united in their opinions, you may want to offer one of the best solutions you can – prototype and test.
You may want to perform user testing sessions with stakeholders watching the tests in another room, perform some A/B testing, you may try installing heat-map recording software or even perform some eye-tracking for your interface.
“You don’t do good software design by committee. You do it best by having a dictator. From the user’s point of view, you must have a coherent design philosophy…”
- Donald Norman
Be honest and respectful
It may happen that despite all your experience and evidence you presented to the committee, they still suggest a design decision that you believe is totally wrong. In that moment, you basically have 2 options:
Do what they ask for
In the end of the day, users are those who will decide if the product will or won’t be successful. Without proper research and testing, you may just guesstimate how well the design will perform. If the committee is absolutely adamant, then just do what they ask for, but don’t forget to measure success of the product. It may end up as interesting experiment – or even huge success.
Follow your ethics
Surly you have some designer ethical standards – you may not want to harm your client’s business, harm users or simply design something that will be totally against your belief. It may be the right time to say “No.”
The Perils of “Designed by Committee” as a Pejorative
Death To Design By Committee
How to Navigate Design by Committee
Design By Committee: A Designers Worst Nightmare!
Why Design-By-Committee Should Die