Most user research in the last decade has focused on the external users of a website. These external users are your potential customers. More specifically, the target audience that a website is meant to entice to become customers.
User research is used to help identify your target audience, but beyond that, it can also help you prioritize your target audience if you have different audiences you are trying to target.
For example, the target audience for a university could be alumni, students, parents of students, faculty, and much more. If you don't prioritize, you risk everything becoming a jumbled mess. You try and do everything for everybody.
This can manifest as dumping every piece of information out there "just in case" with no sense of what is most important. Or worse: everyone fighting over how the organization prioritizes information. Users have to lean on a search function that probably doesn't work very well. No one can find anything. No one is happy.
Most organizations understand the importance of user research for their external users, and it's easy to understand why. Proper research can lead to insights that directly improve the bottom line.
But what about internal users?
Internal users of a website
At the most basic, the internal users of your site are your site editors and content creators. Their opinions are at risk of being minimized or ignored.
These internal users are the people who create the content for your external users. They make the website worth visiting in the first place. But if the needs of these users are not met, your entire project can be put in jeopardy. If they find things hard to manage, your external users will eventually suffer.
Maybe they can't place images exactly where they want. Or maybe editing the metadata of an article is laborious. They could be unhappy with something as simple as the placement of bylines.
A big reason for organizations getting disillusioned with their content management system is that these problems finally bubble up and become something that can no longer be ignored. This is a big problem, but this is the most basic manifestation of it.
What if your organization is large and decentralized? It might be what we call an archipelago, a word we borrow to refer to an organization made up of many subsidiaries under a central governing authority. If this describes you, as it describes many universities, state governments, and sports leagues, then your internal users form a larger group. And how you involve them can make or break your project.
For a university, their internal users will be various schools, departments, deans, and many more. There is no single group of site editors—more opportunity for clashes and disagreements. Not only can you fall into the trap of not prioritizing needs properly, like with external users, but if you try to prioritize, you risk alienating members of your organization.
The solution many archipelagoes settle on is just to give everyone HTML access and hope for the best. This helps you avoid initial political problems, but it leads to an unmaintainable mess with zero chance of standardization or content re-use.
Part of the solution is to research your internal users with as much vigor and urgency as you do your external users.
Treat your internal users like customers, too.
Internal user personas
User personas are typically used to focus on solutions for customers, but you can use them effectively for your internal users.
For example, the State of Georgia created very detailed user personas for their agency users, dividing them into the six most common personalities and laying out a variety of information that defines them. Each persona included their motivations, frustrations, common software, goals, and much more. They also defined common "verticals" for their agencies, such as Elected Officials and Law Enforcement.
Just like with your customers, having personas allows you to take a very broad base of people and narrow it down to the groups you need to focus on. It also allows you to spot commonalities.
So develop some personas. Additional help for creating some can be found at Nielsen Norman Group.
Now, as you talk to users about their use cases and pain points, you can make sure you get a good representation for each persona. You are more likely to include the full range of use cases for your internal users.
Dig for the "why"
As you interview your internal users, you will hear a lot of complaining. You'll also get lists and catalogs of needs. Before you act on this giant pile of information, you need to dig for the "why."
What motivates their use cases? What are they actually trying to accomplish when they hit roadblocks? Often, the obvious issue isn't the actual issue.
Example
On one project, everyone wanted us to address design issues. They complained about not having access to something, or they needed to move a photo here, or make it bigger there, or control the output for a call-to-action.
Many of these needs contradicted one another. There was no consensus other than everyone wanting some variation of "just give me HTML access."
We asked two questions to get to the root of the problem and try to find a solution that everyone could accept.
- Why did they need this specific design control?
- What was the driver or business goal behind it?
Internal politics or directives from those in authority might be common reasons for these requirements, but that was not the case here. As it turned out, there were no specific design goals. They also were not trying to fulfill specific requests. They didn't actually need to place a specific photo in a specific place.
The main driver, the "why": they just wanted to "break up the wall of text." They thought their pages were "boring" and looked "dated." The more we researched, the more this specific complaint popped up.
With the problem identified, we could now design a solution and validate it with acceptance testing.
Ask five times
When doing user research, don't take what people say at face value. This adage is true: you need to ask why five times before getting to the heart of a problem. It's easy just to do what you're told, but you won't be serving your users very well.
When you understand users' motivations, you can design for them, and if you can design for them, you have a way better chance of keeping them happy.
There is no shortcut to this—just a lot of conversations.
Frame your conversations around the desire to make their life easier. Nobody likes being delivered solutions that someone else created, and which were created without taking into account their expertise and requirements. If you are truly listening to them, people will generally be responsive to the work you are doing.
For additional questions, check out our article on discovering your root design and strategy problems.
Finding champions
Once you start doing user research for internal users, you'll start to identify people who are just as interested in making working solutions as you are. These are people who are willing to be champions for your cause.
Hold onto them. They will become your eyes, ears, and voice within the various branches of your organization. They will be able to spot problems or elicit criticism to which you are not privy.
These champions are more likely to be trusted by their peers, and so as you identify and elevate them, you elevate the voices of the internal users they are championing. Their motivations might not align with your own precisely, but that's fine. In this case, the common goal is what matters.
For example, you may want the website to be 100% accessible because you believe it's a human right. Your champion might want the website to be 100% accessible because they don't want to be sued.
Roll with it.
Conclusion
By taking the user research tactics normally used for external users and applying them to internal users, you have a better chance at having a successful project. If you focus on the "why" of their needs, you can start to put together commonalities and gain real insights. Once you find champions, this job becomes a little easier.
It can be difficult to think of your internal users as customers. Because of that, user research early in a project is a perfect thing to hire an agency like Lullabot for. A third party has no problem treating your internal users as customers…because that's exactly what they are.
For a fuller treatment of research and building bridges in a large, decentralized organization, download our ebook All Carrot, No Stick: Maintaining Consistent Web Standards in a Decentralized Organization.