To design great internal apps, you probably need to do more user research
How internal users do work isn’t always straightforward or simple.
As UX Designers, sometimes you may be tasked with designing internal applications. These can be complex, information-dense, and sometimes look like they came from a time when there was no such thing as GUIs.
As a result, your first reaction may be to try and find ways to simplify it. But that’s the wrong approach. The first thing you need to do before changing anything is get a deep understanding of your users, organization, and the contexts they work in. Because the way internal users work can be much different than the general public.
To understand why we first need to understand the difference between internal and external products.
Internal vs. external products
One of the first things that may come up when you get assigned to a project is if it’s an internal or external application. This is simply a way of talking about who a project is meant for.
Internal applications are meant for people within an organization or system, while external applications are usually meant for the public. This doesn’t seem like a big deal until you realize that your UX training was likely about external applications.
We’re taught in boot camps and classes about external-facing websites. It’s not that surprising: few companies want to leak internal website pages to people, and it’s significantly easier to understand and critique external-facing websites because you can understand the user. It’s usually a subset of the general public who wants to complete tasks on your website.
Internal applications are a different world entirely. Here are some of the main differences:
Accessible users: Since your users are other members of the organization, you can quickly and easily reach out to them for their input. Doing this is often a necessary step to understand the problem space.
Rules and Regulations: What you can and can’t do is often governed by a set of rules and regulations that the organization must follow (called governance). As a result, sometimes obvious solutions can’t be used, as it doesn’t follow specific required criteria.
Consistency is vital: Internal tools are usually part of a more prominent family of products, consisting of visual and spoken languages. Advocating to make changes to your product also often involves considering if it’s worth breaking from consistency across other products.
Streamline the best practice: We often want to support only one answer when addressing a problem. Rather than offering users choices, it’s usually better to direct users to avoid making errors.
Slow to change: As a result of many of these things, organizations are often slow to change. There may be pushback for what you might consider obvious actions to take because you may be going against what many users have trained on over the years.
Information Density: Internal tools tend to have high information density, as many of these systems are built for professionals who often use a non-linear workflow. The risk of hiding the wrong thing is sometimes so devastating that the risk isn’t worth the screen real estate saved.
Efficiently delivering value matters more than polished designs: Sometimes, applications are cobbled together from quick wins meant to offer immediate value to your users. While building features can be of great value, it’s also necessary to think about the overall picture.
These factors result in something that is usually information-dense and hard to understand at first glance.
It’s not a flawed assumption to believe that this must be overwhelming for a new user to learn. But trying to simplify this may make your user’s jobs much harder. To explain this, let’s talk about two types of expertise.
Interface vs. Business expertise
When we talk about a user being an expert, we often don’t clarify. There isn’t just one type of expertise: there are multiple. Let’s focus on two of these types:
Business expertise: This is a person’s knowledge in an area or a topic due to work experience, business training, or certification. To put it another way, this type of expertise establishes them as Subject Matter Experts (SME). It also includes the shared mental models on approaching their tasks and processes.
Interface expertise: A person’s knowledge of how an interface works due to habits when using it, training, or experience with similar interfaces. This is the ability to recognize familiar interaction patterns instead of stopping to analyze or recall from memory.
These two types of expertise are much different from one another, and some of you might have met people who are experts in one way but not another.
The most common example of this might be a doctor with two decades of experience in one field, but he doesn’t quite know how to create a PDF of a report he filled out. It’s imperative to understand both types of expertise as they can offer you a glance into where you should and can make improvements.
One of the most common problems you’ll run into with internal applications is that they’ll be near point #2. This is because enterprises were built with legacy systems, where businesses designed things with the system in mind, not the users. As a result, people with high business expertise were also assumed to have high interface expertise.So simplifying the interfaces is a good thing. But you don’t want to simplify it so much that our users can’t utilize additional business expertise.
Many of your users are what you might consider expert users in terms of business expertise: since they know what they want to do and will likely be working with the tool constantly. They may want features to make their jobs more efficient. These may include shortcuts, keyboard navigation, and personalization to complete tasks efficiently.
Simplifying an interface to the level of the general public may slow them down overall, and it’s often not necessary. So how do you balance a more simplified interface without making things less efficient for users?
How to design for internal users
Do a lot of user research, especially about workflow.
One of the best things about internal applications is that your users are other organization members. As a result, it can be easy to get a hold of and talk with your users to understand the current situation.
Spend the time to understand their current tools, how to organize their workspace, what frustrations they have, and what they’d like to improve. It’s great to get feedback on what you’re designing, but one thing that’s helped me immensely has been creating design artifacts that focus on user workflow.
These can range from journey maps to Hierarchical Task Analyses that can help break down the steps of a process.
This way, you’re laying out what you think the process’s steps (or workflow) are like, and they can correct you about it with something in front of you.
This is especially helpful with internal applications because there are often two versions of the workflow.
The first is the official workflow. This is what the business expects to happen, with each step nice and polished and moving in an orderly manner.
The second is what the user does, which can sometimes not follow that process.
If the organization expects to show information at a later screen, but the user wants it now, they’ll copy-paste it and put it into notepad (or take screenshots). Or they might bypass certain functions entirely.
These workflow tips are often the crux of what you want to improve with the interface (along with general usability issues). They’re a way to make sure that we can leverage business and interface expertise to create something that works for users.
Design with people, not for them
Understanding everything about a large and complex system is hard to tackle alone. This is where talking with your team, both formally and informally, can be incredibly useful.
It’s okay not to know everything: you’re not required to. But you should reach out to other people to unblock your flow, as well as learn more about what perspectives others can offer.
It may be hard to get people on the calendar for meetings at times, but having informal chats about what you might not understand is something that can be a great icebreaker.
In addition, you can go around and act almost like a suggestion box. By introducing myself as someone working to improve the next release, I often get a sense of what features would provide the most value to our users and what I can focus on to help our users.
In either case, working on internal products should mean an awareness that your users are easily accessible. So don’t be afraid to reach out.
Changes come gradually
Large interfaces take time to understand, make changes to, and implement. During this time, you may experience pushback, have to consider alternative approaches, and may otherwise face other difficulties. But that is part of what happens with internal products. Sometimes changes can come in a piecemeal fashion, as we provide value for users one part at a time. But that’s not to say that these changes won’t eventually happen.
As a result, you need to be patient and know that many of the more minor changes you may today make a more significant impact later on.
Designing for internal applications requires a greater understanding of users.
One of my favorite stories about internal applications came from a user test when I was still new.
We couldn’t understand why we got near a 0% response rate for one of our fields, and as a result, we decided to do user testing.
We noticed that many of our users tended to entirely skip over the field as well, even when the scenario explicitly hinted at using the field. For example, when we asked about how they would record a specific piece of information, some users went as far as opening up a Notepad application to record it and attach it rather than using a field.
But the response we got when we finally asked our users about a field was enlightening. Most of them didn’t even know what we were talking about at first, and when we pointed it out, we got an interesting quote.
“Oh, I didn’t even see that field. I look for red asterisks to fill out on a form.”
The way internal users think about and complete work may be based on training, organizational structure, or other factors that you may not be aware of. As a result, before you change anything, make sure you have a deep understanding of what the users need and how they work. That’s the quickest way to improve an internal application.
Kai Wong is a UX Specialist, Author, and Data Visualization advocate. His latest book, Data-Informed UX Design, talks about small changes that you can make to incorporate Data into your UX Design process to yield better user research, incorporate analytics, and provide more persuasive arguments to your team.