Usability of systems
In early June, I moderated the conference “IT in Industry”. At the round table on personnel training, an interesting question arose: is it possible to create an industrial program with a simple interface?
If you simplify the interface, then you don't need to train employees. You can compare SAP, whose interface is devoid of any human features, and Uber. For some reason, no one launches courses on “how to use Uber”? But for SAP, such courses are necessary.
The round table concluded: no, it's impossible! We manage complex systems with complex processes that can't be simplified to Uber. And there's no money for it!
Unfortunately, the round table format did not allow for large discussions, and it was not possible to discuss the thesis in detail. But, in my opinion, this is a mistaken opinion. Let's figure out why.
Can interfaces be simplified?
There are many examples of interface simplification. Computers have gone from punch cards to nocode. A bunch of buttons on a mobile phone have turned into volume up/down, the stylus has disappeared. Previously, to drive a car, you had to know how to change spark plugs. Now people drive a car sometimes without understanding how to fill the washer reservoir with water, not to mention adding oil.
That is, there are many examples of interface simplification. Why did the opinion arise about industrial systems that simplification is impossible?
Why are systems complex?
Systems can be divided into two classes:
1. systems for users, S4U – systems for users. This is what we use as end users: iPhone, Uber, booking.comairbnb, passenger cars and so on.
2. systems for business, S4B – systems for business. This is what the company instructs us to use: SAP, Oracle, 1C, airplanes, etc.
These classes of systems differ in the directions of development:
1. The end user cannot voluntarily abandon the systems for business (S4B), unlike the systems for the user (S4U). If we do not like the iPhone, we buy an Android, or vice versa. I do not like the note application – I switch to another, it is entirely my decision.
In business systems it is not so. Employees are tied to business systems by employment contracts and job descriptions. I do not like the 1C interface – but I cannot refuse to use 1C.
2. The end user does not participate in the selection of business systems (S4B). And even if he does, the usability factor does not play a decisive role in choosing a system. Salespeople who do not work with the system sell the system to top managers who also do not work with the system. At most, they look at reports in the system.
User experience systems cannot ignore usability. If Uber's interface were like SAP's, the startup would die before it even started. And if the iPhone's user experience were like using a punch card computer, we'd still be sitting on phones with buttons.
Systems for users are selected and evolved, including for ease of use. Incorrect user actions are assessed, how they affect the experience of working with the application, repeat orders, etc., that is, the interface is constantly adjusted to the user.
Business systems, for the most part, don't care about user behavior – for them, it's a secondary goal. If a user doesn't understand something in the system, then it's a problem for a specific company and a specific employee: train employees more thoroughly, here are some instructions (if you're lucky, they'll be clear and convenient), implement mentoring, and so on.
I was once discussing the employee personal account at one of the companies. I was worried that people would not use it, as the interface was quite complicated. To which I received a wonderful answer: “No need to worry! We will just tell them to!!!” I have heard similar answers at other companies.
Dealing with user errors
User error in business systems always remains the responsibility of the user. In 2005, a broker of a Japanese company, instead of selling 1 share at 610 thousand yen, entered an order to sell 610 thousand shares at 1 yen. The damage amounted to 27 billion yen. When analyzing this situation, no one talks about the usability of the software, everyone talks about the broker's error.
In my practice, there was an example when the operator entered the price of the product 2500.00 instead of 25.00 rubles: the comma on the keyboard got stuck or she was distracted. This price was agreed upon by the commercial, financial and general directors. Only the storekeeper noticed – the order volume did not correspond to the order amount.
After that, we redesigned the price entry portal: we introduced spaces between digits, increased the font, added warnings and other actions to reduce the likelihood of incorrect price entry. Unexpectedly, as the operators told me, working with the new system turned out to be much more convenient!
So business systems are so ugly and inconvenient not because they can't be made simpler, but because companies and developers don't care about end users. The main thing: reports, performance, scalability, etc.
How much does convenience cost?
How can you evaluate the usability of a system? Industrial design experts will tell you that a user-friendly interface brings a huge number of benefits: reduced time, fewer errors, less fatigue, etc.
You can evaluate usability using a simple example. Let's say we've simplified one operation from 35 seconds to 5. The user performs this operation 10 times a day. That is, the time savings will be 5 minutes a day: 30 seconds multiplied by ten.
Time savings per year per user will be: 5 minutes per 240 working days, which gives us 1200 minutes or 20 hours or 2.5 working days. If we assume that the company has 1000 users, then we arrive at a savings of 2500 working days per year, or 10 full-time positions.
If you translate this into money, you get a pretty impressive amount. If you also assume that the new operation does not require training and the number of errors is reduced several times, then the effectiveness of a simple change can be simply gigantic.
Business logic
But such an assessment runs into harsh logic: how can these calculations be proven?
As one of the top managers told me: Look, we won't pay employees less because they work less? That means there is no economic benefit. So why spend money on a project where there is no economic benefit?
In some ways, this logic is correct. If an employee worked exactly 8 hours, and now he works 7 hours 55 minutes, we will still have to pay him for 8 hours of work. If we follow this logic, then the benefit of reducing one minute is zero. Well, the company will not gain anything from this!
Such an assessment leads to a negative effect: the cost of adding another minute to working time is also taken to be zero. Well, the employee does not work all 8 hours a day. He chats with colleagues, drinks tea, goes to the toilet! So, there is a reserve of time, and you can add another two or three minutes, or even 10 minutes.
In my practice, there was a project for 500 million rubles, which did not work, because they did not provide for who would spend 5 (really 5) minutes a day. The system analyzed different data streams, issued potentially harmful situations that had to be divided into safe and harmful. As always happens, this was assigned to the store director, who already had a lot of responsibilities – he had no time for this. As a result, the sophisticated system generated a data stream that no one used in any way!
Increasing load
— How much does a drop of vodka cost you?
– A drop? Not at all!
– Then pour me a glass!
Business systems are constantly expanding. A company may have several projects, each of which adds one or two or more operations, without showing this in any way in the costs. Which ultimately leads to employee overload.
Employees will, of course, complain about the increasing volume of work. But here another logic comes into play: we used to manage everything! Here, just a couple of simple operations were added to the system. You simply do not want or do not know how to work. And if employees perform some operation in 10 minutes, then everyone will talk about an underdeveloped generation, a learning curve, poor training of employees, etc. And the system? The system is perceived as a given: they work in other companies!
Increased workload on an employee ultimately leads to increased staff turnover. Staff turnover is easy to measure, but proving a cause-and-effect relationship between inconvenient programs and turnover is virtually impossible! Turnover is influenced by many factors, and isolating the impact of one operation on employee departure requires large-scale research, which takes time and money.
The bottom line is that although the efficiency and benefit of improving usability is significant, we cannot prove it. In this case, projects in which it is easier to calculate indicators become more significant than projects that can radically change the work in the company. In this case, the business saying: “if you can't measure it, you can't manage it” turns into “you manage what is easiest to measure.”
Conclusion
Increasing the usability of systems leads to significant benefits: saving employees' time, reducing training time, reducing the number of errors, etc. The larger the company, the greater the effect.
Current project evaluation practices do not allow us to prove the benefits of improving usability:
1. If we reduce the time of one operation, we will not fire any of our employees.
2. If an employee does not have time to do something, it is his responsibility.
3. The influence of other factors is difficult to prove, so they are not taken into account.
To avoid such logic, we should talk not about the number of staff units, but about the pool of working time at the company's disposal. We reduced the time of working with the system by 2,500 man-days per year? This means that we increased the company's capabilities by this time. How the company uses this pool of time is a question of the efficiency of the company's operational procedures, but not a question of the efficiency of improving usability.
In my opinion, everyone should take as a goal to bring the S4B interface to the S4U level. Yes, ordering a taxi will always be easier than managing a nuclear power plant. It is most likely impossible to develop software similar to Uber for all systems. But the goal is not to bring the interfaces of all systems to the level of one button, but to constantly improve the usability and simplify the systems. Even if the usability of systems is increased by 10-20%, it will be simply cool.
The very premise that business systems cannot be brought to the level of Uber is harmful, since it does not move systems in the right direction.
Author: Alexey Koryakov
