So you’re a seasoned (or perhaps, lightly salted) designer, ready to take your design capacity to the next level. You’ve learned the process, practiced the methods, and maybe even attended a Professional Education class with Cooper. Yet, after all of this training, you are left with the question: “How do I get [my team/my department/my organization] to value design?”

Surprisingly, the answer has very little to do with your team, and much more to do with you. 

As designers, we often operate from a mindset of struggling against an oppressor. We view developers, business leaders, and managers as opponents who see us as wasteful or unhelpful. This is justified; even 15 years ago, the vast majority of organizations had not heard of design, and didn’t see a reason to shift practices.

However, as we continue to operate with this mindset today, we begin to exclude these stakeholders from our design work. We go through our process, excited by the autonomy and ability to conduct meaningful research and synthesis, only to deliver a concept to a discontented developer. Their lack of enthusiasm is a cause for personal frustration, and enables a cycle of exasperation. 

We might attribute a developer’s disaffection with our work to a disaffection with design. However, more likely than not, the developer is discouraged by a lack of consultation. Without input earlier in the process, the developer is unable to address major problems they might see in the proposal - even those that may have been easily fixed. Moreover, they feel devalued, as if their expertise and skill is boiled down to a rote code monkey. They hold no ownership over the project, and as a result, they allow the project to fall further and further in their priority queue. 

This situation is more frequent that we would like to admit, and it illustrates an essential misunderstanding of many designers. We operate with an assumption that business leaders and developers are completely uninterested in the design process. In fact, they certainly do care, if for no other reason than that they take pride in the work they do, just like us. 

So how do we address our natural instinct to shield our work from our stakeholder colleagues? With empathy, of course!

  1. Address your starting biases. Recognize that you may apprehensive about working with non-designers, because you assume they may view your work with contempt. Acknowledge the not-so-pure goals you might have when entering a project - such as recognition, egotism, or the desire for impact. Is the pursuit of these aspirations limiting the ability to address the larger goal? 
  2. Understand your design team. Take the time to learn about your team members. Maybe it’s not a 90-minute interview, but coffee or a lunch date. Consider their needs when they start a project - particularly in regard to ownership, freedom, and the optimal communication strategy.
  3. Keep your eyes on the prize. In the spirit of goal-directed design, keep in mind the end goal: a successful product, service, or strategy for your client. Know that your larger team of people, across disciplines, wants this same goal, particularly when they build investment in the project.

As a leader of the project, ensure that developers and business leaders are updated and aware of your research and synthesis work. Invite them to conduct their own research - perhaps on relevant technologies, new markets, or changing trends in the space. Explicitly request their feedback and support when considering domains or ideas that fall under their expertise. This ensures they have a genuine role on the project that capitalizes on their hard-earned skills to provide real-world insight, building investment in the long-term project outcomes.


Reed Loar is Operations Director, North America at Designit, where he was previously Design Director. Interested in learning more? Consider Cooper Professional Education's Design Leadership class, where we dive into this issue and more to enable functional and creative leadership capacity.