Threats to Your Project, Part 2: Design by Committee

Caption

Too many voices fighting over a single project creates its own problems.

This is the second post in a 3-part series on threats to your project.

My previous post in this series, Surviving a HiPPO Attack addresses how to manage a HiPPO, the highest paid person’s opinion. The reason HiPPOs are able to influence decisions is due to their position in the pecking order. Good or bad, their decision is final. This type of executive decision can be tied to the person who made it. A HiPPO isn’t the only possible threat to your project. What happens when you have a room full of people who are equal in their organizational pecking order, and everyone wants their tastes and opinions included? Or, when the person in charge wants to “run it by their team?” In this case, you’re facing the threat of design by committee.

My team has been involved in designing and redesigning several web projects in the past decade. Almost every time, a project is kicked off to an enthusiastic start. We discuss wish lists, user studies, stakeholder goals and requirements, and explain all the user experience awesomeness that is needed — all of which is met with excitement and understanding by the clients.

Then, the conversation turns to how to handle the content and design, and it’s as if that initial kickoff meeting never happened. Instead, the conversation turns personal, to something flashy someone saw on another website that they want to implement on their new site. Or, how someone higher in the pecking order despises a certain color so we can’t use it for the design. I have sat through way too many painful meetings where the “committee” requests specific colors, fonts, shapes, and photos without understanding why their organization needs a new design.

Design by committee happens in most large organizations. A group of people from various departments are designated business owners or stakeholders and given reign to lead projects. No one wants to make a decision because two or more stakeholders have competing opinions. This is when it all goes downhill.

We can save this from happening.

As a digital species, we have evolved greatly in the last few decades. We can curb our lizard instinct to treat our websites like our cave paintings. It will take a cultural shift at most organizations, but I have noticed a change starting to happen. It’s happening within a few organizations I respect and follow. There’s no reason why the rest cannot follow suit and save our own organizations from failing projects and compromised goals.

So how can we avoid designing by committee? Let me take a stab at it with the following suggestions:

Choose the Right Stakeholders to Own the Project

“Of course we get the right people involved,” you say. But I have seen many agencies appoint stakeholders based on their personal interest or availability. Many times, the project owner has nothing to do with the project after launch. This poses a huge risk. Projects should be led by stakeholders who will have their stakes deeply rooted in the product after the project itself is complete. This keeps them committed to their goals and requirements as they live with the effects later.

I’ve seen many agencies struggle with their websites post implementation when they require a project manager to also bear the role of business owner. A project manager’s primary goal is to finish the project on time and within budget. This goal is very important, but it is not the goal of a business owner. With a website design project, there’s so much more to its life after the project has been completed. There is the afterlife of implementation, content management, and maintenance.

With that in mind, the business owner should be someone who has previous experience with the live site, and who’ll be leading the internal content and support post launch. To that end…

Stakeholders Should Be Empowered With Context to Make the Right Decisions

Often, poor decisions are a result of a lack of information.

If you happen to be a stakeholder on a current project, it’s expected that you’re representing your domain and you're part of the project. If you’re involved from a business, communications or security aspect, you’ll be looking out for issues that impact your domain. So, it’s important for you to understand the context of the areas outside your domain, and how those may influence the project.

Recently, we started including our research and analytics results along with deliverables requiring approval at each milestone of our projects. This has shown significant value in the signoff success rate. Stakeholders not only see deliverables such as updated information architecture or wireframes, but they also get insight into the reasoning behind the change, see user testing data, and any thought process that has gone into the deliverables. This helps them process the information and understand the reasons behind it.

Making sure stakeholders have all the necessary data helps cut down on the number of extra requests to “just see how it looks this other way,” because there’s a greater understanding that our proposals have reasons behind them.

Two Is Company, Three's a Crowd

Sometimes, we (the design or web team working on projects) enable the design by committee threat. When you get all the stakeholders and other curious minds in one room and ask them what they think of a proposal, what else do you expect? When a group of people come to the table, there are the vocal and the not-so-vocal participants in the mix. The vocal participants tend to dominate the conversation. If the vocal members have different viewpoints, the meeting either ends in a fist fight or consensus. (Well, most often it’s a compromise in disguise as a consensus.) We are a civilized society, after all. But compromise in design can be as bad as any other solution.

Instead, I have seen tremendous success in communicating proposals with stakeholders individually. This might take a toll on your efforts to schedule and repeat your pitch, but dealing with one-on-one conversations is much more beneficial than dealing with conversations you cannot control. This also ensures every person is heard - including those who aren’t comfortable speaking up in a crowd.

When discussing one-on-one, you get valuable feedback to put together a solution that takes the project to the next level, rather than trying to steer the conversation to make sure you don't go a step back.

When aggregated feedback turns into a solution for the project owner to approve, they still might choose to discuss with other stakeholders. This time however, there is a good chance your one-on-one conversations will keep the internal conversations informed and on task.

Do Your Job, and Trust the Designers to Do Theirs

This point is specific to interface design. Everyone involved in a web design project has an opinion on the colors, layout, and fonts, even if that’s not their area of expertise. This is the point where we find, there are plenty of opinions flying, but no one can get into the specifics of a solution.

A design is a solution towards a problem experienced by a real user. It’s not a canvas for personal expression. Design is not personal like our taste in music or art. A strong designer makes design decisions based on user research and best practices, with a focus on communicating clearly and achieving business goals. Still, this does not hold people back from stating “something should have more jazz” or “it doesn’t make me jump out of my seat and say wow.” What if it’s not supposed to? This is where it’s important to remember that you hired designers because you needed someone else to do that job. Ask your stakeholders to trust that the designers know their job as well as they know theirs.

Testing Testing Testing

As a picture is worth a thousand words, a single test result is worth more than a thousand opinions. You should constantly remind stakeholders that the website or the application you’re working on is eventually for the users. It’s important to make sure the users are going to understand the design and are going to interact with it in the most efficient manner.

We can get a sense of user interaction by testing ahead of time. There are several ways you can test mid-stream deliverables. There are tests you can perform in person, remote, online under observation, or over a phone. Test results confirm the fact that stakeholders and designers are not users. When a stakeholder says “I think a user would like to see a beautiful big photo,” receive it as an opinion that the stakeholder wants a big image that will take up half the screen real estate, hide important content, and cost a small fortune in mobile data download costs. This is where user testing can help level facts with opinion, and help the business owner make an informed decision.

Testing also helps the business owner make an informed decision.

The Only Thing to Fear…

Finally, we can only control what is within our circle of influence. While some of us might control how project teams are formed, we cannot control work cultures that are fueled by fear.

Fear of failure keeps stakeholders from taking ownership of their decisions. By looping everyone in to make a consensual decision, no one person can be held accountable. The best way to battle that decision-making fear is with information. By making sure you keep your stakeholders informed with all the needed background knowledge and test results, they can confidently make the right decisions for their users.

Related Link

• Part 1: Surviving the HiPPO attack

Related to: 

• Leadership