Avoiding designing by committee

Question

How can one avoid making a design that satisfies everyone, but pleases no one?

As a UI designer, you often find yourself a part of a development team, with numerous stakeholders. Now, when it comes to users' experience, everyone is sure they know something about it (since they are users themselves, and they experience something, right?). Having a couple of such big-headed people on the team's leadership, you start to get a variety of opinions, and when you try to balance all of them, you often get clumsy UI's. Because everyone must agree, the results are full of compromises and whimsical considerations. To illustrate, think of the joke that a camel is a horse designed by a committee.

Things get even worse, when agile and lean UX methods encourage us to get everyone on the team involved, which is a good thing in principle, but gets you even a larger portion of opinions.

How do you combine the great opinions and ideas of the team leaders and members, but keep your design useful and elegant? and more generally, how do you base your design authority, so when you make a design decision concerning users' experience, people come to acknowledge it?

Answer 1

After some years of fighting I got used to it. There are various ways to struggle with it, you can play as an authority often saying "no", or actually "NO!", but you will lose your followers, because there are always decisive people who will maintain that they know better. You can try to establish processes, but there are going to be people who will not follow them.

I love this game, actually, as you don't play a role of the one who decides about the big picture of the project, but instead a role of a consultant and co-creator. If they see you try to put together all the parts rather than being a stopper, you are considered an important part of the project in the eyes of the stakeholders.

So, what you should do is, in my eyes:

• prepare arguments that translate to achieving business goals
• remember, that you may be wrong - never underestimate stakeholders, try to understand them, their needs and goals that evolve and adapt over time
• adapt visions - when someone says that something should be done in a different way, find another solution with cooperation with this person
• discuss ideas and explain how they address the business needs
• always refer to the business/project owner - after all, usually this is the person who has the highest influence on the project. Even if there is input from other persons, you need to lead to confrontation with the business needs
• never agree to stupid ideas - if you don't find a reason behind something, and after a research (which means consulting the idea with business owner, strategist, or something people from technical side - designers, programmers), explain that it does not make sense. Which means that if you say "No." then you always need to explain why, and have a good reason for this.

I know this is kinda general, but it works.

Answer 2

It's a good but difficult question, without any universally good solution. However I will try to give you some things that you can do to help with this.

Firstly, recognise that the role of a UX designer is to say no a lot of the time. That doesn't mean that you say "no" whenever someone suggests something that you don't particularly like.

Secondly, you should listen to all input or feedback, and take the time to consider it. This consideration should be measured in hours or days, not in minutes. In considering it, try to think of the good and bad points in it, and then when you speak to the person, you should articulate some good points, and then explain why you are or aren't going to use it. It shows that you have taken the time to consider their input, which usually goes a long way to placating them if you don't use it.

Finally, you will often have to include poor UX as a result of someone with power telling you that you have to include something. At that point there is nothing more you can to than to explain that you believe that it will hurt the UX (for X and Y reasons), but that if they still insist, you will go ahead with it. If they insist, all you can do it to try and make the UX as good as you are able within the constraints that you have been given.

You need to keep in mind that UX is only one of the many considerations that go into a product or website, and although it is what is most important to you, other issues may be a higher priority to those with the power. If you are designing by committee, all the solutions that come out of it will be compromises, and so you need to be willing to accept that.

---

As an aside, most of the problems that you will have here are not specific to UX, but apply to most areas of expertise. The field of study that I have found most useful to this is Policy Analysis. It may seem somewhat disconnected from what you are asking, but if you delve deeper, you will find that it is essentially dealing with how best to design a system or make a decision when there are many actors (stakeholders), each with their own set of desires and powers.

Answer 3

Another idea I would add to everything said above is do user testing when you can. When there is a proof that something works/doesn't work people are more likely to agree. Some important people are also more agreeable when you talk to them in person and they don't need to show their power to a bigger group. So you can try convincing them individually and then bring them to a bigger meeting.

Answer 4

It'd make sense to drive by facts. If you can setup measurable conversion goals, and verify them either by user testing or metrics from your production - you won it. If its not easily measurable, I'd suggest collecting qualitative user feedbacks about alternatives.

Answer 5

Focus on goals, not visuals.

In other words, when presenting part of the UI, explain what that part of the UI does to accomplish the particular goals it was put there to handle.

By doing that, you end up explaining WHY things are designed they way they are. The won't stop all random 'stripes vs. polka dot' type questions, but should at least reduce them.

Answer 6

It is definitely useful to get input from a variety of different people, but the key here is to define the people that are asked for input, and the people that make decisions based on the input. This way, people know which part of the process they are involved in, and how the decisions are being made. Also, for the 'design committee', it is important to have some guidelines on how decisions are made so they are not as seen to be based on individual preferences. The way I like to think about this is as a funnel, where various inputs are progressively funneled and filtered down to actionable decisions for the team to act on.

Another thing to work out is when you solicit those inputs. I think at various design or development stages you want to engage specific groups for input. Generally it is more effective to work on the high level requirements, and once these constraints have been worked out you can spend as much or as little time on the colours, fonts and more subjective requirements without impacting on the delivery milestones.

Answer 7

Tests, tests, tests! A/B testing, User testing, calculating, finding targets, users eye tracking, mouse moves tracks, clicks, actions taken, focus-groups, think-aloud-protocols...

Everything else is just empty words and hundred of articles in the net and discussions leading to nowhere.