And the winner of the “it seemed like a good idea at the time award” goes to…the Tax Free Savings Account, or TFSA.

The TFSA is a special type of savings account established by the Canadian government, and which came into effect in 2009. Individuals can contribute up to $5,000 per year, and the amount grows tax-free.

Sounds great, right?

Here’s the problem: if you contribute $5,000 to your account, withdraw it, and then add it back later, you will get a stiff penalty.

That’s right – even though the total balance in your account never exceeded the $5,000 maximum, you will still be penalized.

I know this because it happened to me, along with about 72,000 other taxpayers. (For full details, read my entry on TFSA overcontributions in Wikipedia.)

CRA later admitted the contribution limit rules were confusing, and has said they will allow taxpayers to appeal if they genuinely felt they were mistaken, and that they will review each situation on a case-by-case basis.

The problem was that the entire TFSA programme was inadvertently designed to cause confusion. In other words, failure was built into the system. How?

With many people using online banking, transferring money back and forth between accounts is extremely easy. I, like the 72,000 other hapless taxpayers, simply moved funds back and forth on a regular basis, hoping to get the higher interest rate of the TFSA account.

A warning in small print did appear on the banking website, stating not to exceed the TFSA contribution room. But all that indicated to me and the other users was to not exceed the annual limit. There was no warning indicating that the limit doesn’t apply just to the balance but to the total amounts transferred within a year. That difference makes all the difference.

This confusion exposes problems both in usability and documentation. There are several ways it could have been avoided. In order of effectiveness, they are:

1. Clearer documentation should have given to everyone who signed up for a TFSA account. All financial institutions should have emailed, or better yet, phoned, every applicant and clearly explained the transfer limit rules. Even with this warning, though, many people would still have over-contributed. So we move on to the next solution: clearer on-screen warnings.

2. When transferring funds using online banking, a clear warning should have appeared stating that if you transfer more than $5,000 into your TFSA, you will be penalized even if your total TFSA balance is less than $5,000. But again, even with this warning, some people would still have over-contributed, so we move on to the proper solution.

3. The online banking system should have tracked all TFSA transfers and prohibited all transfers that exceeded the overall yearly limit. A message would appear indicating that the transfer would exceed the user’s limit, and stating that if they still want to perform the transfer, they would have to phone it in.

This last solution is the only valid one, because it builds success into the system. It prohibits the user from making a really dumb decision, which is what all great software should do. (Of course, it wouldn’t prevent overcontributions that occur from one bank to another, but it still would avoid much grief.)

Compare the poorly-designed TFSA with a Gmail’s “forgotten attachment” feature. In Gmail, if you prepare an email with the phrase “I’ve attached”, but forget to actually include the attachment, a message appears asking if you still want to send the email without an attachment. Brilliant.

Now, it is not a perfect feature. It won’t work if you use the phrase “I attached” or “Check the attached file”. Ideally, the feature should just search for the word “attach”. But still, it’s a fantastic feature because it attempts to build success into the application.

Building success into our documentation means doing everything we can to anticipate how a user will screw up using both the document and the application. It means creating VAD – Value Added Documentation.

VAD does not simply tell the user what they already know, but what they need to know.

For example, a user may want to send a letter to many different people. If the user doesn’t know about the mail merge feature, they will insanely copy and paste all the letters.

Having an index entry of mail merge is useless, because if the user doesn’t about this feature, they can’t look it up! However, having these index entries could help:

• distributing a letter to many recipients
• letters, sending a letter to many recipients
• mailing a letter to many recipients
• mass mailings, sending
• recipients, sending a letter to
• same letter, sending to many recipients
• sending a letter to many recipients

Yes, these are long index entries, but so what? A good index attempts to anticipate all the strange and wonderful ways a user might look up a topic.

The mail merge topic itself has to clearly explain why doing a mail merge is better than copying and pasting, because if the user cannot see the benefit of what you are suggesting, they won’t do it.

Bottom line – when it comes to bad documentation, don’t get mad – get VAD.