Removing the Dread from Internal Enterprise Systems
Removing the Dread from Internal Enterprise Systems
Typically, thinking of internal enterprise tools (especially those used to manage internal processes) gives us software PTSD. However, it does have to be this way.
Join the DZone community and get the full member experience.Join For Free
Don’t let inefficiencies in software testing lead to delayed deployments and poor quality products. Get the 90 Days to Better QA Guide by Rainforest QA for best practices to avoid these common pitfalls.
When you think about 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" that was created seven years ago by someone who left five years ago.
What is wrong with internal tooling?
Let's take a look at the seven fundamental problems plaguing the majority of internal tools.
1. Lack of Vision
"We just need this system to do XYZ, nothing more. Just make it work. It doesn't matter if things change in the future. We can cross that bridge when we get there."
2. Lack of Process
"Design process? Use-case research? No, thanks — just get it done. I'll assign it to some of our devs."
3. Lack of Empathy
"Oh, this tool is for our employees? Well... they have to use it no matter what, so too bad for them. Let's just get this thing out the door and functioning."
4. Lack of Ownership
"I built the thing, but I really don't want to maintain it. That's the next guy's problem. Commenting the code? Writing docs? How about no."
"Is it still kind of working? Oh, only 95% of it works still? 5% of the actions crash the entire system? Sounds like it's still working to me."
"This was built to do A, B, C and half of the variables are hard coded. You want to add X, Y, Z to it? Good luck. I'm not touching that. "
7. Legacy Stack
"Wait... this was written in Java 1.4?"
Consequences of a Painful User Experience
Poorly designed internal tools negatively impact your business and operations — even more so than you think.
The system will not be performant. It will crash. There will be danger zones to avoid and a save button that crashes the entire system.
Deviation From Scope
The functionality of five 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 love more than maintaining and building a legacy stack, especially when there's little to no documentation or guidance. You will need to throw a few engineers and many hours 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 five times as long to complete a simple task. This sucks the joy right out of their day and increases the rate of attrition.
Increased Employee Error
A terribly 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 five tenets of building an internal enterprise tool that employees will love and want to use and that your engineers won't mind 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 increase productivity and help your company's bottom line — not hurt 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.
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. 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, and profit!
Published at DZone with permission of Justin Baker , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.