Building Apps For Internal Use
Hi, it’s Arek! Welcome to Fundament, a newsletter that enables growth in UX and product design. Not subscribed yet? Join for free now:
Many designers dream of working at big tech and serving huge user bases. Meta, Apple, and Microsoft, to name a few, are the companies that build products for millions of users and attract us. However, these are not the only choices if we want to thrive and be satisfied by doing fascinating things.
Applications used internally by a few users can also provide professional satisfaction. For the past two years, I’ve worked on a natural catastrophe analysis platform used by an internal team of flood analysts at ICEYE. This project has a truly small user base—when I joined, it was less than 10, and through the years, the number has grown to a substantial…40 people.
Despite that, the work is really fascinating, and I wake up every morning pumped.
I know it’s the Space industry, so it can’t be boring, but I still believe that a huge share of internal projects isn’t boring, either. It depends on how we tackle these projects and whether we want to bring value to our users.
This article is a follow-up to the talk I gave a few weeks ago at Infoshare ‘24 in Gdańsk. I was presenting our internal platform and discussing the differences between working for an internal user base versus client-facing apps.
How different can it be, you might ask. Let’s find out together.
User research
Researchers reading this, please don’t throw rocks at me for what I will write next, but I think that a full-time UX Researcher in many internal projects might be an overkill.
Why?
Access to the users is more direct and frequent. You basically know them by name—in some cases, even all of them. Whenever you do a discovery exercise, you don’t have to plan the budget, recruit participants, and prepare an extensive report after the research.
For simple things, just go to their desks and ask (or call them on Zoom). There’s no need to prepare a scenario for an in-depth interview or to create a few-foot-long questionnaire. If you need more depth, for example, when your team picks up a new and complex feature, you can introduce more structure, create a plan, and conduct interviews.
Usability studies can also be done faster and in a less official manner. For small changes, simply show a piece of the user interface and ask what people think. For more complex user flows, prepare a prototype and invite some of your users to test it properly.
These are the pros of such a setting: research is faster and less expensive, but it’s not ideal.
Here’s the most crazy pickle.
Because you know your users and vice versa, everybody is biased. They will not be 100% honest in the conversations about your work. The fact that you have some relationship with these people will influence your job. They might be easier on you and not give you the most honest feedback you’d get from anonymous users who don’t care that much about who’s on the other side. Keep that in mind.
Metrics
Business metrics can not be called the most important set of metrics in internal products. The focus should rather be on usability and performance. The main reason for this is that, in most cases, it’s extremely difficult to bond revenue with internal tools. There might be money flowing in thanks to such tools, but they are not sold to customers directly, so the revenue share is vague.
It doesn’t mean that you should ignore business and product metrics. Knowing how satisfied users are is a good idea. Use the CSAT metric to learn if they like the tool they use.
Tracking UX metrics such as Customer Effort Score, Error rate, or Time spent on task might be worth tracking to identify any usability issues. However, if the user base is really small and there are no immediate plans for scaling it up, don’t bother yourself with too many metrics. Talking to the users about the tool usage on a regular basis and setting up a place for reporting issues will do the trick. It could be a Slack channel, Jira board, Hotjar addon, or a Google form. Pick whatever fits your product best.
Prioritization
We already established that working for internal users makes user research somewhat less complicated, and the focus on metrics is slightly shifted.
What about the prioritization piece?
The fact that we know our users doesn’t make it particularly easy. In fact, it has a negative impact.
Different people might have similar needs, but they will never fully align. Because you have some relationship with them, you want to bring joy to all of them. Sometimes, this won’t be possible because of the conflict of interest concerning some small details.
When it comes to resource allocation, the projects bringing revenue in a much clearer way will have a louder voice at the table and can end up shortening the staff in internal teams. And that’s something that not much can be done about. Until the projects present start influencing the revenue (positively, of course), the conversations about money and priorities will be difficult.
To not end this article with a rather sad note, I’ll add one positive flavor: product discovery. Thanks to the fact your users are really approachable, and they are, in a way, forced to use your app and won’t delete their accounts and cancel their subscriptions when you screw something up, you are open for experimenting as nobody else in B2C will ever be. Try to fail, and try to fail fast. Make short experiments and roll out the changes often. Even if you slow the work down for some time, you will return with a better working piece of software that your users will enjoy using.