A number of our more expert users have asked what approach we use internally to build a particularly complex component in a form. This is an approach that we’ve found very helpful. It recognizes that really intelligent users tend to over-complicate their searches for solutions to a form that doesn’t work as intended. We call it the “Rule of Three.” This description may be too basic for you, but it helps make certain that we get it all in as far as “surrounding the issue”, so please excuse that.
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.
I know. It sounds basic, 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 a) start from a fresh completely blank page; b) void any jargon at all; c) and proceed with one step at a time, proving each step as you go. We think of it as approaching the problem as a most basic new user would, one who doesn’t know anything and who is conditioned against taking shortcuts.
For a specific example, really do start from complete scratch to eliminate mental distractions caused by details that make no difference. Leave out all the jargon and instead use A, B, C or X, Y, and Z and 1,2,3 and Andy, Betty, and Charlie or Apple, Banana, Carrot. The key is to use words that have no meaning or merit so that our brains don’t leap ahead of themselves to make connections that don’t exist, or spending effort trying to decode the jargon in case it is important (it never is), 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 but won’t burn up brain power trying to keep everything under control.
The added benefit of the approach is that if there is a problem with the program it becomes very easy to communicate the problem and show it by example.
Give this approach a try. It will allow you to either solve the issue by looking at it completely differently or make it really easy for us or other professionals to see it and “get it” if additional help is necessary.
