Death to design by committee

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.

Designer with a gun to his head

olly, Shutterstock

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.

A client feels out of depth giving design feedback

corepics, Shutterstock

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.

Avoid this by making sure the stakeholder doesn’t just see the final design. Instead present mood boards and wireframes.

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.

Design committee arguing over colour

corepics, Shutterstock

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.

Bill looking horrified at stakeholder feedback

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.

  • Great article and very well-presented thoughts and information. Everyone who’s designed more than zero websites has run into this – thanks for giving some information on how to handle the situation!

  • I’m confused
    Andy Rutledge’s advice is to avoid showing wireframes to a client
    but you recommend it.
    who to believe! :)

    • Primarily I work for a local authority council,

      We appointed Jadu as our CMS provider last year but have been working on the “design” since March(ish). Unfortunately, the site is being designed by a print designer whose only previous website was the monstrosity we have at the moment. That design is going through the the above process and it’s just horrendous.

      In the mix we have:
      – 3 developers (me + 1 who have actually built other websites and our line manager who is a PL/SQL coder)
      – 1 project manager
      – 2 graphic designer (1 is head of graphic design)
      – 2 web journalists (1 is council mouth piece)
      – 3 “content managers” and I use that very loosely as I’ve yet to see a piece of managed content

      then add in 2 levels of senior management (1 IT and the other corporate).

      Looking to launch in Oct, work is being rushed and the quality is poor.

      Unfortunately I’m told “that’s how councils work” but its never thought of to look at ways of improving the process. Wireframing, mood boarding etc were non existent.

      Avoid this at all costs if possible.

      Thank goodness freelance takes me away occasionally as I couldn’t work that way all the time.

    • @paul,
      To be clear, my article explained that it’s “not always” a good idea to show wireframes to clients. It also alluded to the fact that it sometimes is a good idea.

      I don’t want you to believe that Paul and I are necessarily at odds here, just that we’re each talking about different contexts. Context matters.


  • Loved the article! Design by committee is something I’ve experienced first hand, and it is horrible. I learned from it though, and I’m a better designer for it. It will never happen again (god willing).

    • Really good work, and I agree with @Mark. Very tough process and nobody seems satisfying.

  • I too have had the pleasure ( and the pain ) of designing interactive by and for committees. Unfortunately, committees gauging excellence should be left to the dominion of design competitions, Top Chef episodes, and Rupaul.

    In my experience, the best way to deal with design committees is, as you say, not to meet with them as groups (this just brings all of the social-emotional into the equation). I have also found that giving these groups very specific tasks related to the design work can be very helpful; tasks like surveying their current content and their future content needs, can actually work in your favor as this often exposes serious issues and raises questions internally that they might have simply waved their hands at and dismissed had the designer brought them up.

    Another great blog post.

  • Anonymous

    Excellent article with practical advice. My challenge has been getting stakeholders to hold off a bit until I can even *get* user feedback. It’s not as if you can hide the design you’re doing from the organization until after testing happens. We have (in theory) a process where all designs are validated quickly by users before implementation, but management often won’t allow me to complete the process. Anyone have any advice on managing such a situation?

  • Brilliant, I am now going to share this with the world!!

  • Anonymous

    Here is what we do to avoid design by committee:

    Find the key person who will approve the design, hold a meeting with this person and explain the main factor that makes the website succeed – the website visitors should like the website only then it will succeed .  Show some successful websites and ask to guess how many people visit this website per month, then show the actual stats.  Then take a commitment to allow us to design the website focusing on the needs of the website visitors.

  • I like your website…….

  • Jonathan Elder

    Great article – and possibly worth sharing with new clients.