Design by Committee can be bad, but so is the reverse.
So we’ve all been there, you’re making something for a client and you’re in the final stages of working out exactly what the end product will look like when someone managing it starts with:
“Hey, I showed this to my ________ and they said it should have ________.”
Suddenly everyone in the room chimes in with ideas of what the end product should be. Just go google “design by committee” to see a boundless world of hilarious memes showing what happens when group design gets out of hand. When the team is small, say less than five people, you can easily handle the requests. I often like to do a quick mockup of what a client says they want to give it contrast to other options I’ve come up with. But here is the thing, I’ll come up with terrible ideas too.
To design something well you need the input of others. It can be as simple as asking someone to take a look at what you’ve been staring at for three days just to see if it’s legible. This becomes apparent when writing because so much focus and attention
This is the part where your UX research will tell you that people need more than one button on a mouse in order to use a computer effectively. However, as a lone designer, you might not get all the information. You can ask the clients what they want and they’ll give you a list of parameters that they need and the rest is up to you. Some things are easy enough, you know how big to make something that is considered “handheld” or “easy to use”. You know what colors
Let’s take the Design By Committee scenario and reverse it. It’s just you, the list of requirements, and all the things that you know better than everyone else. Perhaps you even lead a small team but their input is irrelevant to you because you know better! The Polly Pocket mouse is the way of the future and everyone will love it because you made it. All those other multi-button elongated mice are common trash compared to your glorious concept. That is until everyone tries to use it.
Let’s switch gears to writing. Say you want to write a book that will have agents fighting to represent you, that Netflix will call you up wanting to know where to send the money so it can be a miniseries before Amazon gets ahold of you. So like any reasonable person you give the current market a quick glance. Young Adult fantasy is on absolute fire so you think you have a shot at it. You read Harry Potter and watch nothing but magical high school anime so this is going to be a cakewalk. First, you start developing the dozen or so main characters, you give them diverse backgrounds and convincing points of conflict. Then you write the setting, an urban dystopia where people have magic powers. Every character is given a heart-wrenching romance arc that will grow fanfiction archives for generations. You even go to the point of making sure no major tropes or stereotypes have been conveyed in the slightest. It’s bulletproof.
You then send it to several agents looking for YA manuscripts and each one returns with something along the lines of “Where is the story?” or they tell you that there are too many characters, that the first chapter isn’t going anywhere, or that it’s just hard to follow. So where did you go wrong? You ticked all the boxes in your head for the perfect book, something you would personally read, but the story itself falls flat. Just because you personally like every conceptual component of
Yes, there will always be those one or two people who jump up and say “I really liked X tho.” You’ll probably see them in the comments below telling me how much they love their Polly Pocket mouse and still somehow use it to this day. That’s great, you do you. But you can’t always cater a design to one or two users unless the userbase is literally only one or two users. Piling up a list of things you like and cramming it into something could turn out just as bad as having a room full of people telling you things they like and trying to do the same.
Remember that episode of Friends where Rachel makes a trifle for Thanksgiving? Spoiler alert, she goes to make a dessert from a magazine and follows the recipe exactly. However, one of the pages from a different recipe has become stuck to the dessert recipe causing Rachel to create a trifle that includes a layer of meat and potatoes between fruit and cream.
It’s hilarious to watch because her friends try and eat it in support and are all super grossed out by it. Everyone but Joey, who claims to love it. Why does he love it? Because each component is something he likes. But as everyone at the table trying to eat it points out, they just don’t go together. You can’t design for Joey, you have to design for everyone at the dinner table. Not everyone in the world, just the people at the dinner table.
The other issue with the reverse of Design by Committee is that sometimes what you came up with isn’t great in the first place. Sometimes you pick the wrong font. Sometimes your prose starts turning purple. Sometimes you start sticking icons wherever they will fit. The worst offense is when you have it in your head that you must do something unique to a fault. I went into a bathroom the other day that had a flat sink. Well, it had a little 1-inch lip around the edge of it, but for the most part, it was a flat sink that water shot out towards the middle of. Guess what? You get splashed with water, the whole sink area gets splashed with water, it’s a mess. It was an automatic spray as well so you couldn’t turn it down either. So why was it in a fancy hotel lobby bathroom? Because it looked nice.
Concept cars are what jump to mind first when thinking of things that look nice but aren’t exactly user-friendly. That Mercedes up there looks gorgeous. Things light
Things that you personally think look good aren’t always good for daily use. Starting a website with a huge
Having someone step in for a second to take a look at what you’re working on can save you hours of frustration later when you’re told to redo everything. This why you use beta readers for your first couple of drafts of a story. It’s why you consult the rest of your team before showing work to the project lead. It’s why I show clients a series of basic concept logos before spending hours in illustrator making a final draft. It’s what unit tests are for in your code. Why wireframes arent’ full color mockups. Simple things like, “does a mouse need buttons?” or “do beef and peas go in dessert?” can be handled early, saving time and effort.