Removing the Dread from Internal Enterprise Systems

How to design internal tools that your employees love to use, developers love to build, and customers will notice

When you think ‘internal enterprise software’, what first pops into your mind? When you think of using your company’s internal tools, what’s your initial reaction?

Typically, thinking of internal enterprise tools, especially those used to manage internal processes, transactions, and issue tracking, gives us software PTSD. We dread having to use ‘that program’ which was created 7 years ago by someone who left 5 years ago.

So, what is fundamentally wrong with traditional internal tooling?

Fundamental Problems

Let’s take a look at the 7 fundamental problems found in many legacy internal tools:

Lack of Vision — The business demands from 10 years ago are substantially different from the demands of today. The original developers could not predict the future deviation in scope.

Lack of Process — The ‘just get it done’ attitude, typically a necessity at the time, means that the system was designed to deliver core functionality as fast as possible. However, it also means that traditional usability heuristics, scalability, and design architecture were not duly considered.

Lack of Empathy — Employees have to use the software no matter what, so there’s typically a disconnect in empathy between those who build the software and those who have to use it. When’s the last time you’ve heard of an NPS survey for an internal tool?

Lack of Ownership — The person who built the system years ago is likely gone and the system was unenthusiastically passed onto someone else.

Neglect — The system is meant to run and perform tasks, nothing more and nothing less. As long as something seems to be functioning, no proactive improvements or performance optimizations are made.

Rigidity — The system was built to do X, Y, Z, and that is all. Anything additional is appended to the original stack. It is easier to add than it is to modify existing components.

Legacy Stack — These systems are typically written in deprecated languages (like Java 1.4 or legacy PHP), which modern devs hate.

Consequences of a Painful User Experience

Poorly designed internal tools negatively impact your business and operations. Often, these pain points are latent because employees just ‘deal with it’ (there is no other option). The pain becomes normalized, which exponentially compounds the negative impact on productivity and happiness.

Platform Instability — The system will not be performant. It will crash. There will be danger zones to avoid and a save button that brings down the entire system. Simple queries will require minutes, which makes the employee move on to a new task or get distracted with someone else. Tasks take longer with higher risk.

Deviation from Scope — The functionality of 5 years ago is likely much different than the business demands of today. No one wanted to maintain or take ownership of the system, so all new functionality has been appended with the deprecated stack at the core.

High Maintenance Costs — There’s nothing developers despise more than maintaining and building on top of a legacy stack, especially when there’s little to no documentation or guidance. You will need to throw many engineers and weeks (maybe months) to even make a dent.

Decreased Productivity and Morale — Employees will dread using the system. In fact, it will become the bane of their existence. This will make them unhappy and it will take them 5x as long to complete a simple task. This sucks the joy right out of the day and increases the rate of attrition.

Increased Employee Error — A poorly designed user experience exponentially increases the amount of human error. Employees will keep making mistakes (which are not entirely their fault). This will introduce bad data into the system, piss off your customers, and force employees to redo their tasks.

Degraded Customer Experience — While your customers may not use your internal tools directly, they will indirectly benefit from efficient operations. If your company is slow, manual, and can’t function efficiently, then your customers will share that pain.

Building Joyful Internal Enterprise Tools

Yes, I did it. I used the words “joyful”, “internal”, and “enterprise” in the same sentence. Before you call this ‘crazy’, let’s examine how to build a joyful internal enterprise tool. Here are the 5 tenets of building an internal enterprise tool that employees will love and want to use, and that your engineers will take pleasure in maintaining.

1. Treat your employees as customers and your engineers as people

Happy customers are more likely to want to use your product — happy employees are more likely to want to use your internal tool. Productive and happy engineers take pride in the system they are building. So, empathize with your stakeholders and make sure that you build a user-centered tool that treats your stakeholders as valuable customers and aspires to bring joy to their days.

2. Use an actual design process to research, plan, and iterate

Throwing resources at a tool to get it done may get an MVP out faster, but even in the medium-run, the gross inefficiencies and lackluster experience will cost your company exponentially more in lost productivity. Use a PM or a designer to gather feedback from the stakeholders. Identify use cases, common tasks, and get to know the end-users. Sketch, wireframe, and prototype a scalable tool with the expectation that things will change in the future.

3. Get user feedback, establish productivity and performance benchmarks

Your tool should be increasing productivity and helping your company’s bottom line, not hurting it. Identify objective and quantitative ways to measure how the tool is performing over time. Is it stable? Are end-users happy? If not, iterate and fix it before things snowball out of control.

4. Assign ownership

There should be two owners of the internal tool: one non-technical and one technical. The non-technical owner speaks on behalf of the end-user. He or she will serve as the point of contact for all complaints and suggestions. On the other hand, the technical owner will take ownership of overseeing maintenance and continued expansion of the system. These two owners work together and hold each other accountable for the viability of the platform.

5. Make it fun to maintain

Working on an internal tool should not be a punishment. Imagine going to work as an engineer with your end-users sitting around you loving the system you build and maintain? The foundation for an easily maintainable product, and one that is fun to build, is that the design is elegant, scalable, and has a clear vision. It also needs to be something that all stakeholders are proud of, whether they are using it or building it.

All in all

Your customers may not know what your internal tools are or why you use them, but they will know a company that is run well from one that is not. They will know happy employees from those who are not. And, they will use your speed and efficiency to gauge the efficacy of your support and the integrity of your platform.

Treat internal tools like you would your core product. Empathize, design, iterate, … profit!

— —

Original article on The Tech Ladder

Want to keep in touch? Add me on LinkedIn