IDEO founder Tim Brown once said, “Design is everywhere, inevitably everyone is a designer.” And it’s a viewpoint that designers are hearing with increasing frequency; because if you’re a problem solver, you’re a designer, right? Not necessarily.

Brown didn’t mean that everyone is a professional designer: someone who can make decisions from expertise and experience. Everyone can participate in the design process, but that doesn’t necessarily make that person a designer. This also does not mean you, the designer, must exclude them, but you shouldn’t allow them to drive the design process either.

In this article, we’ll take a look at how you can avoid design by committee while still maintaining a collaborative design process, something we use a lot at UXPin, a collaborative design platform with a 40-something person team of designers, developers and marketers split between the U.S. and Poland.

Traditionally, a design process enables a designer or design team to quickly move from idea to finalized product. And when we talk about “design," we’re talking about the overall design of any digital product, from UI to UX. With a collaborative design process, an entire team with varying skillsets can easily participate in a product’s design.

As part of that process, you’ll need to designate roles early on to know how long to keep certain members as part of that process. Eventually, you’ll need to whittle down your contributors because not everyone has to participate at every step of the way (which we'll discuss more later). Mastering this balance is crucial and will enable you to design collaboratively on any project.

***

Step 1: Designate Roles & Boundaries From the Start

Collaboration is about building momentum. There are a few folks you’ll want involved in the design process early on, so that you don’t get any last minute feedback that could stall the project. Therefore, it’s critical that you are able to quickly identify who has a stake in the project and who is most affected by any design decisions you make.

Assess the design skill level of your contributors. This helps you both determine the context of the feedback you receive and how you respond to that feedback. For example, if someone lacks a basic design understanding, they may not be able to articulate their feedback using design terminology. So “Make the logo bigger” can be translated to “I’m not sure the hierarchy is correct on this page.”

Think of the business analyst on your team, whose feedback would help you better understand the business goals of a project. Yet, this person may not be able to fully tell you why they don’t like your call-to-action. With this knowledge, you’ll know to ask follow-up questions in order to suss out the underlying problem. Using our “make the logo” example, probe with questions like:

• Why don’t you like a smaller logo?
• What benefit do you see for the user in making the logo bigger?
• What feels off about the logo?

“Why” is a good follow-up question that allows you to get to the reasoning behind a piece of feedback.

To help you figure out the skill level of those you’re including in a feedback session, Everett McKay, Principal of UX Design Edge, advises using a UX Design skills ladder.

According to McKay, most people fall at level zero. At this level, they can only identify superficial design problems. A zero-level designer has:

• A generalized design awareness
• Equates design with technology
• Gives subjective feedback that can either be vague or overly-detailed, dwelling on minute rather than big picture ideas

The higher someone goes up McKay’s ladder, the more they’re able to articulate design problems as well as solutions, and be confident that their proposed design solution is actually correct—and thus the more valuable their input becomes. This ladder can be useful in determining how to frame your response to each person’s feedback. You can also use it as a means of figuring out how to approach each person and what kind of feedback you’ll want from them.

For example, you might ask for feedback on copy from a marketer whereas you wouldn’t want the same kind of feedback from a developer. The reverse is true: You wouldn’t want implementation feedback from the marketer.

A few cautionary points when determining people’s roles:

• Executives fall into the trap of making others fulfill their opinions. Executives who are left out of the process can be a blockade as a project nears completion. They could come in with different ideas that don’t align with a project’s current direction, throwing everything into chaos. That’s because an executive’s opinions can be deemed as marching orders that you’ll have no choice but to follow.

• Developers are overworked and technically skeptical. Developers can end up feeling like code monkeys if designers fail to seek their input throughout the process, and they could become defensive at the prospect of implementing a design that might not even be possible to code. Just like you wouldn’t enjoy last minute design changes, they (rightfully) aren't big fans of last minute features.
• Project Managers think in terms of outputs and timelines. Their job is to move projects along, so it’s in their nature to want more—and faster. However, this could also create a lot of friction as design thinking could be sacrificed for the sake of expediency.

Give those executives, PMs, and developers a voice—but don’t bend to their will. Otherwise, you’ll design by committee, which is product death by a thousand cuts.

Committee design is not collaborative. It’s a dictatorship of many, and you’ll be reduced to implementer rather than facilitater. In order to remain in control, you must kick everyone out of the process at some point (we’ll get to that), especially when it comes to integrating the feedback into your design.

Just because you’re collaborating at one point does not mean that design itself is completely collaborative. There are times when everyone’s feedback is needed, such as during the early stages, and times later on when you’ll want to narrow that list.

When determining whose feedback is needed when, here are three questions to keep in mind:

Who are the stakeholders? — Figure out which key stakeholders must be involved end-to-end on a project. A stakeholder is someone, as the name implies, with a stake in the project—a person who has a vested interest in the success of the project. This can be an executive, such as the CEO or a VP, a department head, a project manager or whoever might stand to lose something if the project goes off the rails. You’ll have to do research to determine who on your team is a stakeholder by interviewing them.  

Start by interviewing potential stakeholders using Kim Goodwin’s extensive guide (broken out by departments) so you can clear the air as soon as possible. Goodwin advises you to ask everyone what their role in the project is. Get everyone’s thoughts on what worries them most about the project as well as their take on whom the product is for. Ask marketing stakeholders their views on the users and what worries them about the competition. Talk to engineering stakeholders about the tech under the hood so that you have a better understanding if something you design is feasible to implement.

Identifying the stakeholders sooner rather than later will help you avoid last minute feedback that could derail the project. Additionally, deciding who is not a stakeholder helps you make the best use of that person’s limited time.

Whose feedback is needed when? — The exact moment when each collaborator should be involved in the design phase varies. It is paramount to always have the fewest, but most useful, people in the room. To do this, evaluate the priorities and subject matter expertise of each stakeholder. For each group ask a few questions. What is that person’s skillset? When is their opinion most valuable to my process? When would I be wasting their time?

For example, consider your executive team. When the feedback process is botched, most executives go on a search-and-destroy mission at the end of a project, demanding changes or even taking it upon themselves to start designing (with some horrifying results). It’s crucial to identify key stakeholders and involved them as early in the process as you can. If you don’t, late comers will feel like their opinion isn’t valued or valuable—when, in reality, it is. Leaving key stakeholders out in the cold will erode trust in you and the project.  

Here’s a few things to keep in mind when trying to figure out whose feedback is needed when:

• Involve executives early on. They’ll have business insights that can help shape the goals of the design. More than that, you’ll build trust by having them participate early in the process.
• Kick marketing out when it’s time to design. A marketer will have insights into messaging. They’ll also help generate a lot of ideas (more on that later) and they might have useful feedback at the prototyping stage. But they may not have anything valuable to contribute when it comes to visual designs or the actual implementation of the design.
• Validate ideas with your sales and customer service team. These folks are on the front line with your customers. They’ll tell you whether those ideas align with what customers want to accomplish. You can also involve them as you get closer to implementation to see if your solution is the right one for the customer’s problems.
• Bring developers in before implementation. Work alongside your developers to see if what you’ve designed is technically possible. Don’t just hand in your designs at the end and expect developers to make it happen.

What feedback are you looking for? — Don’t get stuck in endless feedback loops. You must know how much is required to move forward—and when enough is enough. And that starts before you even get into a feedback session.

Determine beforehand what feedback you’re seeking. What are the specific areas that you need to know work or don’t work? Come armed to any feedback session with questions of what it is that you want to know. Are you seeking feedback on the layout? On the overall concept? On the copy?

To keep everyone on track in any feedback session, set an agenda that outlines your objective. As the designer, you should be in charge of the feedback session. Don’t let others drive it or you’ll go off on tangents, getting critiques that may not be relevant to what you’re currently working on.

Look for patterns. Is there commonality among the feedback? If there is a piece of feedback that’s repeated, then something much deeper must be investigated. Listen closely when someone points out a problem. Then ask plenty of questions if they try to offer solutions. Remember: not everyone will use design language.

Once you’ve heard everyone’s feedback, it’s up to you to synthesize it. You are the decision maker on the product.

Ultimately, the designer should be decision maker on the product. However, it is still designer’s responsibility to seek insights and ideas when needed, and to continue looking at the problem from multiple perspectives.

Collaborative Design Formats We Use at UXPin:

Now that we’ve identified your players of collaborators, let’s get into how to actually collaborate with them. There’s plenty of collaborative design techniques, such as using post-its to come to a consensus, but we’ve found that a brainstorm kick-off works best for us because it gets everyone involved and felt as if they are being heard.

Start Broad…

Divergent thinking, or thinking of many perspectives as opposed to one, is required in the beginning in order to “think broad to get narrow.” Explore as many potential solutions as you can—such as creating mind-maps and holding brainstorming sessions. You want as many minds as possible to help identify the right problems before even starting to think about a solution. This is where everyone truly is able to be a designer because problem-solving is a universal skill.

Get everyone involved in the brainstorming phase. You’ll want to have an open and flat structure, which means everyone has equal access to resources such as design files, business metrics, and user data.

Allow anyone who wants to participate in the kickoff to also partake of design studio exercises, which help get everyone excited and involved. The goal of these exercises is to generate ideas through sketching—taking pen to paper and drawing out their potential solutions. Don’t restrict people’s creativity so that they come up with out-of-the-box solutions. We do this on a regular, monthly basis when thinking of product improvements or new features.

For example, we hold a brainstorm kick-off for every project, where anyone from any department is welcome to join. We typically provide a brief on the project, sharing data, and other interesting factoids. But participants can’t be passive observers. They have to sketch out their ideas alongside the designer and then be able to discuss why their suggestion is a possible solution.

You can also use the “How might we...” approach of design thinking to keep everyone on task. It’s way to riff and build off ideas by saying, “how might we do X” or “how might we make Y better.” Remember: It’s your job as a designer to focus everyone on the goal at hand in any studio session.

Afterward, the designer must take all the sketches back to his desk and unify them by finding the pattern among them. Once again, the final call is in the hands of the designer.

…Then Narrow the Playing Field.

As you iterate, lean on convergent thinking, which means you’re selecting the best possible solution to the problem. This is where you’ll decide which ideas are worth pursuing, which elements to remove, and where to add fidelity.

At this stage, you’ll want to seek the feedback of someone with a sharp design skillset, such as a design lead or project manager. This type of person is useful in separating valid feedback from opinion.

You’ll also want to move toward an open and hierarchical model as you develop the first wireframes and prototypes. In this model, anyone can still contribute, but only the core product team decides which ideas move forward.

One way to communicate this shift is to let others outside the product team know where you are in the process and reiterate the goals of the project. If you’re sprinting toward a finish, let them know that.

However, listen to what they have to say. Keep a text file where you can collect ideas and suggestions for future iterations. Let others know that’s where you’ve placed their ideas. Don’t dismiss them just because you’re on a deadline or else you risk alienating those whose input you might need on later projects.

As we discuss in our post Design Collaboration in the Enterprise, you’ll still take stakeholder feedback into account, but the more disciplined model outlined above helps prevent executives from “swooping and pooping” as they please.

When people give feedback in the form of a solution, always ask them what the problem is they’re trying to solve. Feedback is a two-way street and you have every right to respond constructively. Feedback is a negotiation, not a mandate.

A few tips on how to handle this late-stage feedback:

• Treat feedback as a dialogue. Feedback shouldn’t flow in only one direction, and it shouldn’t just be prescriptive either. It should spark discussion and a designer should feel free to challenge the thinking behind a piece of feedback (constructively, of course).
• Ask follow up questions. If a piece of feedback is directive rather than open-ended, ask follow-up questions. This way you’ll get to the root of the problem. For instance, if someone merely says, “make the button bigger,” you can ask why that would make users click on it more. Try Dustin Curtis’ three question rule: Always ask the other person three questions before discounting their opinion.
• Back up decisions with facts. It’s hard to dispute cold, hard facts. Whenever possible use statistics, user data, usability research, or design principles to sell your ideas.

It bears repeating, however, that the final decision is with the designer. Maintain this position as you refine the product, otherwise the project will dissolve into a pile of compromises.

The best design comes from making decisions and then learning from them. Use your judgment, test with users, analyze where you can improve, and then repeat the cycle. If you try to please everyone as you iterate, you’ll still end up failing—and in several different directions at once.

Be sure to loop back around after you’ve iterated based on the feedback. This lets everyone who gave feedback know that you listened to them even if you didn’t implement every piece of advice you received. Doing this will also benefit you in other ways. You’ll strengthen the trust between you and those you sought feedback from. Also, showing your team what came of the feedback will also further get them excited about the project and allow you to gather steam as you hurtle toward a finish.

Everyone is a design participant, but you’re the expert. You must drive the design and not allow others to drive you. Understand that the modern designer is equal parts facilitator and creator. If you can’t facilitate, someone else will eventually trample on your creations in order to do so.