There is little novel or controversial in the claim that most B2B software offers its users a terrible experience.
It can be characterised by overwhelmingly complex screens, no consideration of flow, and menu systems bolted on top of menu systems taped alongside menu systems blu–tacked to menu systems.
When delivering training I often ask class participants about their worst encounters with impenetrable software. The question is often followed by lots of knowing glances between participants who then confirm that it is the software they use every day to do their job. This comprises one or more of the intranet, the annual leave booking system, the timesheet system, or most unforgivably of all, a piece of software which has been written bespoke specifically for their job role.
There are a number of reasons why this is the case, which sit somewhere between excuse and mitigation. I list the more common ones below:
- The people who buy the software and the people who use the software are often different people. The purchase process is regularly driven by feature requests, technical architecture and price. A purchasing team has been assembled to get the organisation best bang for their buck and the effectiveness of the software purchased, or even the idea that software can simultaneously be powerful and also ineffective is given no consideration.
- Enterprises by their nature are vast and complex. Particularly for organisations which have grown by merger and acquisition, or those with an eclectic product and service portfolio, the back–end systems which the enterprise runs on are a patchwork quilt of technologies, databases and integration fudges. The software then has the unenviable task of trying to provide a unified experience to the user, as if the underlying software layers were as one.
- Edge cases dominate the interface. Cluttering screens with “what ifs” isn’t the pure preserve of large organisations yet they seem even less inclined to prioritise flow and interface elements than others. As a result of this the tasks which most users want to fulfil most of the time are overwhelmed with the tasks that some users want to carry out very occasionally. Keeping compliance happy doesn’t need to keep users sad!
- It takes a long time for the tech team to know if their software sucks or not. In the cutthroat world of B2C software and in particular consumer App Stores, designers and developers are connected to the performance of their product in real–time.
The commercial success of their ventures will be closely aligned with number of downloads, number of first uses and the holy grail – number of users who have become frequent and regular. It therefore becomes almost instantly self–evident if an element of the software requires improvement or doesn’t meet user expectations or needs.
This contrasts starkly with large organisations where feedback loops can be long and cumbersome requiring many layers of bureaucracy and months of time. Software replacement cycles are managed using a calendar rather than a stopwatch. So, if the enterprise finds itself with poor or frustrating software, it can be years before it finds out about it and further years before it can do anything about it.
The good news is that UX has a positive contribution to make against each of these factors, which requires the right software design and procurement process, and the right internal mindset and culture to be effective. Below I list how digital mature enterprises get this right:
Involve users in the procurement process – don’t just judge the software for its feature set as part of its assessment, test it also for its usability and usefulness. Ensure usability is a criterion when evaluating options.
Measure software cost in its totality – the cost of software to an enterprise is the license cost of purchasing the software PLUS the salary costs of all the staff who use it and the time it takes them to get stuff done. It is this cost which is so often overlooked but which is regularly much greater than purchasing cost. Work out time taken per task across different units of software, and multiply that by the number of times the task is carried out in the business to fully understand the actual cost of the software.
Prioritise ruthlessly – of course software needs to accommodate edge cases, but it doesn’t need to accommodate them on the same page or flow as the use cases. Be much more ruthless in deprioritising edge cases and avoid choking the flowers of core user needs with the weeds of edge needs.
Evaluate constantly – those responsible for software procurement, specification and design need to be in constant communication with those who use software, so that they have a keen sense of how that software performs in the real world. This will help with empathetic and more commercially–aware software design, specification and procurement.
Users of poor B2C software generally are spoilt for choice and just choose to select a superior competitor. However, users of B2B software often don’t have a choice but to use it. This may give employers the false impression that there is no problem and thus no cost attributed to poor design. A look under the bonnet, using proper measurement metrics as outlined above, with staff morale and staff time to complete tasks being to the fore, exposes this perspective as the dangerous, short–term and false economy that it is.
