Back in the dark ages (the 1980s) when I studied Systems Analysis a large area of the coursework was in creation of paper forms. The paper forms (often designed to be NCR — no carbon required) were a primary way for data capture up until the 90s and still are today.

When designing a paper form, there were many common elements. Consider the forms that are still often used today by home repair contractors. They have an area for defining the customer (name, address, etc.) and then lines for capturing whatever work was done, with a column for price, quantity, and extension (price times quantity). And of course, subtotal, tax, and total. In other words: invoice forms like are still for sale at office supply stores like this from Office Depot.

The reason these forms worked for years (and are still in use) is because they solved a common problem and did so well. In the field, a person with such an invoice can capture any arbitrary work. Even one-off special jobs are fine because anything can be written into the lines (and anything often is).

Now, the company decides they want to have software for a phone or pad to avoid using paper. Naturally, they tell their developer that they want to make an electronic version of that venerable invoice, so that they don’t have to re-key all the data from the paper into their accounting system.

And from such an obvious and humble beginning one of the most insidious mistakes has occurred: the prior solution was used as a requirement for the next solution. Instead of solving the problem (capturing the work done) the requirement is to make a version of the old solution.

They have asked to solve the solution instead of the problem.

What is the problem that the paper invoice solves? More than one:

1. who is the customer or client
2. what is the work needed to be done
3. what is the work that was in fact done
4. what is the price for the work done
5. how much did the customer or client pay for the work at the time the work was done

The paper was intentionally designed to let those five things and many more be captured so that later in the office all the details could be captured and transferred to a more permanent and useful system (be it paper or computer). And the paper copy was able to act “as receipt” for the customer’s payment as well. In short, the paper is carrying many different responsibilities.

The task of creating a computerized version of this is not to emulate the paper. If that were attempted, and the “invoice” in the new software let the user “free-form as they saw fit” as they do on paper, then the free-form text would need to be evaluated in the back office just as the paper is in order to fill in the systems!

Instead of attempting to use that prior solution as a requirement, re-evaluate the problem itself. When the contractor is sent on a job, the customer’s data should already be established. The contractor shouldn’t have to re-capture that anyway. The job should have a “reason for visit” which may be free-form or may be one (or many) well defined tasks.

When the contractor arrives at the customer’s site, they need to indicate what they found there. This may be free-form or again may be one or many well defined values.

Those two steps, reason for visit and findings on arrival, are often mashed into the free-form area of the paper form but by being separate they enable the intentions of the business to be clearly delineated without increasing workload on either back-office or contractor. This is a benefit the paper does not have.

Whatever work is done, typically (not always!) has consistent names and pricing. So, instead of scrawling something and “looking up the price” and writing it in, with a computer, the work done can be selected, along with the parts and supplies. There still does need to be “other” with free-form entry, but that becomes the occasional use, not the constant use.

And in turn, those things feed the final amount due to the system for doing the payment processing.

There’s no reason, then, to even consider making a tablet or phone system “look like” that paper it is replacing. The invoice paper solution from an analyst in the 20th century can expire. The modern tooling allows us a modern solution.

This long example seems obvious, but this mistake is endemic.

User interfaces are routinely designed to look like what they replace. Well defined interfaces that capture address data ask for the zip-code first. That lets them pre-fill city and state. Of course, it also must let them overwrite the pre-filled values, but the pre-filled is generally correct. By putting zip-code last they gain the “benefit” of looking like an address does when printed for delivery, but they require more work for the person doing data entry. Isn’t it a good thing to reduce the work when we’re using a computer?

In processing (back-end and not user experience) this problem is common. Payroll systems tend to batch employees and do “runs.” Why? Because older technology was batch and the data had to be loaded on tapes and the job launched via JCL. Those days are long past us, but “because payroll practitioners understand that payroll is in batches” they are still forced to work with huge lists of people per run. But modern systems don’t have any of those technical limitations that caused the older models to run in batch. It’s just a convention that should certainly be allowed, but not required.

When tasked with solving a problem, remember that the person with the problem is generally not an analyst and often can’t “just tell you” what they want. The analyst has the (often hard) task of learning what their problem is and this work must come before even attempting to solve it.

Don’t let “I want it to be just like the current version!” be treated as a requirement. Otherwise, the proper answer is, “Excellent. I’m done, because you have a system 100% like this now.”

And what do we do when they insist on using the prior system as a requirement? Learn what problem it solves, and then ensure that what you propose for the solution is based on the problem the prior system solved, not the prior solution itself.

Keep the Light,
Brian