“Design is everywhere, inevitably everyone is a designer,” says Tim Brown of IDEO.

That’s something we’ve heard time and time again. Because if you’re a problem solver, you’re a designer. Even Don Norman, who coined the term “user experience,” says that everyone is a designer. As he writes:

“We are all designers. We manipulate the environment, the better to serve our needs. We select what items to own, which to have around us. We build, buy, arrange and restructure: all this is a form of design.”

Don’s talking about how we bond with products and make them our own. However, it doesn’t necessarily mean that everyone is a professional designer, who can make decisions from expertise and experience. As he says:

The 💜 of EU tech

The latest rumblings from the EU tech scene, a story from our wise ol' founder Boris, and some questionable AI art. It's free, every week, in your inbox. Sign up now!

“Professional designers can make things that are attractive and that work well. They can make beauty, create products we fall in love with at first sight. They can create products that fulfil our needs, that are easy to understand, easy to use, and that work the way we want them to.”

So saying that everyone is a designer is a bit misleading.

Everyone can participate in the design process, but that doesn’t necessarily make them a designer. That doesn’t mean you have to exclude them, but you shouldn’t allow them to drive the design process.

Welcome Everyone Into the Design Process … Then Kick ‘Em Out

Everett McKay has a UX Design skills ladder to figure out your actual skill level or measure the skills of your team. At level 0, you can only identify superficial design problems and that’s where nearly everybody falls. The higher you go, the more you’re actually able articulate design problems and be confident that the design solution is actually correct.

Photo Credit: _dChris, Creative Commons 2.0

For Hudl’s Kyle Murphy, there are the obvious designers on a team, such as, well, the designer. In his excellent talk “Everyone is a Designer, Whether You Like It or Not,” Kyle says there are other designers on the team, such as executives, developers and product managers.

He also outlines the less obvious choices, such as legal, sales/marketing, spouses and customer service. But that doesn’t make everyone a good designer.

As Kyle points out:

• Executives come in with a “swoop and poop” mentality.
• Developers are overprotective of their database and code.
• Project Managers want more, faster.

Give those execs, PMs, whoever a voice initially. But don’t bend to their will.

Like we reiterated in Web UI Best Practices, committee design is not collaborative. It’s a dictatorship of many, and you’ll be reduced to the role of implementer rather than facilitator. You’ll also eventually want to kick everyone out of the process at some point.

Design is Collaborative … Until It Isn’t

Just because you’re collaborating doesn’t mean that design is completely collaborative. There are times when everyone’s feedback is needed — during the early stages — and times when you’ll want to narrow that list.

Collaboration is about buy in and building momentum. There are few folks you’ll want in early on as we discussed above so that you don’t get last minute feedback that could stall a project.

Here’s three things to keep in mind:

• Who are your stakeholders. Figure out which key stakeholders must be involved from end-to-end on a project. Interview them using Kim Goodwin’s extensive guide (broken out by departments) so you can clear the air as soon as possible.
• Whose feedback is needed when. It’s easy to want to involve everyone. But you shouldn’t. Figure out who is needed at different points along the process. For instance, a VP of marketing may be great at the beginning to gain insights into branding and goals, but could become a major roadblock if involved in minutiae near the end of a project.
• Know when feedback is enough. Don’t get stuck in endless feedback loops. That’ll be a momentum killer. You’ve got to know when you’ve had enough to actually do the work.

Let’s walk through a  process that’s worked well for us at UXPin.

Start Broad …

Divergent thinking is required in the beginning to “think broad to get narrow.” You want as many brains as possible to help identify the right problems before even starting to think about a solution. In this sense, everyone truly is a designer because problem-solving is a universal skill.

Photo Credit: Jacob Bøtter, Creative Commons 2.0

Get everyone involved in the brainstorming and kickoff phase. You’ll want to have an open and flat structure in which everyone has equal access to resources, such as design files, business metrics and user data. Allow anyone to participate in design studio exercises as part of your kickoff. We do this on a monthly basis at the minimum whenever thinking of product improvements or new features.

However, it’s your job as a designer to focus everyone on the goal at hand in any studio session. You can use the “How might we….” approach of Design Thinking to accomplish this.

Then Narrow the Playing Field

As you iterate, convergent thinking starts to drive your decisions in deciding which ideas are worth pursuing — which elements to remove, where to add fidelity, etc. You’ll want someone with a sharp designer skillset, not just a designer’s mentality, at this stage. 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. Anyone can still contribute, but only the core product team decides which ideas move forward. You’ll still take stakeholder feedback into account, but the more disciplined model helps prevent executives from “swooping and pooping” as they please.

When people give you feedback in the form of a solution, always ask them what problem they’d like to solve. If you still stick with a drum circle model, you’ll find that the design will get stuck in feedback purgatory at some point – or worse, people go with the path of least resistance.

Remember that feedback is a two-way street and you have every right to respond to feedback. It’s a negotiation, not a mandate (we discuss specific tactics in Design Collaboration in the Enterprise).

Be sure to maintain the same structure and process as you refine the product, otherwise it will dissolve into a pile of compromises.

Good design is about making decisions and learning from them. Use your judgment, test your designs with users, analyze where you can improve, then repeat the cycle. If you try to please everyone as you iterate, you’ll still end up failing – except you’ll now be pulled in conflicting directions when you struggle to fix things.

The validation cycle breaks down, killing your product whether the HIPPOs want to admit it or not.

Everyone is a Design Participant, But You’re the Expert

Everyone is a design participant.

But you’re the expert. You must drive the design, not allow others to drive you. Understand that the modern designer is equal parts facilitator as creator. If you can’t facilitate, someone else will eventually trample on your creations.

If you’d like more design advice, feel free to check out the free e-book Web UI Design Best Practices. It’s part of our free design e-book library, which features tips from experienced product and UX designers and visual examples from top companies.

Read Next: How to use design thinking in your next project

Image credit: Shutterstock