Avoiding Design By Committee
‘A camel is a horse, designed by committee.’
Alex Issigonis, designer of the Mini
No matter how hard we try to avoid it, we have on occasion ended up working with teams who together are lesser than the sum of their parts. Some of the least helpful feedback we’ve ever received has been from some of the sharpest business minds we’ve worked with – but because of the way it’s been collected, they’ve been pressurised into supplying feedback which, for one reason or another, ends up having a negative impact on the end product – and leading to rounds of costly revisions.
Why does this happen?
Well: there’s usually a few common factors to projects that go south like this. It usually comes down to a combination of one or more of the following factors:
- Too many cooks. We always nominate a Project Manager for any client we work with. The more levels of management or feedback contributors a project has, the more likely it’s going to degrade.
- Personal preferences. ‘I don’t like that blue colour’ isn’t good feedback. ‘I like this other site’ isn’t good feedback. Unless it’s backed up with hard evidence of a benefit to the design, it’s not of value.
- Feedback under pressure. Nothing destroys a good product like the dreaded Feedback Meeting Loop – where contributors are pressurised into providing any feedback. Chances are, if it’s not thought through, it’s unlikely to improve the end product significantly – and may well do damage.
This isn’t to say that collaboration is the enemy of good design. Far from it: if you’re dealing with a project and you’ve got experts to hand – be that in marketing , sales (especially sales) or just an insight into client demographics – it’s by and large a good idea to use them. And there’s been occasions where we’ve missed the mark with design, and have worked with clients to get it right, ending up with a far superior product at the end. But there’s a few techniques to getting the best out of customer feedback.
Here, then, are a few top tips for you – our poor, overworked Project Managers – to help get your project past the committee without changing the font to neon pink Comic Sans.
1. Figure out the ‘why’
‘Make the logo bigger‘ is one of those phrases we (along with every other design agency) hear so often that it’s become a meme in its own right. (It’s actually immortalised in poster form in our meeting room.) And it’s something that clients often latch on to – why’s our logo, that we paid so much money for all those years ago, so small in this layout design? And can we make it bigger?
Our answer to this is always the same. ‘Why?’ Because, unless your websites first objective is to show off your logo, you’d probably be better focusing on what you’re trying to do with the site – be it sell products, drive bookings or just make contact. That’s why our logo (top left) is titchy, and our ‘Get In Touch’ link (top right) is bright pink. Guess which one we want you to interact with.
If you’re dealing with feedback that doesn’t sound like it adds value, the first thing to ask is: why. If there’s no tangible benefit in the answer, it’s much easier to disregard.
2. Give people just enough choice
Nothing quite makes a designers day like presenting two or three separate designs and getting the following back:
‘Can we take element A from design 1 and combine it with element B of design 2…and maybe drop them both into element C of design 3…?‘
To use a slightly nauseous analogy, mashing together the best bits of a cheeseburger, a prawn jalfrezi and a pear & blackberry crumble isn’t going to please everyone at the table. Yet this, in culinary terms, is almost without exception how a final design ends up after being critiqued and approved by the eyes of everybody on a committee and/or management team.
It’s worth explaining this to people, though. When presenting multiple designs, be sure to explain that these are self-contained concepts for individual feedback – not something that should be bolted together like some kind of design Frankenstein’s Monster. And it’s often worth narrowing options down before presenting them – so if you’re working with a concept sketchpad, remove all of the ones that definitely aren’t appropriate to make it easier for users to choose.
3. Don’t force feedback
The most damaging feedback comes when a team member with no strong preference or understanding of a project is forced into delivering feedback. This can be a situation where a team member is pressurised in front of their peers into ‘making a contribution’ to prove their involvement in the project, or (sometimes worse) when upper management feels that they should contribute in order to put their stamp on the product (‘See that big orange stamp in the header? That was my idea!’)
When presenting a concept for feedback, explain the project first. Talk your team members through the aims and objectives of the project, and explain, where possible, how each element of a design helps achieve this objective. And then turn it over for discussion, moderating what comes back in to ensure that, while feedback and contributions are taken on board, you avoid feedback for feedbacks sake.
4. Be a dictator
If you’re happy to lead a project in terms of design, and you’re confident that you understand the brief, it’s sometimes better to aim to lead a project through with as little resistance as possible. The oft-used example here is the iPhone – the dream of a very small design team, they largely ignored customer feedback throughout (a smartphone without a keyboard? That’ll never work!) to deliver a far improved product.
Obviously, it’s not always possible – or appropriate – to railroad through colleagues/committee members/management, ignoring all and sundry – but it’s often worth presenting design updates without actively demanding feedback from each and every team member (see point 3 above). Encourage people to see where the project is, and pull in expertise as required, but a strong project leader can deliver a product through that rocky design stage a lot quicker and at lower cost than a committee.