“Technology should meet my needs. If I have to change what I do to meet the needs of the technology, then it’s bad technology.”
– Ann Sowers
I start with this quote from my wife because I’ve heard her say it so many times. As a Special Education teacher, she used IEP management software to create educational plans for her students. Every few years the software would change and she would need to attend several days of ‘training’ on the new software. And every time she would come home and vent to her software-developer husband about all the ‘extra’ work she needs to do just to meet the needs of the software. Things like having to enter the exact same information into certain fields for every single student, or having to lookup specific codes to classify the student’s behavior, or having to scroll past pages of irrelevant fields just to get to the ones she needs. She needed to do this extra work to help the software, rather than the software doing extra work to help her.
When she changed jobs to work for our local city government, she thought her days of dealing with maddingly-complicated software were over. So she was disappointed to learn that ERP (Enterprise Resource Planning) software was even worse. Because when the city ‘upgraded’ to a new ERP product, she had to attend several weeks of ‘training’. And she came home every night with the same complaint; that she needed to so much ‘extra’ work (work that the city didn’t need or care about) just to get the software to operate correctly.
In both settings she asked her trainer and her boss why she needed to do all this extra work. And in both settings they told her, “That’s just the way it is with complicated software.” When she didn’t understand something, or struggled with a complicated workflow, she was made to feel like it was her fault for not trying hard enough, or for being ‘too old’.
And that’s because everyone in the decision-making chain (from the person who made the decision to buy the software, to the person who wrote the contract, to the developers who had to code it, to the managers who had to implement it, and to the trainers who had to teach it), all accepted one simple premise: “The more complicated the software’s task, the more complicated the software must be to use.”
Here’s how they saw it. If the software does one simple task (like, say, a calculator), then of course its interface will be simple to use. But if the software covers many types of data, whose structure can change depending on circumstances, and comes from many sources, and must be processed and presented in many different ways to many different users, then the software must, by necessity, be more difficult to use.
There’s just no way to make a giant ERP system, spanning hundreds of data tables, and thousands of potential outputs, be as simple to use as a calculator. Right?
And my wife is a perfect example of why that assumption is wrong.
My wife struggled with IEP software (containing dozens of data-tables), and ERP software (containing hundreds of data-tables). And yet my wife is really good at keeping up with her friends’ lives on Facebook and buying things on Amazon. Of course, this seems perfectly normal until you realize that both Facebook and Amazon are some of the most complicated pieces of software on the planet. These staggeringly-huge pieces of software probably span millions of data-tables each.
How is it possible that my wife can so easily interact with software spanning millions of data-tables, but still struggles with software that’s orders-of-magnitude smaller? It’s possible because everyone in the decision-making chain at both Facebook and Amazon understand that it doesn’t matter how complicated the software is on the back-end, it must be super-simple on the front-end.
These companies spend orders-of-magnitude more time, money, and effort on making their software friendly, then they do on simply making it work.
Because what’s the alternative? How long would Amazon stay in business if it had to spend weeks training every single user on how to place an order? How long would Facebook stay in business if it had to hire a huge tech-support department to constantly walk users through the ‘proper steps’ of posting a picture?
These companies realize one important truth: It’s easier and more cost-effective to 'train' the software then it is to 'train' the user! These companies train their software to meet the needs of the user, not the other way around.
Think about my wife’s experience. She spent weeks learning a new ERP. This means she spent weeks not doing her regular job that she was hired to do. That right there is a huge cost to the organization. Now multiply that by the number of people in those training sessions. Plus add the cost of the trainer(s), plus the additional time that managers had to spend scheduling, ‘encouraging’, and referee-ing, the training process. And that’s all before the go-live date.
Then once the software is live, there’s still a long learning curve (often a year or more) before the new software begins to feel ‘natural’. Then when a new staff member is hired, they must be trained by an existing staff member. Both an existing staff member and the new staff member are being paid, but are not performing ‘actual work’.
Then add to that the cost of ‘support’. These are people, both in-house, and from the software company, who help out when someone can’t get the software to do what they need it to do. ‘Support’ is a huge cost. And its not just a one-time cost. ‘Support’ must be provided year after year for the life of the software.
When all these ‘hard-costs’ of a new piece of software are added together, the actual cost of the system can be much higher than the ‘contract’ price.
But at least these additional expenses can be budgeted for.
What can’t be budgeted for are the ‘soft-costs’ of difficult software. And it's these costs that often end up sinking an organization. Here are some examples from real-life software implementations that I’ve personally witnessed. They cover 6 categories:
One piece of software I’m familiar with requires a user to click the mouse button a total of 30 different times to reach the information they need. Yet I’ve also seen well designed software deliver that same information in as few as 3 clicks. This is a dramatic difference. This means employees using the bad software are 10 times less efficient than they could be. Not due to any lack of training or experience, but solely due to the software they are forced to use.
And the information the user was trying to get? It's not some obscure tidbit that only needs to be retrieved once or twice each year. This piece of information (the one that takes 30 clicks to reach) was actually mission-critical and needed to be accessed multiple times each day.
With good software, this organization could run 10 times as many reports, or fill 10 times as many orders, or help 10 times as many stakeholders in the same amount of time. But because the organization chose the ‘cheapest’ software package, their employees simply can’t work that efficiently.
At this same organization, in order to build a particular spreadsheet, the user must string several different pieces of software together in a highly-convoluted process. The data is stored in one piece of software, extracted with a second piece of software, formatted with a third piece of software, and finally pasted into a fourth piece of software, where it can finally be used.
But even that is not the most egregious example. Because for a different set of data, there is no ‘second’ and ‘third’ piece of software to assist the users in extracting and formatting. In this case, employees spend days manually looking up individual pieces of data in the ERP, and building their own Excel sheets one cell at a time, just to compile a single report in a format they need. This ERP software that was supposed to make their life easier just couldn’t do the job.
I’ve seen enterprise software with extremely poor navigation and incomplete search abilities. Key pieces of information were buried under layers of abstract taxonomy. Because the software was so unhelpful, and because ‘training’ was so long ago, the effort required to ‘go digging’ for that information was too much. Users who are forced to work with this piece of software admitted to me that they often ‘just gave up’ looking for something, and moved on to an easier task. As a result, many opportunities to assist stakeholders were lost.
I’ve seen several administrative assistants in the same admin-pool spend hours looking for one piece of data that they know exists in the system somewhere, but (again) they don’t know how to access it. The first admin asked another admin, who spent time looking. When they couldn’t find it they asked another admin, until the whole pool was looking for this one piece of information and no one could find it. They ended up putting in a help ‘ticket’ and had to wait 2 days for a response.
But that’s not the amazing part. The amazing part was the response they received back. The folks in IT told them that this particular bit of information ‘wasn’t available’ to employees at the Administrative Assistant level. Not because it was proprietary, or confidential, or needed to be restricted in any way. They didn’t have access because no one thought someone at the admin level would ever need it. So someone in IT (who was being paid several times as much per hour as the admins), had to run the report and send them the data.
I visited this admin-pool several months later and asked how things were going. They told me that nothing has changed. They still didn’t have access to that piece of data because ‘IT had more important things to work on.'
Just as bad as not knowing how to reach a certain dataset, is not knowing that some insightful data even exists in the first place. Friendly software encourages exploring. It offers little hints of what’s possible. It shows examples of related data. It offers comprehensive search capabilities, and well organized, easy-to-read, and thorough menu systems.
Difficult software greatly discourages exploring. One piece of software I’m familiar with requires users to memorize dozens of codes (seemingly random strings of letters) in order to access its most important functions. These codes are holdovers from the 1980s when the software was run on DOS systems. Yes, that’s right. A navigation system developed back in the days of floppy disks and Oregon Trails is still being used for the daily operation of major organizations. Because no one thought it was important enough to update this system, many many opportunities are lost.
When I brought this to the attention of the IT department, I was told that users can now bookmark their most-often-used codes. But most users didn’t know this option even existed because it was not obvious in their regular workflow. And even if is was obvious, bookmarks don’t help users find new reports and functions that could make them more productive.
Here’s a hint: if the navigation system your software uses was developed before most of your employees were born, it might be time to upgrade.
This is probably the most detrimental soft-cost to an organization because it happens slowly, without anyone even realizing. It eats away at employee morale until the workplace turns unproductive and sometimes even toxic.
Think about the different types of people working in your organization. Some people, like Janice, are an absolute joy to work with. They always have a smile, are eager to help, and are overall a positive influence in the office. And other people, like Bob, can power through a difficult piece of software, using it to its fullest potential.
But ask yourself: how many people can do both? How many people are both great at using the software and super-friendly, helpful, and have a positive attitude? People who can do both are a rare find indeed.
When a difficult piece of software is introduced into a workplace, the positive and helpful employees will often struggle to ‘keep up’ with the technology. Their productivity drops. And sometimes they end up leaving the organization as a result. Those who remain tend to be the less positive and helpful employees, who are now made even crankier by having to deal with frustrating software.
So now the organization has to replace the departing worker. Do they look for someone who is friendly and helpful? Or do they look for someone who can use the software? The answer to that question can be found in just about any Help Wanted ad. Very few ads request someone who can boost morale and support others, while virtually all ads list a string of software skills that new employees are expected to have.
Online job sites (like Indeed) only amplify this problem. It’s difficult employers to include characteristics like agreeableness or helpfulness, and it’s difficult for these sites to measure these characteristics. But it’s easy for employers to name a piece of software. And if an applicant, who may otherwise be a perfect fit for your organization, didn’t specifically mention that piece of software, their application isn’t even forwarded along.
As ‘good’ employees are replaced by those who can ‘run the software’, the office culture slowly transforms. Soon it no longer fosters worker satisfaction. Soon employees are no longer ‘invested’ in the organization. Morale plummets, the workplace slowly turns sour, and stakeholders aren’t getting the support they need.
The organization becomes inefficient and ineffective.
If you’re not sure if your employees are working for the software instead of the software working for them, look around for ‘superusers’ in you organization. These are users who other employees turn to when they need help using the software. If you have them, then you have a problem.
As the software becomes more and more challenging, only a few employees will be able to fully ‘keep up’. They are given cool names like ‘superusers’, but often they’re anything but. Sure, they know the software really well. But like before, it is exceedingly rare to find someone with both exceptional technology skills and decent soft-skills like agreeableness, openness, and extroversion. Instead ‘superusers’ often express the exact opposite of these traits. Those who can ‘get things done’ often tend to be the least personable. And as they grow in power (and they do grow in power because everyone else must rely on them to get things accomplished), the entire organization suffers as a result. If your organization has superusers in its ranks, that right there should be a HUGE RED FLAG that something is seriously wrong, and that the software is definitely not doing the job it was created to do.
You probably don’t have to think too hard to find examples of these ‘soft costs’ playing out within your own organization. And I hope you now see that the source of these costs is often something as simple as poorly chosen and/or developed software. I really can’t overstate just how much a piece of software can affect an entire organization.
In many cases the right software can eliminate even the biggest roadblocks your organization faces. But that doesn’t happen the way most people think it does.
Many people conclude that if a piece of software ‘does the work’ faster and better than before, it automatically means the organization will see an improvement in efficiency and productivity. But most of the time, that’s simply not the case.
Think about this example. Let’s say you want your sales staff to be able to visit more locations around town. You know that driving is faster than walking, and letting each salesperson determine their own path is more effective than everyone taking the bus. So you tell your Purchasing Department to purchase a bunch of vehicles that can take your sales people directly to different locations around town. But vehicles are expensive and you want to save money. So your purchasing department puts your specifications (vehicles for individual salespeople) out to bid, and you accept the lowest price.
What you end up with is a bunch of street motorcycles.
For less than $4,500 each, a brand new bare-minimum street motorcycle ‘does the work’ faster than walking. And because it ‘does the work’ of transporting your salespeople around town faster, it must make them more productive, right?
If that’s true, then why does the average new car cost over $45,000? That’s 10 times more expensive than the motorcycle. Is the car faster than the motorcycle? No. Is the car more efficient than the motorcycle? No. So clearly the most cost-effective solution is to just buy motorcycles for your entire sales force. Then if one of your sales people can’t adapt to driving a motorcycle, replace them with someone who has ‘motorcycle skills’.
Just looking at the numbers, this is clearly the most cost-effective solution. So why doesn’t a single major company do this?
Because we don’t want to hire sales people based on their ability to ride a motorcycle.
Instead, we spend 10 times more money on a car that ‘does the same work’ as a motorcycle because, for the average person, the travel experience is vastly improved. It’s easier. It’s more familiar (doesn’t require any special training). It’s safer. And most importantly, it’s more comfortable. This allows our sales staff to focus on what we hired them to do: sales.
Software should be treated exactly the same way.
If all a piece of software can do is ‘the work’, but makes it exceedingly difficult to either enter data or extract results (in other words, it’s not ‘comfortable’ to use) then the software can end up actually reducing efficiency and productivity.
Good software doesn’t improve efficiency by ‘doing the work’. Good software improves efficiency by making the work easier to do.
Software shouldn’t lead to the creation of superusers. It should do the exact opposite. It should enable every user to be a superuser. It should help every user focus on their actual job, rather than forcing them to spend time and effort using the software itself. If software doesn’t make the work ‘easier to do’, then it’s simply not doing its job.
Remember Janice? That positive, helpful, and eager employee who is dedicated to your organization’s mission? Because of her people-skills, Janice is the employee who’s going to make your organization ‘better’. But Janice is struggling with some poorly-written piece of software, and as a result, her work is progressing slowly, and has many errors.
Your action plan shouldn’t be to replace Janice with someone who can use the software to do work faster and more accurately. Your action plan should be to replace your software to make it easier for Janice to do the work faster and more accurately. Good software should turn Janice into a superuser.
Big data companies like Facebook and Amazon show us that the right software can virtually eliminate even the biggest roadblocks your organization faces. They show us that even super-complicated software can be as easy to use as a basic calculator. So what’s their secret to making such complicated algorithms super-easy to use?
Facebook, Amazon, Apple, and most other huge tech companies focus on the user experience. These companies don’t just make their software ‘do the work’. They’re willing to spend the additional money, time, and effort to make it ‘comfortable’. They study what the user is trying to do. Then they structure the software so it can help the user if they get stuck. They try to place themselves in the user’s shoes and see things from their perspective. There’s a word for that: empathy.
So what can we learn from big data companies like Facebook and Amazon? Believe it or not, empathy for the user. And while smaller organizations may not be able to hire teams of experts, or live-test multiple versions of their software, they can at least make an attempt to think about the user and try to imagine solutions that will help them.
And this empathy must come from the top down. Everyone in the decision-making chain should understand that the user’s needs are hugely important. They should understand that if software is simply functional, it places huge soft-costs on the organization. They should understand how making the software user-friendly can go a long way towards reducing those soft costs. And everyone in the decision-making chain should be shown ways they can actively work towards that goal.
The person making the buying decision should empathize with the people who will actually use the software, and choose software that can both do the job and be easy to use.
The person in the procurement office putting it out to bid or writing the contract should be aware of ‘soft-costs’. They should understand that, when it comes to software, the actual cost to the organization may be much greater than the ‘contract’ price. In their ROI calculations, they should factor in the additional costs of long training periods, the additional time and effort it takes to access data, and the effects of staffing changes produced by poor software. They should recognize that a more expensive piece of software in the short term will likely end up saving both soft and hard costs in the long term. And most importantly they should write specifications in a way that emphasizes user-friendliness. Here are a few example specs:
“Data-entry and data-access must be accomplished with the fewest number of clicks as possible. Any click that is not absolutely necessary to the organization’s goal (not the software’s goal) must be eliminated.”
“The average user should be able to independently enter any type of requisition after receiving 10 minutes or less of training. The average user should be able to retain that ability, even after not entering a requisition for 6 months.”
The software company itself needs to understand that making their software easy-to-use will improve their company’s reputation. They need to recognize that the one-time cost of making the software easier will save ongoing costs of having to ‘support’ software that’s difficult. They need to figure out exactly what the user is trying to accomplish, put themselves in the user’s shoes, and design the software with the user-experience foremost in their mind.
So here’s an idea… Instead of sending ‘trainers’ to each site to teach customers how to use the software, how about sending ‘listeners’ to each site, and let the end-users ‘train’ the listeners on their current processes and pain-points. Then develop software in a way that directly addresses those pain-points. Suddenly the staff feels like they are being heard. They are open to trying the new software and don’t need ‘encouragement’. The software becomes more friendly and intuitive, so scheduling (and paying for) training is no longer necessary.
Will this approach to software development cost more upfront? Yes. But in the long run it will produce significant savings on both hard and soft-costs.
Think about the costs of training.
If 50 people need to use the software, that’s 50 people who need to be trained. And that’s 50 people who will need to be re-trained when the software is updated. When new staff is hired, they will need training. And when someone forgets, someone else will need to spend time reminding them.
‘Forgetting’ is something that happens much more often than most people realize. With so much busy-ness in our lives, we’re always pushing back old information to make room for new. This is natural. This is human. And as a result, humans need constant training and reminding.
But software can be ‘trained’ to help the user. It can be ‘trained’ to be intuitive and comfortable. This ‘training’ can be built into its code. And the more you ‘train’ the software, the less you need to train all 50 users.
Because software remembers.
You only need to train the software once.