There are major advantages to building internal tools; software that’s only used by a specific team or a single company, and never gets seen by clients.
There are also risks.
Here’s one: An executive wants to make some arduous internal process more efficient. They have a clear vision of what they want, so they hire someone to build a tool. The tool gets built, and launched with great fanfare – and only then does the team learn anything about it.
To the executive’s shock, the team reacts with hostility and suspicion. “But this will make their jobs easier,” the executive thinks. “Why aren’t they praising me?”
The problem started, perhaps, with that clear vision.
As a designer, one person with a clear vision already sounds risky – the person holding the purse-strings is rarely the person doing the job that needs automating. Do they really understand the problem? Will their vision really solve it?
User interviews are the simplest tool for validating those assumptions. And when working with an internal team, you can literally interview every user, rather than just a representative sample.
Unfortunately, it’s not always easy to convince The Person With A Vision that the time and money conducting user interviews will be well spent. “I don’t need you to do discovery, I don’t need you to assess, I need you to build what I say!” And maybe they’re right! Maybe they do have a perfect understanding of the problem space, and maybe they’ve determined the perfect solution.
But there’s a more mercenary argument for doing user interviews even in that case: user interviews sell the tool.
People don’t like any change; but people hate unexpected change. Salaried workers assume all change will give them more work, not less. And in one way, they’re right: any change will always make them less efficient at first simply because re-learning a long-practiced skill isn’t easy. No new tool is going to feel like a big improvement on day one, because of the energy it takes to learn to use it.
A user interview is a great, sneaky way to make sure everyone knows what’s coming; gives everyone a chance to air their worries and grievances; to feel heard. It gets all that done early in the process, so it gives everyone time to get used to the idea of what’s coming. If you want the team to cheer when the new tool launches, then user interviews are worth the time even if you don’t get any new information at all.
Obviously, between you and me, of course you’re going to get new information. What does the executive really know about what their office manager does? But pitching the interviews as a way to socialize the executive’s brilliant vision is one more way to ensure they get done.
A postscript:
My instinct is that there’s an argument for the user-interview-as-sales-tool even for customer-facing software; I just don’t have the direct experience to back that up. It’s much easier to see the difference in the highly-limited pool of users of an internal tool.