Black and white photo of two men arm wrestling over cash

Build UX Awareness With Stakeholders In Your Company

  • LinkedIn
  • Twitter
  • Facebook

This problem shows up often on many UX forums. An intrepid UX’er wants to bring the other 90% of user experience skills outside of design to bear on the problems customers and the company face, but cannot get traction beyond the “wireframe/design mockup without research cycle trap” many of us fall into. An experienced UX researcher is brought in by a single advocate to fix some nebulous usability (probably) problems. Although experienced, the researcher may have been lucky to only work with teams of other UX’ers or companies with some knowledge of the full field.

We address either experience similarly. Tackle it like any other UX problem. User experience is about understanding and gaining empathy for the user, then providing value by solving their problems. In this case, the users are the leaders and stakeholders inside the company, as well as your teammates.

Note: you will find we always use “teammates” instead of “employees” throughout our articles. We do this because you need to break down your own us versus them mentality before you can expect others to as well. With that, let us break down an approach.

Keep in Mind the Point of UX When Building Awareness

Never forget the point of UX when convincing others of its merits. It is not to produce deliverables and slick designs; it is to deliver results for both the company and the users. User experience research especially helps us to score how we are doing in:

  • Accessibility
  • Productivity
  • Usability
  • Addressing pain points
  • Meeting user goals
  • Discovering user mental models
  • Delivering value to users

Identify the Stakeholders for UX Work

Start with identifying who in the company will be the primary stakeholders affected by a more thorough user experience approach. Not only who will benefit from UX research, service design, and usability testing but also who has a perceived negative impact. Some teams will immediately see the benefit of understanding users, and others will see it being too time-consuming. Furthermore, you must understand their drivers around changes that impact products and the customer.

Typical stakeholders around UX product work are:

  • Strategy Stakeholders (C-suite, department heads)
  • Product Teams (developers, QA, designers, product owners)
  • Customer Experience
  • Business Development (product managers, sales)

I will cover methods for each UX stakeholder and some techniques that work regardless of the stakeholder role.

Strategy Stakeholders

Bring the Value

For strategy stakeholders educate on UX aspects that affect product strategy or performance in other areas of the business. Show the return on investment (ROI) that UX and any proposed work is going to bring. Your responsibility as the UX Designer/Researcher/Engineer/Unicorn is to demonstrate the value UX delivers. At any size of company, there is always a balance happening around limited resources. Often the most valuable resource being time. UX provides value in many ways, but one of the easiest to show is the amount of time you can save product development. Doing early discovery, idea validation, and usability testing decreases time spent by teams supporting bad features, redoing invalid UIs, and customer support around bad workflows.

Gather feedback from team members across the organization to show evidence that there might be a problem that’s worth investigating. Are there suspected unused features, high support volume around a workflow, or complaints from the field? Sometimes you will need to find third party data, like case studies to show value or do smaller-scale tests to show the potential benefit. Pick something easy to measure, like support volume before and after changing a UI.

UX Informs Product Strategy

Making decisions around strategy is not easy; UX’s most important deliverable is relevant knowledge about users. Call out gaps in knowledge around features and new work, especially risky assumptions. Always treat assumptions as hypotheses that need proof, and are not facts. Focus on the riskiest assumptions first, since researching those delivers the most value. By demonstrating the type of knowledge you can provide to product and market strategy, you will show the potential for reducing guesswork.

Start “small” when picking a project. The work needs to have value, but do not let ambition get in the way of pragmatism. You will not improve UX maturity at your company if the initial projects fail to produce value because they never finish or are hard to measure. Balance the risk of an assumption and the time required for research. Using a tool like Weighted Shortest Job First (WSJF) will help prioritize current UX work. As you gain more support for UX projects you will want to add in more user-centric scoring like Jobs To Be Done (JTBD) or the KANO model.


For strategy folks, use quantitative research initially to warm them up for mixed methods later and hopefully qualitative research. They love numbers; numbers feel concrete and safe and are familiar from other performance metrics. Start collecting analytics around critical interactions with customers, or analyze existing feedback from past surveys. Analytics and surveys are methods the C-suite roles are already familiar with and feel (mistakenly) are lower effort or “safer” than user interviews.

By focusing on quantitative research first, you start collecting data early and finding clues to usability issues. These issues can optimize where you spend time performing more qualitative methods like user interviews later.

Good initial UX questions your quantative data should answer are:

  • Where is the product underperforming in usage?
  • Are there features not getting used?
  • Is there high usage in help areas like password reset, search, or help documentation?
  • Do certain areas have higher bounce rates?

Some of that data will show possible features that can be removed. There are usually areas to point out for improvements or elimination that save in development and support costs. CTOs love this because they know every existing feature has a support cost, regardless if no one is using it.

Fact-Based Decisions are a UX Super Power

Focus on how UX and user research help drastically reduce risk and uncertainty when developing products. UX methods provide a bevy of tools for every situation and time-frame to problem solve and understand user goals.

Do the same for UX, reduce the uncertainty for your stakeholders. Educate your stakeholders on how UX work is based on solid methods, not opinion and heresay. Research and provide case studies that demonstrate the effect UX has on the bottom line. Use studies and reference articles that your strategy makers will consume. Summarize studies you do not think they will read.

