Users will abandon systems that don’t let them do what they need to do. That’s why it’s important to adhere to the second principle of building better systems.
Principle #2: Know how your users do what they do.
Knowing how your users do their job helps you design better systems, that facilitate their work and improves results with less time and effort.
Users must be able to use your system to do their job, or they’ll find another way; usually they’ll abandon your system and go back to doing things how they already know. Simply put, don’t frustrate your users by forcing them to change.
I was the dispatcher at an auto service center, and trained technicians to use a computer system to pull repair orders. Some had never used a computer their whole life, and they were so set in their ways, they refused to acknowledge the incoming change.
One tech was angry at me when I told him I wasn’t going to assign him work until he pulled a job through the computer system. He was less than pleasant, and complained to our boss.
I explained to him that he could pull a repair order without me being there (which I’m sure, given his current perception, was a good thing). With this, he could arrive early as he always did, and get right to work.
Before then, the techs had to line up at my station, and wait as I handed out work, based on who was in line first. Once he saw how the system enable him to do his job without me, he was happy to use it.
Facilitate means to make a task easy, or easier. This is accomplished by removing obstacles, such as myself, so the users can get right to what they want as quickly and effortlessly as possible.
Reduces Time and Effort
A system can only facilitate a task if it reduces the time and effort it takes to complete it. This applies to operations and internal communication, not just computer systems.
Time and effort can be reduced by:
- Reducing manual, tedious, and repetitive steps.
- Reduce the need for users to form the meaning of information.
The first, reduce manual, tedious, and repetitive steps, is accomplished by learning how users do what they do, and then translating that into an algorithm.
That algorithm is a set of sequenced instructions to achieve a result, each and every time. Some call this strategy, and developers call it code. Human resources call it policies, and operations call it procedures.
Whatever label it is described, the benefit of an algorithm is that a user doesn’t have to rediscover what to do by interpreting instructions or memory.
While we can train people, we’re still human; we still make mistakes. An algorithm doesn’t change, nor should it, to ensure it remains consistent and produces the same result, every time.
The best example of this is an old one: a cash register. A cashier can manually calculate the total for an order, but what are the chances he’ll get every single order correct?
Meanwhile, an algorithm ensures that the order is calculated correctly, including the complicated tax codes that overlap between state, city, town, and other, seemingly endless factors.
The second, reducing the need for users to form the meaning of information, is accomplished through the result of the algorithm. The total for an order has meaning to both the cashier and the customer:
- The cashier knows how much to collect.
- The customer knows how much to pay.
Once the cashier receives a certain amount, they input that into the system, and it tells them how much change to give the customer.
The meaning behind it is that the transaction is satisfied, and the customer can walk out the proud owner of an 80-inch plasma TV.
Systems need to improve results, otherwise, why fix what isn’t broken?
I go to a barber once a month, sometimes a week late. I’ve seen his website, and I know I could design a better one for him… but what good would it be? He has regular customers (sometimes more than he can handle), so… why?
Your users will have the same question of the system doesn’t improve the results over what they can get now.
Let’s go back to the service center I worked at, and the technician who could pull work without having to wait for me to get into work. (I would arrive at 6:50 am, he would be waiting there since 6:30 am).
This allowed the tech to pull work before the shop opened, and sometimes complete it before the vehicle owner had their morning coffee. They believed we had elves working in our shop overnight.
Nope. We simply had a system that facilitated a technician’s job, and therefore improved the results of the shop. This improved customer satisfaction.
Eventually, word got around about our magical shop, and customers learned they could drop their car off after work, and then pick it up the next morning, either before work, or on their lunch break.
That’s improved results.
That’s a better system.