May 27, 2022

How to Champion HCD and Design Research to Stakeholders

A group of coworkers crowd around a conference room table to discuss and look over a design research plan.


Design and research professionals like us need no convincing of the value behind conducting human-centered design (HCD), service design, and design research. We can confidently speak to how conducting research improves services, de-risks product launches, and uncovers insights that lead to product and service innovation. We also know there are major benefits to implementing HCD (human-centered design) initiatives, like increasing customer satisfaction, retention, and loyalty.  Though the importance of taking a human-centered approach is a no-brainer for us, the power of this work might not be so obvious for those outside our field. For example, stakeholders and executives working at organizations who fall lower on the UX Maturity Scale (which can also be applied to HCD), and who are new to design research, might be apprehensive to involve end-users and customers in much of anything.

We know overcoming objections to this type of work can be a challenge, but don’t fret! We’ve been in the position of trying to communicate the value of conducting research before and by this point, we’re pros. 

In this blog post, we’ll cover…

  • The importance of stakeholder management
  • Challenges to overcome with research resisters
  • Common objections to doing user research and how to respond


The Importance of Stakeholder Management 

First of all, let’s discuss stakeholder management and the critical role that internal stakeholders play in our project work. As service designers, our mission is to “connect the dots” to deliver seamless experiences for our end-users, but to do that effectively in large, complex organizations (i.e. government or enterprise) we need to equally be able to connect the dots between people, projects, departments and teams within our organizations. This means knowing who should be involved, at what stage, and in what way throughout our projects.

How might we do this? Here are a few examples: 

  1. Identify similar or related initiatives happening across the organization that can help you get a “leg up” in your own work. Can you share resources or coordinate your efforts with other departments?
  2. Gain a broader understanding of how your work will align with your organization’s greater strategy. Understand what sort of impact the organization is looking to achieve, and how it will be measured.
  3. Learn who else in the organization might be able to help you. Are there domain experts in adjacent teams? People who have done something similar in the past? People who might benefit from this work and who should be consulted? People who can put you in touch with specific segments of users?
  4. Develop an understanding of how mature your organization is in terms of design. All organizations are on a journey, and some are just starting to embrace human-centered design. It’s important to understand where your company and stakeholders are at with their own understanding so that you can effectively communicate the value of your work, meet them where they’re at, and then bring them along with you.

UX Maturity - Guide to UX Maturity and how to level up your organization.

Much like building empathy maps for end-users, we like to “map” out our internal stakeholders. Who are they? What do they want? How do they measure project success? Etc. We keep track of all the decision-makers, subject matter experts, potential advisors, and supporters we meet from across the organization, and work with our design team to figure out where, when, and how we will engage them in our project work. We build them right into our project plans, in fact!

This is something that your product owner product manager, or supervisor will be able to help you with, as they themselves will have experience navigating the organization and will have a point of view on how to fold others into the work. After all, good design cannot happen in a vacuum! A practical solution would be to create a template to keep track of all the internal stakeholders you meet in a project, and update it as you learn more about them throughout the project.


Challenges to Overcome With Research Resisters

There are several distinct challenges experienced by design teams with stakeholders who are resisting the research process. Remember, your stakeholders are trying to do their job as best as they can. You’re coming in and making suggestions about a product or service that they feel particularly close and connected to – their “pride and joy,” if you will! It will take patience, strong communication, and a mindset shift to break down those barriers and overcome the resistance. Let’s break ‘em down…

  1. Trust building Conducting research and uncovering new insights often means change is around the corner, which can be scary! This is why building trust to ease fears is a key component of a successful research initiative. You can build trust by always being transparent and honest with your stakeholders about your research activities, allowing them to review interview scripts and research plans–and even building them together. Once you’ve brought them along, invited them to user interviews, and sought their feedback frequently, you’ll notice they will start to release control and trust you. Seek to understand and build empathy for everyone who will have to experience change as a result of the insights you uncover. Reassure stakeholders that the work they’ve done up until this point is important and helpful, and that you are there to build off of what exists and uncover new insights as well. Instead of, “you’ve done it this way, but you should have done it this way,” rephrase the conversation as “you’ve done it this way in the past, and we’re going to build off that together.”
  2. Education & awareness – The more you can educate stakeholders on the human-centered process, the more receptive they’ll become! One of the best ways to educate the value of design research is to host a lunch and learn session or give a presentation at the onset of a project. Send out personalized invites to team members and stakeholders, as well as other managers and staff involved in product and service development. Try to invite people who you feel are open-minded to the process. Take this opportunity to explain the HCD process, how service design and UX work together, and how valuable research is. Don’t waste your time with stakeholders who wouldn’t be excited about improving the experience!
  3. Moving towards a consultant’s mindset This means thinking more about the organization’s goals, business drivers, and the psychology of your team and stakeholders. What are their professional goals? Why might they be acting in a certain way? What pressures do they feel at work? How will this change/new product affect them and the organization? While considering these points, be sure to continue championing the HCD process. 


