How to Develop Custom Business Software That Employees Will Use
Introduction
In this article, I discuss what I believe to be the key factors to consider when developing custom business software that employees will use. I’ll accompany the factors with a personal story that will help guide us through each factor.
Finally, I’ll suggest a common practice to invoke when dealing with uncertainty in large projects. By the end, I hope to leave you with the confidence to design, develop, and ship software that becomes a staple for your organization.
Know Your Audience
In my previous line of work, we had software we could not use. It was made for people that could be at a computer thirty-five hours a week. That did not fit a golf shop. Additionally, the user interface was intolerable. We had neither the time nor the willingness to learn how to use it. My boss received calls about the software from other people in the industry and actively discouraged them from purchasing it. Unfortunately, we were at the mercy of our organization and were stuck.
Everyone in the golf shop was a capable employee. We all had a college degree. Still, we declined to make the software work.
I picked up on one of the complaints that I heard often, the software wasn’t ‘intuitive’. It was clear that they were referring to creating an intuitive user-interface, which is our first factor.
Take Cues from the Big Guys
I’ve had a cell-phone in my pocket since middle school. That was replaced by a smartphone in high school. My peers and I use software applications that are developed by some of the smartest engineers and designers in the world.
When I navigate to a website or download a mobile app, I implicitly compare it to Amazon, Facebook, Quickbooks, Google’s G Suite, etc. I naturally expect my user experience to be on par with the big guys.
Your employees or colleagues probably feel the same. You should take note of the applications that they are familiar with using, like Google products, Microsoft, Apple, Facebook, etc, and emulate them.
What we want is to lower the just-noticeable-difference. How big is this change going to look compared to what they are using now?
Growing up, it was common for younger people in the household to be the most tech-savvy. They could “fix” broken applications or devices that their parents struggled with. This wasn’t due to their extraordinary IQs! It was because they regularly interacted with interfaces and products that share common patterns for using, troubleshooting, and configuring. This gave them the confidence to “figure it out”.
In the golf shop that season, we had also started using brand new tournament software. The tournament software’s user interface was friendly and the customer service was quick. Daily, the comparison between the accounting software and the new tournament management software was bemoaned, “Why can’t the accounting software be more like the tournament software?!”
I thought that—maybe—my co-workers just hadn’t put in enough focused effort to give the accounting software a chance. Despite their warnings, I decided to give the accounting software one last shot.
Last Chance
I downloaded the manuals, talked to customer service, and dug into the despised software. I began to see what each module did. I gave it a valiant effort, but could quickly see the fit was not right. After one month I abandoned the project.
I no longer saw the point of continuing. Other people—somewhere—have learned how to use this software, but I couldn’t throw any more time at it. Especially, since it wasn’t yielding any results.What happened to every employee that tried to use the software was that they lost the will to continue learning. The advantages of continuing, perceived or real, were no longer enough: software needs to be advantageous to learn. This is factor number two.
Be Advantageous to Learn
It was a last ditch effort for me to try and use the software. Others had tried, but lost the will to persevere through the learning process. They didn’t see a reward for putting in more effort.
I haven’t created an analysis for judging whether software is advantageous to learn or not. Only a series of questions:
Will organizations gain a competitive advantage by using the software?
Will users within the organization gain a time or effort advantage using the software?
Will the users agree with your answer in question 2?
If yes, then you have succeeded.
If no, then there are a few more questions:
Is it too difficult to learn?
What’s going to be our proof of concept moment?
Do we need to do more research?
The goal is to reduce the perceived switching costs. For example, you’re likely to expend more effort on a hike that you know has a view than a hike that looks at a wall of trees. The small issues in the foreground are overshadowed by the grand vista.
So far, we’ve discussed the first two factors:
Does the user-interface follow common design patterns?
Is the software advantageous to learn?
Let’s return to the story to reveal the final factor.
Software Resolution
Four months later, I called my boss and said I had the solution. I could automatically pull invoice PDF files from supplier emails and get them into a Google Sheet.
Then, I could use the Google Script Editor (Javascript) to sort, move, and manage invoices across various sheets. Allowing us to track invoices, billing, and accounts payable. The process combined new technology with existing technology that the shop was familiar with (Google Sheets).
What was his reaction? He immediately wanted to implement it based on my demonstration. Could anyone have pitched this idea to him and received the amount of enthusiasm that I did? Of course not. There was a final factor that allowed me to push the project over the finish line and into their hands. I had his trust so he was willing to buy-in.
Build Trust & Buy-in
The biggest advantage I had when creating and pitching the software solution to my golf shop was they trusted me. I knew them personally. I didn’t try to sell them a product. Also, I understood the problem intimately and then went out to find a solution.
During the discovery, design, or development process you will most likely be looking for some form of user stories from your employees. Those stories contain issues that may be the bane of their day-to-day workday. They are emotional about their struggles and what they need.
When you collect information from them you are exchanging trust. I’ll trust you with this information, if you promise to deliver on it. Viewing the collection of user stories as an exchange in trust is a better vantage point for developing. It’s also the third, and final factor.
However, even with these three factors there’s still more that can be done to increase your chances of success. In the next section, I’ll introduce a quick practical exercise to cap off my recommendations.
The Premortem
The Premortem is a popular managerial technique first introduced to me by Daniel Kahneman in his best-selling book, Thinking, Fast and Slow. However, he credits Gary Klein for the strategy.
The stated advantages are, overcoming groupthink and unleashing the imagination of knowledgeable individuals1. The prompt is stated:
Imagine that we are a year into the future. We implemented that plan as it now exists. The outcome was a disaster. Please take 5-10 minutes to write a brief history of that disaster.
Look at the project as a whole, and determine if there are concerns that relate to employee adoption and use (or misuse). You may need to modify the prompt to fit the scope of your issue. Then, make adjustments to software requirements or the user stories to combat the threats that you brainstormed.
Conclusion
In review, the three factors to consider are:
Follow common user-interface patterns
Be sure employees will see the advantages of learning the software
Build trust and buy-in with employees by involving them in the process.
And, before you begin to execute the plan, have others join you in ‘The Premortem’ exercise to help identify and avoid threats you may not have already considered.
We hope these tips help you improve your chances of user adoption and success with your next software development project. Feel free to contact us if you have any comments or stories to share!
Endnotes
1. Kahneman, D. (2011) Thinking, Fast and Slow. 8th edn. New York: Farrar, Straus and Giroux. ISBN: 978-0-374-53355-7, pg. 265