Systems That Explain Their Behavior Are Better For Users
It happened again. Wells Fargo, my bank, put an inexplicable hold on a check I deposited from a client. And I’m pretty frustrated by the whole experience precisely because of a single word in that last sentence. Inexplicable. Sometimes the hold is placed on a check. Sometimes it isn’t. I’m sure there are “business rules” that govern this behavior, but they appear to be hidden, because no teller or bank manager can tell me what they are. A better approach, and one that removes this frustraction, is to design a system that can explain its behaviors. This is easier to do than you might think and a powerful rule of design.
First, let me finish the story that motivated this post. For those of you run a business, you know that getting holds put on your deposits is par for the course. That’s not the frustrating part. The frustrating part is when the following occurs:
Luke: “Can you tell me why the bank is putting a hold on this check?”Teller: “No, sir. The system just says this check has to be put on hold.”
Luke: “OK. The hold shouldn’t be a problem. I don’t need the fund until the end of the month.”
Teller: “Actually, sir, the hold is for 11 days.”
Luke: “Why? I’ve been depositing checks this large for 3+ years from this client. I’ve never had a single problem with my account. I’ve never had a check placed on hold for longer than 5 days before.”
Teller: “I understand, sir. You have an excellent history.”
Luke: “Then why is the deposit being put on hold for 11 days?”
Teller: “I don’t know sir. The check is just being put on hold. It is what the system says.”
Luke: “Can you find out?”
Teller: “No, sir, I can’t.”
Sadly she was right. Not only could she not find out the reason the check was on hold, neither could the branch manager, whom we had called for assistance. I’m not frustrated the check is being put on hold. That’s part of doing business. I am frustrated that the “system” couldn’t explain its behavior.
And we wonder why normal humans get so frustrated with us software people.
The way around this problem is simple: design systems that can explain their behavior. I first learned this valuable design rule many years ago when I was building expert systems for Electronic Data Systems. One of the things I learned was that an expert system should be able to explain its behavior. What rule fired. What data was present to cause that rule to fire. What action was taken as a result.
The concept is a powerful design concept and applies to more than expert systems. Last year I had the chance to write a simple payroll application (in Excel and VBA, no less!) that processed records from a worker performance system. The worker performance system kept track of activities:
- 8:00A – 9:00A Ramesh was sanding
- 9:00A – 10:00A Ramesh was priming
- 10:00A – 10:18A Ramesh was on a coffee break
- 10:18A – 11:00A Ramesh was priming
- and so forth
I had a list of business rules such as:
- A worker is allowed a 15 min paid break every four hours
- A worker is allowed a 30 min paid lunch
- A worker is allowed 20 min to change a sanding belt (if you take longer than 20 min you’re not paid, to prevent such abuses as taking 3 hours to change something that has been studied to take an average of 12 min +/- 5 min).
To make the application easy to adopt for both my client and their workers, I made each processing step self-explanatory by writing the reason for a payroll calculation into the spreadsheet. For example, in processess Ramesh’s activities above, he would be paid only 15 min of his break time because of the first business rule. By putting this information into the spreadsheet—clearly explaining every step of the processing—we created a system that was rapidly adoptde with minimal support and/or worker frustrations. It also helped that we usability tested our application by asking a subsert of the workers if the explanations made sense to them.
Returning to the example that motivated this post, it is simply inexcusable that the Wells Fargo system cannot provide me with a clear reason as to why my business check was placed on hold. If you’re responsible for designing systems that directly interact with “consumers” via complex business rules, make certain that they can explain their behavior.
May 25th, 2006 at 25 May 2006
[...] Luke Hohmann on why systems should be able to explain their behaviour to users. [...]
August 22nd, 2006 at 22 Aug 2006
[...] According to this Luke Hohmann post “System’s That Explain Their Behavior Are Better For Users“, an important design characteristic of software is letting users know why they system did what it did. Luke describes building a payroll calculation system that gave explanation for its payroll caculations such as “A worker is only allowed 15 minutes of work every 4 hours” as an explanation for why you didn’t get paid for the last 3 minutes of that 18 minute break (btw, would that be hell to work in such a system). [...]