You are ready to become more than a wireframe/mockup generator, or you are the first UX hire and are excited to bring the full benefit of UX to your company. However, you keep running into resistance in different forms from teammates and other stakeholders.

I see this question show 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 Work

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 a product 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.

What Are UX Deliverables? 24 Methods to Deliver Great UX

What Should Be in a Persona?

What Are the Components of a Service Blueprint?

A Guide to Mental Models

What Is an Experience Map?

What are the Customer Journey Stages?

Build UX Awareness With Stakeholders In Your Company

Strategy Stakeholders

Bring the Value

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 is to demonstrate the value UX delivers. At any size of company, there is always a balance happening around resource usage. Often the most valuable resource being time.

Sometimes you will need to find third party data to show value or do some smaller-scale tests to show the potential benefit. Gather some internal feedback to show evidence that there might be a problem that’s worth investigating.

UX Aides 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. 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 other mixed methods later. 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 questions your quant 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

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 to start:

Departmental Value

For Marketing departments, it is all about the funnel. User experience best practices can often decrease funnel friction for potential 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.

Product Teams

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

  • Too much focus on producing 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 and break platform conventions or are costly to implement.

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 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 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 help satisfy objections 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. 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.

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.

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 your playground. It also breaks down barriers when everyone owns the solution or felt like they contributed. If you have to extend a design sprint over weeks instead of the intense four days, to knock down concerns about the time, it is worth it.

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 that predicts project failure. 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