Avoiding the Camel

Julie Zhuo
Jun 6, 2017 · 5 min read

Photo by Phil Norton

How do you protect the product from being “designed by committee?”

The oft-cited maxim “a camel is a horse designed by committee” warns of the odd humps, poor temperament, and occasional spitting that can result from group-decision making.

Although this cautionary camel-tale is well known in the design community and beyond, the first and most important thing to recognize is that the solution to “too many opinions” is NOT to avoid the committee entirely. If you’re concerned that having 50 opinions will ruin your work, and you instead choose to hole yourself up in some shiny design tower ignoring everyone else until you emerge with your glorious end product, then you’ll almost certainly fall short of producing the best solution. What the camel-tale forgets is that All Of Us are better than One Of Us. If too many cooks spoil the broth, then why do the best kitchens in the world have many cooks working in lock-step as a well-organized team, serving course after course of delicious broth?

Feedback is a gift. When you actively welcome opinions, advice, and even criticism into your work, you open yourself up to learning something new and making better decisions.

The challenge is when opinions come in at the wrong time (when it is too late to be helpful), at the wrong level (discussing a tree while completely missing the forest), or with the wrong context (proposing an impossible change that lacks the background for why some decisions were made).

So, how might we set up the right environment where feedback and opinions can be given in a way that is helpful? The question asked about clients, co-workers, and management, so here are some ideas for approaching each.

When presenting to managers

  • . Show your work as you are creating it. Nothing is more randomizing than going far down one path only to have people tell you you’ve gone the wrong direction, as then you’ll be stuck with the two bad options of throwing away your work, or trying to sunk-cost-fallacy these new requirements into the old work. So as personally difficult as it may be to show work to managers that you know is rough, get into the habit of syncing up as soon as you can by asking “Hey, is this going the right direction?” or specifically calling out “These parts aren’t done, but I’m thinking something along the lines of X, Y, and Z would be a good solution. How does that sound?” Do this early, and keep doing it each time you’ve made progress to stay aligned.
  • . Start broad and refine as you work. In the beginning, showing various approaches and flows makes it easier to have a conversation about the pros and cons. If you just bring one idea to the table and ask for a “Yes or No” decision, then you’re opening yourself up to a greater likelihood of other people devising new ideas to try on the spot. By sharing multiple options, you can then ask questions like “Which way of presenting this information will be more intuitive, A or B?”
  • . This includes qualitative user/market research, or quantitive usage/behavior data. Not only does data win arguments, but data allows for more informed opinions.

When working with other coworkers:

  • . Are there requirements you may not be aware of, such needing to accommodate low-end android devices on 2g networks? Without hearing diverse perspectives, it’s easy to fall into the trap of only drawing from your own experience and not realizing that most people in the world aren’t like you and will need solutions that wouldn’t be what you’d build for yourself. This becomes particularly true when working with people from other disciplines with unique skill-sets. You can ask engineers about how challenging it would be to implement various designs to gain more of a sense of the unique constraints you should work with. You can learn a ton from data scientists discussing how you’re going to know/measure how well your solutions are working.

When working with clients:

  • . Don’t let your client design the product for you, that’s not why they hired you. One technique here is to bring your conversations back to the people problems you’re trying to solve to ensure you’re aligned on goals, rather than having your meetings be a time for spitballing new solutions. Elevating the conversation by responding to some new proposals with a “why?” question that brings it back to the purpose of the work will help keep the conversations at the right high-level where they belong.
  • . The easiest way to shut down a productive conversation is to ignore feedback and repeat what you’ve already said more vigorously. If the client starts proposing alternate solutions that run counter to yours, rather than just shutting them down and reminding them that “I’m the designer here,” acknowledge that “it sounds like something here isn’t working for you. What are some of the areas where this fell short?” to bring the conversation back to ways to improve the current designs, and to keep you working collaboratively and in your appropriate roles.
  • r. “Today we’re here to discuss the navigation” or “I’d like to confirm we’ve provided an understandable solution for uses cases X and Y”. If the conversation veers towards potential distractions (e.g. proposals for word choice, color schemes, or esoteric edge cases), you can take note of the feedback, but bring the conversation back to the meeting’s stated objectives.
  • Note that the above regarding managers — seeking feedback early/often as well as providing multiple options — are applicable to clients as well, and vice versa.

The Year of the Looking Glass

A collection of essays by Julie Zhuo on design, building products, and observing life.

Julie Zhuo

Written by

Product design VP @ Facebook. Author of The Making of a Manager https://amzn.to/2PRwCyW. Find me @joulee. I love people, words, and food.

The Year of the Looking Glass

A collection of essays by Julie Zhuo on design, building products, and observing life.