We all know that design by committee leads to horrendous design and yet committees happen anyway. In this post I ask why, layout the argument against them and look at ways to overcome the problem.
“Wow that looks great, let me just show it to a few colleagues before I sign it off.”
At first glance the above statement looks positive. However if you have worked on websites for any length of time you know it is the kiss of death.
Even if there is no formal committee, any web designer and most website owners will tell you that once a design is ‘shown around’ only bad things can happen.
The problem is two fold.
First, design is subjective, what one person thinks is amazing another hates. Unfortunately website owners often feel they need to please everybody.
However, once design becomes a group decision you inevitably end up with a bland design that nobody hates but nobody likes either. It is not so much design by committee as design by compromise.
Second, stakeholders rarely have all the facts to make an informed design decision. They don’t know the projects history or understand the target audience, business objectives and success criteria. Even if they do have these insights they rarely have an understanding of why the designer took the approach she did. Nine times out of ten the person is simply shown the design and asked “what do you think?”
With design by committee so flawed and the results so substandard why does it still happen?
Why design by committee exists
Although to those of us who have experienced design by committee the drawbacks seem obviously, to a first timer it can appear necessary and even appealing.
Some of the common reasons for design by committee include…
- The website owner is not the decision maker – Instead he is a project manager who has to get approval from higher in the organisation. This is a particular problem on larger websites.
- The website owner feels out of his depth – Many website owners have never run a website or made decisions about design. They therefore feel the need to get the advice and opinions of others to reassure themselves about their decision.
- Because design is subjective – The very reason designers argue against design by committee is also a reason for it. If design is subjective how can the website owner be expected to make a design decision alone? Surely they need to consult others to get a wider opinion than their own personal tastes?
- It shares the responsibility – In many organisations there is a culture of blame and ‘arse covering’. This inevitably leads to website owners being reluctant to make decisions alone. They know that if they consult widely then it is harder for them to be blamed when things go wrong.
- It is politically necessary – Many website owners know that committees are bad for the design process. However, they are left with little choice if they want a design to be approved. Without consulting internal stakeholders the design is likely to get blocked on principle, whether or not it is a good design.
When you look at design by committee from a certain point of view you can understand why some take this approach. However, there are things that can be done to overcome these arguments, while at the same time combatting the problems design by committee creates.
How to overcome design by committee
Once you understand the reasons behind design by committee there is actually a number of alternative approaches.
Separate the problems
Design feedback normally falls into two categories – aesthetic and structural. If a design is going to be rejected it is because somebody doesn’t ‘like the feel’ or there is an argument over who gets what featured in the navigation or on the homepage.
The danger is that an entire design will be rejected on the basis of a content dispute or because somebody doesn’t like the blue. This is throwing the baby out with the bathwater.
The mood board focuses on aesthetics while the wireframe looks only at the structure and information to be included.
This has two advantages. First, it allows the stakeholders to separate in their minds decisions about aesthetics and content. This prevents entire designs being rejected because of minor issues.
Second, producing mood boards and wireframes is considerably quicker than final designs. This means that even if an element of the design is rejected it does not require major rework.
Divide and conquer
Another tactic for overcoming design by committee is speaking to stakeholders individually rather than in a group. Although this is best done in person, it can also be done over the phone if necessary.
Although individual discussions takes more effort the benefits are enormous….
- It prevents design on the fly – When a group of people discuss design they try to reach a consensus. This means that they make design changes in the room and you loose control. By speaking to people individually you prevent this problem.
- It neutralises the ‘alpha male’ characters – In group meetings you will always find somebody who dominates the conversation (not always a man!) They overwhelm quieter members and bounce people into agreeing with their standpoint. By consulting with people individually you avoid them having too great an influence.
- It puts you in control – By speaking to stakeholders individually you are the only person who knows what has been said. This puts you in a powerful position that allows you to pick and choose the feedback you use.
Of course any feedback is bad feedback if the stakeholder doesn’t understand the context of the project.
Ensure opinions are informed
Some stakeholders argue that they do not need background information on a design in order to judge it. They say that users don’t have that background, so why should they? The answer is simple, they are not users.
A stakeholder needs to judge the design from a business perspective as much as that of a user. They need to understand the business objectives, they need to know about corporate guidelines and what the competition is doing. In short they need to understand the context in which the design was created.
However, in many cases the stakeholder is simply given the design and asked “what do you think?”
The obvious solution is to provide the background to each stakeholder before asking for feedback. However if we are avoiding group meetings then presenting to each stakeholder is time consuming and repetitive.
Also even if you do present to each stakeholder there is nothing to stop that person passing the design to others for their feedback without your knowledge or presentation.
One way to avoid this problem is by providing the design as part of a presentation either in powerpoint, PDF or an application like Get Signoff.
Unfortunately people will not always read the copy associated with a design. Therefore an even better approach is to record a video of the design with an audio track explaining your approach. This is hard to ignore and ensures the design will never be seen out of context.
The problem does not just lie in controlling the presentation, it is also important to control the feedback.
Control the feedback
If you ask stakeholders “what do you think?” you are encouraging a personal response. This is actually not the feedback you are seeking.
Ljupco Smokovski, Shutterstock
Instead ask questions that focus the stakeholder on the real issues…
- Does it meet the agreed business objectives?
- Do you feel the target audience will respond favourably to the design?
It is also worth focusing the client on factors that informed the design…
- Is the design inline with your corporate branding?
- Is the design what you expected based on the approved mood board?
- Does the design reflect the agreed visual hierarchy agreed in the wireframes?
Notice that the above questions all require a simple yes or no answer. This prevents the feedback straying into personal opinion. However, it is also a little restrictive so we always ask “if not, why not?” after each question.
Asking “why not” achieves two things. First it forces the stakeholder to better articulate the problem and ensure there is a valid, well reasoned argument behind their statement. Second, it opens a discussion that a simple yes/no answer prevents.
Unfortunately no matter how well presented a design, there will be times when people cannot agree. In such situations testing can break the deadlock.
Turn to testing
Ultimately any amount of stakeholder feedback has a limited use. The stakeholder is not the user and it is the user that the design must appeal to. That is why whenever possible a design should be tested with real users too.
Design testing can be an effective way of breaking deadlocks between stakeholders. By asking users to comment on design you effectively render the personal opinions of stakeholders redundant. Best of all design testing can be done cheaply and easily using services like Ethnio and What Users Do.
Finally it is worth reminding stakeholders that no design decision is set in stone. Often the best way to evaluate design is by putting it live and seeing what happens. Things can always be changed later.
For larger sites (where the stakes are higher) A/B testing should be making many of the design decisions anyway. Ultimately testing is always going to be more effective than the opinions of stakeholders.
It is important to note that at no stage in this post have I tried to exclude stakeholders from the design process. I believe that design is a collaborative process and not something that springs spontaneously from the creative mind of a designer.
What I have tried to communicate is that although the contribution of stakeholders are valuable they have to be informed and shaped into something that is actually of use to the designer. Comments like “I don’t like the green” doesn’t help anyone.