Why Design by Committee Doesn’t Work for Me

Platypus

To me, the platypus looks like an animal that was designed by a committee. Here’s how I picture their design meeting went.

Project Leader: Hey everyone, we’re going to make a new animal. It’s going to be amazing! It’s going to be everything we love. So, let’s go around and here what everyone wants.

Joe: I love dogs. I think it should be like a small, furry dog.

Marsha: I love beavers. It should definitely have a flat tail like a beaver.

Jim: I love ducks. Can it have a duck bill and webbed feet?

Project Leader: It can have whatever you want, Jim.

Louise: I just had a baby and giving birth is kinda messy. Let’s make sure it lays eggs.

Stan: I love snakes. This thing needs some poisonous venom to defend itself.

Chris:

Marsha: You know, Chris got hit on the head really hard this morning, maybe he shouldn’t be involved.

Project Leader: Nonsense. Everyone gets a say. Well, Chris?

Chris: … I want it to… sweat milk.

Project Leader: You got it! Ok. Thanks for your input, everyone. I’ll get this done.

Don’t get me wrong, I think the platypus is a pretty neat creature. It’s definitely odd though. Odd enough that it seems to like a unifying concept.

If there was a design meeting to come up with dogs I imagine it would go quite differently. The project leader would come in with something already designed and ask instead for feedback on his current design. When different people have different requests, he accommodates simply by coming up with different breeds of dogs instead of trying to fit everyone’s vision into one animal.

This isn’t all hypothetical

I’ve been part of meetings where the product started out without a design. The developer simply brought all of the potential end users into a room and asked them how they wanted the product to look and behave. Everyone had a say. What came out of that meeting was a pretty terrible mess.

Ok, I lied when I said that everyone had a say. I didn’t have a say. I was a senior member of the team that would be consuming this product and I was heavily involved in training new additions to the team. I didn’t say anything because I was able to identify pretty early that this design was going to be a mess.

So what did I do about it? After the meeting, I sat down with the development team — just me and them. I talked about the problems that we were facing, how the product should logically be laid out to increase productivity and decrease context switching, and why I had made these decisions. Needless to say, the product ended up being built to my specification.

Once a prototype was completed, we then went back to the rest of the team and walked them through it. Asking for input only once the walkthrough was done and the decisions had been explained. There was very little dissent amongst the group and for the most part the design went unchanged and people were excited about what the product was going to be.

I don’t think that I was the main factor in the success of this design. I believe it was simply that there was an overall vision, and one that could be explained logically before seeking input. Many people have a problem working with a blank canvas. There is no base there for people to build on or tweak. Everyone ends up seeing something wildly different, and bringing that together successfully is near impossible without disappointing something.

Not to mention that if something designed by committee has regular checkpoints then it is going to have more requested modifications. In the end, that product is going to cost more and is going to be less accepted.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s