Every once in a while I do something stupid when I’m using an application. Sometimes I forget to fill out a field on a form or maybe I type in my birthday in the wrong format or miss the obvious “agree to these terms” checkbox that will allow me to continue to the next screen. Most of the time, if these applications are well written, the validation message comes up and tells me I’m being stupid. That’s good.
There are other times where I do something and the logical misstep is not identified. After the misstep I often think, “Wow, I wish the application would have warned me that I was about to do something stupid.” There are two times in particular (I’m sure there are more) where a system warning would have helped me avoid a lot of inconvenience and effort.
D’oh! Moment #1
My first example took place a few months ago when I traveled to Tampa, FL for a business trip. It was a one day trip where we arrived the night before, had our meeting , and headed back to the airport in the early afternoon. I was in a good mood. The meeting went well and I was going to get home at a reasonable hour. My mood however started to change as I was having difficulty checking-in for my flight on my phone. OK. No big deal. Sometimes these apps can be finicky so I’ll just check in at the kiosk. No luck again. It kept telling me I had no flight which was strange because I’ve booked hundreds of these kinds of flights without a problem. So off to the agent I went.
After providing the agent with my information she turned to me and stated that I was awfully early for my flight – a whole month early! Apparently I booked the flight from Feb 27 to Mar 28. D’oh! Thankfully the agent was kind to me and at no cost booked me on a multi-leg flight back to Chicago which put me home that night past midnight. It certainly could have been a lot worse.
When I considered it more, the more I thought about how the system should have been smarter than me. Never in my many years of travel have I ever booked a flight where the departure date and the return date are more than 2 weeks apart.
D’oh! Moment #2
The second example took place several years ago when during our startup phase I setup our first payroll online in the payroll vendor’s system. The setup was surprisingly simple (we were only 3 people in startup mode after all). Everything seemed in order until I got a frantic call from the payroll company. They asked if I had authorized a payroll and stated the amount. The number they gave was surprisingly big – like 24 times the amount it should have been– like maybe equal to the amount of our annual payroll! D’oh again! When I was asked to enter the payroll amount, I entered the annual amount and figured it would calculate what the semi-monthly payroll should be. The payroll company, of course, assumed I would do the calculation.
Unfortunately in this case it took a lot of effort and money to unwind the transaction. They had already sent the money to the IRS and getting money back from the IRS once you give it to them is not easy. After a considerable amount of time and legal fees we did manage to resolve it.
But again the application should have been smart. It should have warned me that I was doing something stupid. The amount of money entered for the payroll was well beyond a range of “normal.”
A Better Way
These missteps identify just a couple of the kinds of gaps that exist in most any system of moderate complexity and usually there is no way to quickly fill that gap. Using traditional programming techniques, these changes would take weeks if not months to implement. Wouldn’t it be nice if the application was built for change up front?
Wouldn’t it be nice if the airline agent (or their manager) had the ability to get in the system and suggest a rule like the following:
All the following are true
Current trip duration for traveler is greater than 14 days
Each previous trip duration for traveler in last 2 years is less than 14 days
Show warning message “Are you sure you want to schedule a trip for [current trip duration]? This is longer than any previous trip you’ve taken in last 2 years.”
This rule could then be approved by the central office, tested, and added to the application without any programming effort. The same is true with the payroll application.
As hard we might try to identify the specific behavior of an application up front, we just can’t. But we can make applications smarter by building in the ability up front to change the behavior that that drives them. If we do this I believe our applications would organically grow whole lot smarter, faster and in many cases more useful. And it would help me avoid those “D’oh!” moments.