Common Objections to Doing Research & How to Respond

Once you’ve identified your stakeholders and received some green lights to conduct research, you may still run into some common objections. Below, we’ve summarized the top three objections to doing research and crafted easy-to-follow solutions and responses for you to bring into conversations! 


Objection #1: “We already know what our users/customers will say”.

If you’ve ever heard from a stakeholder something along the lines of the above or  “Our account managers talk to our customers and tell us what they need” this one’s for you. The first and the best thing you can do in this situation (and most situations!) is to practice empathy. Your stakeholders are under pressure from their own higher-ups to get projects moving, hit deadlines, and stay within or below budget. There’s also the point to be made that you don’t know what you don’t know. A stakeholder may genuinely believe that they undoubtedly know their user, and as the design professional, it’s your job to steer them away from this mentality–they are not the user!

Here’s how to respond: “I appreciate how much you know about the process/service/workflows we are designing and your perspective is invaluable to the design work! It’s also always important to talk to the people who will be using the solution every day to see what they think. This way we can learn from them what they actually need, uncover ways to streamline their processes, and find new opportunities for innovation and improvements. Not to mention users will have a chance to be included in the process. It’s always nice to catch a few different perspectives as well, just in case opinions differ, and based on our experience, some users will mention things that others don’t along the way!”

This image directs you to one of Outwitly's freebies: The Empathy Map Template available now for download through the link attached.

Objection #2: “Our users are busy people, and I don’t want to bother them.”

If you’ve heard this one, it was probably accompanied by another time-related objective like “it will be too hard to organize their schedules,” or “I don’t want to add more meetings to their calendars.” The good news is that this objection can be very easily worked around!

Here’s how to respond: “I hear your concerns here. To be mindful of this, I’ll make sure to work around our user’s schedules so they don’t feel put out by our request. Asking for people’s time might seem like you’re creating an inconvenience for them, but more often than not, people are actually SO excited to take part in this process and to have the opportunity to be asked their thoughts and opinions. You’ll be surprised how willing they are to lend a helping hand. Besides, it’s really important to bring these users along for the journey, even if we think we know what they will say, we want them to feel like they are being heard in this process, which will help with the adoption of our new feature/product/service launch in the long run.”


Objection #3: “It’s too early in the process to talk to users or show them anything.”

Once you’ve gotten to the stage of prototyping and testing (especially in the UX world) you might hear this objection. Executives might be worried that users will see their unfinished mockup and think that it’s the final product. The last thing a stakeholder wants is to feel like what they’ve produced won’t be well received, or that they’ll disappoint their users. It’s easy for them to get caught up in this culture of fear which often leads to the mentality of “if we don’t uncover it, we don’t have to deal with it”. That’s why context-setting with users at the onset of usability testing testing is so important–and you can explain this to your stakeholders.

Here’s how to respond: “I know showing users unfinished designs feels daunting, but in product development, testing early and often is actually more ideal than you might think! When we properly establish the context with our users, so they understand the design is unfinished and it is only a prototype, we’re able to uncover usability issues and new ideas to improve the product before we spend too much time and money on final designs and development! It’s much easier to change a wireframe than it is to change code, so getting this feedback on our initial design will provide a ton of value moving forward.”


Despite how challenging it can be to communicate the value of conducting HCD and design research, you have to persevere! We hope the tips in this post will help you on your journey in getting stakeholders on board with these processes.


Resources We Like: