Inside the machine: UX research with internal users
In the past year I’ve been involved in multiple initiatives across different clients to tackle an often-neglected area: The software, systems and processes used by their own employees. While nominally similar to UX research on customers — we’re still seeking to discover needs and pain points, produce insightful findings and artifacts like personas or journey maps, and help prioritize improvement efforts — these internally-focused efforts have a number of wrinkles that can make them trickier.
Why now?
I don’t have a broad industry survey to go off of here, but I suspect the increased interest in this area is driven by a few factors:
With trimmer budgets and smaller staffs post-pandemic (due to the Great Resignation or mass layoffs in tech) companies realize they need to remove inefficiencies in their systems that get in the way of productivity
Larger companies are recognizing that they’ve accrued so many third-party solutions that tackle specific parts of processes, but which lack integration and which collectively require too much time and learning curve. Can they make employees productive more quickly, and save costs through SaaS streamlining?
Older tech companies in particular have built home-brew systems over the years, often doing so quickly and to satisfy a specific need and organizational context. Those systems are now creaking with age and are holding the current organization back.
The challenges of internal research
So what makes the UX research of these kinds of initiatives challenging? Here are some things I’ve found so far:
Are you solving the right problem? It’s a trope in IT that throwing technology at a problem can feel satisfying and concrete, but may not actually solve it. Why? Because what “presents” as a tech problem may actually be a problem of training, or organizational incentives, or some other “soft” or “invisible” factor. If those aren’t addressed, the new tech won’t make much of a dent. So part of a researchers job should also be to help the team make sure they’re solving the right problem.
Identifying the people to talk to in the relevant roles can be surprisingly difficult, especially for large orgs that are globally dispersed. Titles aren’t always consistent around the world within a company, and what someone does isn’t always aligned with their title.
You often need to recruit through intermediaries, such as stakeholders, managers or other gatekeepers. This adds extra time and effort. Sometimes the intermediaries are skeptical, especially if they want to protect reports who they see as time-pressed or mission-critical. So you need to get them on-board first.
Craft your pitch: To get people on-board, you need to get your pitch right. What’s their perspective on what the problem is to solve? What’s in it for them? What impact do you want to have? Why invest in this now? In other words, it’s just like selling a product to any customer, and you can’t take it for granted that they will see the same value that you do. Having said that, I find that once people are invested in the “why” to give feedback, they are usually eager to talk about how they do their job and what makes their work life more difficult than it should be — if they see you as a path to improving things.
There’s a tendency to be put in touch with star-performers. That’s great, except from them you’re going to get a skewed perspective, as they’re likely highly proficient users of the systems, and will have knowledge or work-arounds not available to new-hires or less expert users. To lift the performance of the larger team you need to get a broader view. You need to talk with people who are confused and who will “bumble around.”
Getting on people’s packed calendars is usually more difficult than scheduling with external customers that have been recruited, opted in, and are getting paid an incentive.
Over-fishing in a small pond: Some roles may have a small number of people that do them. You need to be mindful about not over-taxing them with repeated requests for (especially) interviews that are time-consuming. Prioritize what you really need user input on - are there other ways to get at the answer? What can you do through email, Slack, surveys or other asynchronous methods?
Qualitative research isn’t necessarily the answer: A common issue is that internal tools — whether built by the org itself or bought from third-party providers — often lack the type of usage analytics that we would assume to have available when building a customer product. Major SaaS platforms like Salesforce have some analytics available - though these may not give you the granularity you need to tease out specific usage questions. This robs you of the ability to do basic things like understand frequency of feature usage or navigation paths. If the tool in question was built internally, a prudent step would be to start adding these analytics based on what usage patterns you need to understand.
Do the circle-back: Before presenting findings to a broader group, check back in with some of the people you’ve interviewed. See if they agree with how you’ve analyzed the situation and captured their inputs accurately. This shows you’ve listened and gets them further bought-in, and gives a chance to catch any errors that could undermine the findings.
Manage the politics: Getting employees to critique software developed by colleagues, or that was paid for by their bosses, or that may expose their own lack of expertise or training, can be fraught with tensions. Employees can’t afford to be as self-servingly critical of a product as customers can. After all, customers are doing the paying, but employees are getting paid. On top of this, people in different roles or in different departments may have agendas that can be explicitly or implicitly at odds. This may mean you need to be more careful about anonymizing feedback to avoid concerns about backlash.
I’ve just scratched the surface here - each of these things is a big topic in itself. But if you’re embarking on this kind of effort to improve internal systems and processes, I hope this gives you some useful food for thought. And for those of you that have been doing this work, what are the lessons you’ve found? Get in touch, and let’s share stories!
