Here’s an approach to diagnosing issues in relatively complex forms that we’ve found extremely useful. It recognizes that really intelligent users tend to over-complicate their searches for solutions to a form that doesn’t work as intended. We think of it as the “Rule of Three.” Experience has taught us that it works best when the results of each step are written out; perhaps merely slowing the process helps, maybe it triggers a different side of the brain. Whatever it is, trust us. The difference is measurable.

1. Describe the goal, if possible in one sentence.

2. Describe the Rules that need to be followed by the eventual solution. Start broadly, setting no more than three Rules. They can be developed further in a bit, with each Rule further subdivided into up to three Rules.

3. Start building an example that will illustrate the issue; develop the possible solutions; and eventually illustrate the solution.

Got it, it sounds stupid, right? But it works better than all the alternatives we’ve tried over the last 10,000 or more service issues. The keys are to start from a fresh completely blank page. Avoid any jargon at all, and proceed with one step at a time, proving each step as you go. Think of it as approaching the problem as a most basic new user, one who doesn’t know anything and, critically important, who is conditioned against taking shortcuts.

For a specific example, I would get rid of all the jargon and use A, B, C or 1,2,3 or Andy, Betty, and Charlie or Apple, Banana, Carrot. The key is to use words that have no meaning or merit so that the brain doesn’t leap ahead of itself, trying to decode the jargon in case it is important (it never is), or making connections that might or might not be useful. Then reduce the number of examples to test to just three, a nice manageable number that has the added benefit of fitting on one page. Finally, reduce the number of drivers, whether they are Lists, Conditions, Tags, or rows in a spreadsheet to just three, again a manageable number. What’s cool is that it turns out that anything that works with three variables will work just as well with 53 or 500 but won’t burn up brain power trying to keep everything under control.

The added benefit of this approach is that if there is a problem with the program or a user or the environment it becomes very easy to communicate the problem and show it by example.

A major troubleshooting aid is to reduce every complexity to its simplest level. If you're working with Lists, try Fields, if complex Conditions, test with simple ones: if you're working with SQL, drop it down to Excel. In other words, simplify first then grow into complexity.

Give this approach a try the next time you’re really jammed up with a form that isn’t behaving. It will allow you to either solve the issue by looking at it completely differently, or it will make it really easy for us to see it and "get it.” This entire process should take more than 15 minutes and has a high likelihood (>80%) of solving the problem. It's exactly the approach we've used to solve 9,998 of the 10,000 issues we've worked on.

A caution: the number one mistake we see is working with the “live” form. First, the risk of overwrite is too high. Second, too often the live form is loaded with detail that adds fog to the environment. The best way, the easiest path is to start over with a completely clean slate. If you have problems with two paragraphs of a 100-page form, delete everything other than the two paragraphs. Then delete all the unneeded Questions. That gives you a "bite-sized" problem to work with, rather than an elephant.

Here’s a fun recent example of this approach in play.

Here's what it looks like broken down by the goal set:

And, even better, the attachment includes all the coding necessary to make it work.

tags; complex lists, roles, problem solving, diagnostic, sick form, patience, solve