Design Thinking Will Fix Your Next Internal Software Solution

What is Internal Software and Why is it Different

Internal Software is not customer-facing. Whether purchased, built, or hacked together in spreadsheets. They are internal systems that streamline organization processes.

Internal Software is developed to improve the organization’s productivity. These systems are uniquely tailored to the organisation’s business processes. As the volume of Internal Software grows, these systems start dictating which processes are possible and which aren’t; each process’s design update causes development and changes to IT systems or low-code/no-code algorithms.

IT Business Analysts working on internal corporate applications face a unique set of challenges. You’re not building the next great consumer app; you’re building the new expense reporting tool, the HR onboarding portal, or the inventory management dashboard that Karen from Accounting will curse at every Monday morning.

Unique Challenges of Internal Software Development

Internal projects fail at alarming rates because nobody wanted them in the first place. When your users are captive employees, they can’t switch to a competitor, they just suffer, complain, and find workarounds that defeat the entire purpose of the system.

Oftentimes, your Book of Work will feature tasks set last year that have lost any business value by the moment you developed the requirements. Alternatively, you may be simplifying a workflow that costs your employees 5 minutes a day with a $100 000 development project. Does that math actually hold up, or did we just want to build something?

End users have to use the tool they are presented with, so their feedback is often silence followed by rage and escalation. End Users won’t bother pushing back during discovery because they’ve learned that IT projects take months and asking for changes is pointless. Then, come launch day, the complaints flood in as urgent tickets and CC’ed executives, because now the tool is disrupting the workaround processes the staff silently perfected.

Project sponsors are often wrong when they think they know exactly what frontline staff needs. No one runs A/B tests or consumer studies for internal apps. Neither teams test prototypes with the end users before the development begins.

The real way end users get work done is usually hidden, involving sticky notes, Excel macros, workarounds, and whispered conversations. No procedure or system manual ever captured the full truth. Walk through any cubicle office and you’ll see yellowed sticky notes, cryptic spreadsheet cells color-coded in ways only the author understands, Excel macros shared over mail, and hushed conversations where someone admits, “I just call Dave in support. He bypasses the whole system for me.” These are symptoms of systems that don’t fit reality.

Workers build workarounds because the official process is too slow, too clunky, or missing a critical step. However, the end users will never volunteer this information in a requirement meeting. They’ve invested months perfecting these coping mechanisms. Admitting them is often volunteering for extra work when the new system comes. Until you shadow someone long enough to see the sticky note, you’re designing for a fantasy.

No employee lies awake dreaming of a better vacation management system. Users just want it to be over. Internal tools are chores. End users don’t have a vision for the perfect timesheet app, nor they are emotionally invested with the product. They have a Tuesday afternoon and a calendar full of meetings, and your project is just another item on it. This indifference masquerades as agreement. When you ask, “Does this workflow make sense?” and they shrug and say “Sure, whatever works,” End Users are not validating your design, they’re conserving energy for real work and KPIs, for family and hobbies. End Users will only engage when the new tool makes their already-unpleasant task even harder. Then, suddenly, you have their attention.

Because of that, BAs have to manufacture engagement through observation, not questions. BAs usually cannot rely on enthusiastic participation from internal users. You have to watch what they do, not listen to what they say, because what they say is usually just a polite version of “Just get this over with so I can get back to work.”

These dynamics create a perfect environment for project failure.

Root Causes Design Thinking Solves

Design Thinking starts with Empathy that helps “touch the grass” and solve pains of the end users. In internal projects, requirements often cascade down from leadership. A director attends a conference, hears about “Reference Data Management,” and suddenly you’re linking data from all across the organisation. The problem? The customer complaints manager just needs to record a new process without entering data into three systems.

For an IT BA, it means leaving his desk and interacting with End Users. Go to the warehouse floor. Sit next to the Branch employee. Watch them navigate the existing system. Ask them to show you the “stupid things” they have to do. With Benchmarking, you’re catching the gap between executive perception and operational reality before it gets coded.

Everyone in Internal teams thinks they understand the process which leads to obvious requirements implemented completely wrong. This leads to requirements like “streamline the approval flow” phrases that mean ten different things to ten different people.

For an IT BA, it means prototyping early to expose hidden assumptions. A wireframe of that “simple approval flow” might prompt Karen to say, “Wait, I don’t approve that. I just review it before my boss signs. That’s completely different.” That clarification, caught on a whiteboard instead of in User Acceptance Testing, saves weeks of development.

Users reject the final product if it disrupts their real workflow. Internal users build elaborate systems to handle the flaws in current processes. When you drop a new tool on them that breaks workflows instead of streamlining existing workflows, they rebel either passively, by ignoring the system, or actively, by feeding bad data into it.

For an IT BA, it means iterative testing of prototypes with End Users doing their actual jobs to reveal friction points.  Watch a user try to complete their real task with your prototype. If they instinctively reach for a OneNote or a sticky note to remember a piece of information your screen doesn’t display, you’ve just identified a missing feature. Iterate the prototype, test again, and you ship a tool that fits the workflow, not fights it.

Internal projects are notorious for scope creep because stakeholders feel entitled to add “just one more field” or “a small report.” When requirements are buried in a document, it’s hard to push back.

For an IT BA, it means visualising requirements with visual prototypes to act as a contract and a boundary. When a stakeholder suggests adding a new data visualization, you can point to the prototype and ask, “What should we remove to make space for this? The approval button, or the search function?” The prototype makes trade-offs visible and forces prioritization conversations that documents never do.

Internal Software Development often operates under a mandate to build systems without thinking about problems it solves. This thinking assumes that once the system is in place, End Users will have no choice, but to adopt it.

For an IT BA, it means articulating a problem statement grounded in user problems. Instead of “We need to modernize the time-off request system,” you might define: “Frontline managers need to approve time-off requests in under two minutes while standing in a branch floor without access to a computer.” That definition fundamentally changes the solution, maybe it’s a mobile-optimized form with one-click approval, not a full HR portal.

The Bottom Line

To sum up, here’s how Design Thinking works in practice for a typical internal software project, like replacing an outdated IT asset management system.

1. Empathize. Shadow the IT admin who currently tracks laptops in a spreadsheet. Notice they have color-coded rows and handwritten notes in the margins. Ask what those mean. (Answer: Red means “user quit, laptop not returned.” That’s a data point no one thought to include.)
2. Define the Problem. “The IT team needs to know, at a glance, which devices are at risk of being lost when employees depart, so they can trigger retrieval workflows immediately.”
3. Ideate. Brainstorm with the IT team. Ideas range from a Slackbot reminder to integration with HR’s termination feed. Capture them all.
4. Prototype. Sketch three dashboard concepts on paper. One includes a “high-risk assets” list. Show it to the IT admin.
5. Test by the End Users. The admin points to the sketch. “This is great, but I also need to see who requested a new laptop but hasn’t picked it up yet. That’s a different problem.” Back to the prototype.

This cycle is fast, cheap, and brutally effective at surfacing truth.

For IT BAs, Design Thinking makes your solutions more accurate to the problem at hand. In the world of Internal Corporate Applications, where users have no choice and stakeholders have strong opinions, the biggest risk is building something that misses the mark.

You already know how to deliver a project on time. Design Thinking is how you deliver a solution that makes Karen’s Monday morning slightly less terrible. That is your job as a BA. Everything else is just documentation.