Consensus vs. Collaboration

Let’s say you are working on an application.  There are hundreds of decisions every week, sometimes every day.  Decisions can be big and small.  How quickly should something animate?  What color should the button be?  Is it better 2px to the left or to the right?  Decisions like these accumulate into the design of your application.

So the question is:  How best to make these decisions?

It is certainly possible that a single person could be in charge of the design and make all the decisions him/herself without even talking to other people.  This is called the “Dictator” model.  One person controls all.  The benefits of this model is that decisions are made quickly and usually consistently.  There is a vision (sometimes good, sometimes bad), but it is not muddied.  On the other hand, this model often leaves other contributors feeling left out of the decision making process.  Usually the HiPPO (Highest Paid Person’s Opinion) has the authority to do this.  There is no consensus or collaboration in this model.

Another model, called the “Committee” has everyone vote on every decision.  This is a consensus driven model.  The committee is usually 3 or more people with equal votes.  Usually a few people are ‘louder’ than the rest or play office politics so that their voice carries more weight.  The benefits of this model is that risk is distributed.  In other words, if something is designed wrong, then everyone is to blame, which means no one is to blame.  Spreading decision making responsibility allows each person to avoid putting their head on the chopping block.  The downside of this approach is that usually the design is horrible and makes users feel like putting their own heads on the chopping block to avoid the pain of using such a mangled, inconstent, uninspired piece of crap.

The last model is “Collaboration“.  Generally, you have one person who was delegated authority from the HiPPO to be in charge of the design.  However, since this person is not actually the HiPPO, he/she can not use the Dictator model effectively.  However, the designer’s head is on the chopping block for the design, so the ultimate decision lies in their hands.  The best route is to collaborate with the team.  This means the designer has to work with the team and talk about the choices and even brainstorm ideas.  With that idea-exchange the designer has to make the final call.  This allows the designer to maintain consistency, have a vision and make decisions quickly compared to a consensus driven committee.  However, it also allows each person to get their fingerprints on the project.  It allows good ideas to be heard.  A good designer knows how to strike the right balance between the doctator and the committee.  A bad designer will lose that balance.

What kind of model do you use in your organization?  I find the first two models are the most common.  However, the last model produces the best results.  I find it fascinating how human psychology leads us to make sub-optimal decisions.  Darwin would not be happy.

6 Replies to “Consensus vs. Collaboration”

  1. We have none of those, everyone is kinda on their own, which is quite problematic. There is no sense of vision, since everyone is focused only on their daily tasks. There is no design at all, so the results are minimal and depend only on individual talent. I am trying to change some of this, but the HiPPO is not the dictator type (she is in terms of service, but not organizationally). Although it is not directly my responsibility, I feel that in order for my position to be successful (in the long-run), there needs to be a movement towards one of the three styles. An example of why this isn’t currently working is that in most well-run non-profits the staff donate to the organization. This makes big donors feel better about their investment, it just works. But since most the staff here are not familiar with this idea and individually they don’t feel it is even appropriate for me to ask them for money. However, a dictator could kinda make people do it, and a committee or collaboration would come together and release that this is worth while (and will contribute to the mission). I know we aren’t designing anything, but I through your post had a corollary towards general management systems.

  2. My company strives for the collaboration model, but I have seen one instance where this has broken down: when a Product Manager thinks they are a UI Designer and when the UI Designer thinks they’re a Product Manager. In an ideal world both responsibilities are siloed, but realistically there is occasionally some bleed-over when both parties are passionate about their application.

    When a smashing of heads between Product and Design occurs, there’s often a brief heated discussion and the unfortunate result is a Compromise, which, as you know (I’ve seen your UX presentation), can be a bad thing.

    But generally, Collaboration works great as long as the insight offered by other stakeholders (buzzword alert) stays within the boundaries of their individual expertise.

  3. James: You hit the nail on the head where theory and practice make for an unpleasant outcome. I have had the opportunity of being a UX designer AND a product manager at the same time. I truly believe that product management should be the “junior” partner in the relationship.

    What the product does is always secondary to how it actually works.

    In other words, when an argument happens between design and product management, the designer should win. It will yield a much better outcome in the end. With that said, it is CRITICAL that the product management function be clear about what success looks like. Is it higher satisfaction? A specific use case? A specific increase in sales?

    The place where it gets into trouble is when executives or any non-designer wants to insert their opinion into the design process. This is what makes products fail. I should blog about this detail more specifically, but it comes in so many flavors.

    You said you saw the UX presentation. What was your opinion? I hope I was good, but you never really know. 🙂

  4. Belated reply, but…

    Your UX presentation was top-notch and my favorite at the conference. As someone who is currently transitioning from a lead UI dev role to a lead UI design role, I found your presentation to be relevant and incredibly engaging.

    Do you only speak at conferences? I would love to arm-twist my company (SF-based) into hiring you for an hour and motivating our developers:)

  5. Thank you very much, I really appreciate it. I actually don’t speak at many conferences, although I always love to do it. I wish I was invited to more. 🙂 I was invited to speak at the ExtJS conference in April, but right now, that’s it.

    I absolutely would love to help out. I’ll email you directly.

Leave a Reply