I received the following email last week about an upcoming change in the learning management system used at the university where I’m an adjunct professor:
“Blackboard, has grown to become an essential tool for teaching since it was first adopted in 2000. Over the past few years, however, users have become increasingly dissatisfied with Blackboard from both ease-of-use and technical perspectives.”
Emails like this are indicative not of a specific problem with Blackboard, but with a general problem of most business to business (B2B) software usability in general.
Why does it often take years of driving users to a breaking point before something is done?
While similar to usability in the Business to Consumer (B2C) sector, Business to Business (B2B) usability differs in six key ways.
- User is usually not the buyer: When you purchase software or an app and it’s hard to use, you’ll likely stop using it and probably not purchase it again. When you’re on a website and you can’t find the products or information you’re looking for you go elsewhere. Even a lot of downloadable consumer software has free evaluation periods so users can try out the functions and get a sense for the ease of use. This reduces the risk for the buyer, who is almost always the user.
However, for most B2B software, purchasing decisions are made using a procurement process. Usually a committee assesses the needs of the business, articulates the features, usually in an RFP, and then considers the solutions from qualified vendors. Companies consider the needs of the users when they make the purchase decision, but a lot gets lost in translation. What’s more, a business has to prioritize many competing interests, including budgets and existing software that it has to integrate.
The feedback loop is slow. It takes time for the daily interface problems to work their way up a corporate hierarchy. Who wants to be known as the complainer to upper management? Pretty soon a decade has passed with people tolerating a poor user experience.
- Customization: When I worked at Oracle we’d test enterprise software applications like accounting and HR systems. One thing we heard a lot from our test participants is that the interface we’d test them on wasn’t what they used in their companies. The reason was customization. IT departments have to customize the ordering, HR and accounting systems to match the way their company did business. With large companies, few did business the same way or had the same combination of products and so had software with vastly different experiences. This also made it virtually impossible to have a free evaluation period as there was so much cost involved in coding and implementing custom systems. By the time the implementation was done and users could actually use it, the usability issues would emerge, when it’s too late.
This is why Keystroke Level Modelling is particularly effective. If you can sketch out an interface before spending months to develop it, and if you know exactly what users will do (especially if they are repetitive tasks) then you can estimate if a new interface will take more or less time to complete tasks and make changes accordingly. Efficiency doesn’t fully describe usability, but it can often be a huge improvement to users’ lives.
- Harder to find users: It’s almost always harder to find participants for usability tests when working with B2B software or hardware. All those accounting and HR systems have users with pretty specialized skills. This is not walk-up-and-use software and you can’t just grab anyone from a Starbucks to participate in a test. These workers’ time is precious, and expensive. You’ll often need to recruit from conferences and trade-shows or just set up your usability testing at such an event.
This is one of the reasons why a Heuristic Evaluation can be such a valuable tool. Having 2-3 double-experts in both usability and the product domain review an interface for problems uncovers many of the same issues that users would find. Expert reviews are no replacement for usability tests, but when it’s not feasible to test with users, this approach is a good substitute.
- Switching costs are high: Even when the purchasers, committees and executives know there’s a usability issue costing time and likely money, it’s hard to change. If it takes years to customize and train personnel on a new system, switching to a new system will usually cost as much and take at least as long. What’s more, most large software purchases require new servers and staff with different skills. But it’s unclear if the training and customization headaches will actually deliver easier to use software. Product demonstrations of enterprise software always look great and easy to use, but it’s hard to know if the grass is greener until you get to the other side.
- Training users: Most websites are meant to be used by the general public without requiring any specialized skills. It would be unthinkable if users have to read a manual or take a class just to use a website. Yet that’s often the case for the B2B software user experience. Complicated manufacturing processes, architecture plans, and federally regulated accounting practices mean employees can’t just use their intuition when using software to complete a job.
Some amount of training is expected and often required. This has an impact on how to conduct a usability test. Even if you are able to find enough users to participate in your study, it’s often not reasonable to expect them to use an unfamiliar interface. One of the most common complaints I heard from B2B product developers about usability test results was that the problems uncovered were because the users weren’t properly trained. And they’re right, without the training it was hard to distinguish between real issues and false-positives due to an artificial testing setup.
But required training isn’t an excuse to lump poor interface design in with understanding business rules and workflow. One of the most effective methods we found for working with this issue was to introduce an element of training into our tests[pdf]. We’d simulate training on an interface and even have users attempt the tasks more than once to assess the longer term usability and learnability of a system. Problems that persisted after training and repeated attempts become much more credible to the overburdened development teams.
- The usability is usually worse: When we looked at the frequency of usability problems across a number of datasets, we found that B2B applications had almost 10 times the number of usability problems that websites had and 2 times as many as consumer software. Is it any surprise? When you have users that don’t make the purchasing decision, with a slow feedback loop, customized interfaces that often go untested with scarce users, the usability suffers.
One of the most effective ways for refining and testing features is A/B testing. Yet for most functionality it’s difficult to A/B test features with actual users. Can you see the problem with having a General Ledger Accounting application for an accountant that alternates between different layouts?
B2B usability isn’t a lost cause. While improving the usability of back-office systems isn’t as glamorous as working on the latest mobile app, it’s ripe for opportunity. As more software moves to the cloud it becomes easier to test and update software to improve the B2B user experience. In fact, companies like Salesforce.com have made it their mission to improve the accepted poorer experience by reducing the implementation costs and customization.
Hopefully more organizations will find ways of assessing and improving the usability for their end users and not just take drastic steps to switch software providers every 10 years.