Subject Matter Experts (also known as SMEs) can deliver great insight into how users work and what designs would be best for them. Unfortunately, we often don’t use them to their fullest.

There’s a way to make SMEs highly valuable. However, it’s not the way most teams do it.

Experts with Narrow Expertise

Most subject matter experts come to this role because they’ve done the users’ job themselves, often for a long time. They have deep knowledge and experience about how the job gets done and how best to accomplish it.

This knowledge and experience often far outweighs the rest of the team’s direct knowledge and experience of the work. Delivering that deep expertise is beneficial, for sure.

While we bring SMEs into our project team because of their expertise, it’s that expertise that creates a problem. Though they have deep knowledge and expertise, they don’t know everything there is to know about every user and all of their needs. Their expertise only covers the experience they had when they did that job.

Even with that limitation, they still know much more than the rest of the team, none of whom have ever done the job users do. But they don’t know everything.

When we give someone the title of Subject Matter Expert, it’s the word expert that lingers in the air. We’re putting a lot of burden on SMEs. Most of the time, they no longer do the user’s job, and haven’t for a while. Even when they are, it’s only one perspective for what’s often a very complex job with lots of variations. The SMEs’ ability to provide well-rounded expertise frequently falls short from the very first day.

If a team member, senior executive, or other stakeholder had a job like the users at some point in their career, they often become an unofficial SME on the team. They behave similarly to the official SMEs, in that they advocate design decisions from the perspective of their own previous experience. And they create the same problems for the team as official SMEs do.

User Advocate is Everyone’s Job

For many teams, their resident SME is the closest they’ve ever gotten to a real user. Many of these teams appoint their SMEs to the role of user advocate.

It makes sense, because the SMEs should understand what their users are trying to do and the frustrations that come from having poor tools to do it. Yet, once we call someone a user advocate, we’re implying that everyone else on the team is not advocating for the user. Any contrary opinions or data that disagrees with the advocate could be seen as not serving the user.

In great teams, everyone plays the role of user advocate. Everyone needs to make decisions that benefit the user. We don’t want our team to have some user advocates and others who aren’t advocating for the user.

Design Decisions Based On Our Own Experience

For many teams, SMEs become the arbiter of design decisions. “Based on your experience doing this job, do you think this makes the design better?”

When put into this position, the SME does what any of us would do: provide the best answer they can. But they usually don’t answer with “Well, I know what may have worked for me back when I was doing that work, but it may not work for today’s users the same way.” Instead, they give a solid opinion, the way anyone with the title of expert would.

In essence, they are making a design decision based on their own experience. And we have a name for when we make design decisions based on our own experiences doing the tasks. We call it Self Design.

Self design can be a good thing. Many excellent products have come out of self design work. One notable example is the iPhone. The team at Apple didn’t do a lot of external research into what users needed. Instead, they built a phone based on what they themselves wanted to use. They designed the iPhone based on their own experiences using the technology of the day.

The Two Criteria for Effective Self Design

For self design to be an effective decision making strategy, the person making the decision has to meet two criteria. This is is where the self-designing SMEs run into trouble, as they often don’t meet either criteria.

The first criteria for effective self design is the designer needs to use the product or service. They need to use it every day, for the tasks it’s intended for (and not just for demos or testing purposes). As they were designing the new phones, the iPhone team used their phones every day. When the product or service is frustrating, the designer encounters that frustration first hand, and is highly motivated to improve the design.

Most SMEs come to be part of the team because they are no longer doing the job. In some cases, it’s been quite a while since they ever did the work. They have no need for the product or service, and therefore won’t use it every day. And, since they won’t be using it, it’s unlikely they’ll experience any new frustrations the new design introduces.

The second criteria for effective self design is that the target audience has to be just like the designers. Apple knows that not everybody is like them. They don’t believe they’ll make everyone happy with their designs. They count on there being a big enough audience of people who are just like the designers and will be happy with what they produce.

Most teams, whether they have SMEs or not, are not blessed with a target audience just like them. That’s why those teams resort to other active forms of user research to understand what our users need in the product. This doesn’t count towards meeting the second criteria.

By asking SMEs to use a self-design approach to making design decisions, we’re likely setting them up for failure. If the team is gathering any other research, that research will likely be at odds with the SMEs’ suggestions. That conflict creates tension and frustration within the team.

Shifting the SME from Advocate to Guide

We’ve found there’s a more effective way to get rich value from our teams’ SMEs. Instead of using their expertise to make decisions, we’ve asked them to play the role of project’s cultural guide and translator.

In this new role, the SME helps us reach better insights from our user research observations and findings. They point out things we wouldn’t otherwise see. And they ask questions we wouldn’t know to ask.

We take the SME with us on field research. They observe the people who currently do the jobs of our users. They compare what they’re seeing to their own experience of doing the work.

The SMEs can identify important tasks and contextual details that are easily missed by other observers. They can translate local jargon and semantics into terminology the team can understand.

When the SME encounters differences with how they used to do the same tasks, they can ask those users questions to explore why those differences might exist. Is it just a preference thing or are their situational factors that call for the work to be done differently? They’ll know to ask questions that the team would otherwise miss.

When a team watches a user (or potential user), they are seeing the users’ tasks through those users’ eyes. When they have an SME acting as guide, they now can also see those same tasks through the SME’s eyes. The differences are often insightful for the SME and the other team members. This gives them an added advantage and more rich, nuanced information.

Reframing the SME to Increase Their Value

The difference between the SME as advocate and the SME as guide and translator is just a perspective shift. We’re still taking advantage of the SME’s experience and knowledge. We’re just no longer asking them to resolve our design decisions directly.

Instead, we’re inviting them to be part of the larger team, and exploring the richness of the user journey with us. They can apply their knowledge and expertise to that exploration, while not feeling the pressure of always having to know everything. It’s a win-win for both the SME and the team, leading to a more collaborative outcome.