Here are some excellent places about the value of UX to start with:

Departmental Value

For Marketing departments, the focus is on the marketing funnel and user experience best practices will decrease funnel friction for potential and existing customers. Usually, the landing page for a product is easy pickings for usability and improvements. Make some improvements and get user feedback from a representative audience. The input can be a powerful educator for executives. Be cautious if you are new to the company, the design might be someone’s pet.

For all departments and executive levels, customer and user research sessions on the product are powerful educators. If UX is new to the business, then they probably haven’t done decent user research. Showing C-suite stakeholders the high/low lights reel from user research will be educational for them. Look at customer life-cycles from a service design perspective across departments and look for gaps in communication and stage hand-offs. These are often quickly addressed.

UX Awareness with Product Teams

Much of the pushback from developers towards UX usually stems from a few perceived problems:

  • Too much focus on producing “latest-greatest” visual design instead of solving problems for users.
  • Untested designs that get “tested” in production for usability and produce churn for the team.
  • Designs that do not understand the medium (HTML, Android, iOS) and break platform conventions or are costly to implement.
  • Design activities/workshops that do not deliver concrete outcomes.

My background is software engineering, but I have performed HCI/UX roles for about 20 years. Even with the benefit of experience and the ability to code, it is tough to design for multiple platforms without team help. I lean heavily on Android, and iOS leads to understanding the cost of a custom UI pattern versus using a pre-baked platform component. Even if you are part of a larger UX team, you still need to approach UX as a collaborative and educational task for everyone. User experience is everyone’s responsibility, and it is easier the more non-UX specific people understand it. Get the client-side developers involved and take every opportunity to teach them UX techniques.

Work closely with product teams and again focus on the value you and user centric thinking can bring to them. There are simply going to be designs and experiences that have to be implemented differently between web, iOS, Android, plus whatever else. There are very few designers who can keep up with all the platform-specific design changes and have a good understanding of each medium. Getting specific developers and QE (quality engineers) involved early helps prevent “delivering” designs that miss the mark for a platform and cause mistrust in UX from the product team.

An excellent exercise is getting developer input and involvement early in the design process. Early involvement will address objections early and educate about UX methodologies. You’ll need the help from the developers to design for the platform, and they’ll appreciate participating. When introducing UX practices, start small, and only add one or two techniques per project and only ones that will specifically deliver value. Do not use activities just to do them, they should always add specific value to product development. Pick a project to get early user testing on wireframes, prototypes, and mockups and share the feedback with the team. Share UX maps like journey maps with the product teams and iterate on them based on team understanding. Do affinity diagrams or empathy maps with different subsets of the team to build a shared understanding of the users and their challenges.

When picking UX activities with product development:

  • Do involve development early in the UX process.
  • Do share the outcomes with development teams.
  • Do pick activities that add value for the specific challenge.
  • Don’t pick activities just to do the activity.

UX Awareness with Customer Experience (CX)

These are your customer support, client services, and other CX roles. These folks feel the pain every day, but can also be “in the weeds” on problems. Meaning they may not see broader strategies to eliminate the source of a problem and instead focus on fixing each symptom as they show up. However, these symptoms provide lots of evidence there’s a core problem to be solved.

What areas is the CX team spending a lot of time helping customers? Can you make an easy measurable improvement and demonstrate the aspects of UX used to do this? CX department heads, along with CX teams, have no love-loss for repeat calls on the same feature. Work with your CX teams to find the most significant time vampires for issues or the highest pain-points of users. What areas is the CX team spending a lot of time helping customers? What seems to cause the greatest frustrations?

For example, how many times do they have to reset passwords for customers despite the platform having a password reset feature? Can you make an easy measurable improvement and demonstrate the aspects of UX used to do this? Can you do some usability tests of password reset to see where actual users are getting stuck?

Get access to the system customer support uses to track incidents. I built reports that classified and tagged support incidents, kept stats on them, and then got feedback from CX on the problem areas and customer interactions that stood out most to them. Having a broader focus on overall usability and UX strategy allowed me to plan preventative solutions instead of reactionary patches. Involving CX in design sprints or diagramming sessions and circling back with them throughout the design process goes a long way to both getting their buy-in and also educating them on the UX process.

UX For Every Role

After classifying and tagging survey results, are there common areas of concern or elation around product areas? If existing survey results can not be quantified, this can be a UX value add for future surveys. Help marketing and customer success teams to build and report on surveys. Surveys seem easy to produce, but asking the right questions and properly takes skill and experience. Analyzing and gaining any insights from the results also takes experience that is a good fit for UX.

Design Sprints (ala Google Ventures/AJ & Smart) go a long way to educate everyone since the collaboration gets people out of their silos and into user centric thinking. Design Sprints also break down barriers because everyone owns the solution and fell like they contributed.

It’s About Teamwork

I like to get as many people involved in UX and my process as possible. Educate by having them participate and share ownership of the user experience. Siloed teams are the single biggest “organization smell” I encounter when consulting that predicts project failure or mediocre performance. Many of the UX activities also happen to be great at breaking down departmental barriers. They build alignment, shared understanding, and build buy-in from skeptics.

Further Reading and References

  • LinkedIn
  • Twitter
  • Facebook