Catch-22 with a pretty large health insurance website: – you need to give us the first payment to get your card – in order to perform a payment, you need to log-in. – to log-in your first need to register – to register you need you adhesion number – to get your adhesion number, you first need your card.

Best part? When I tried calling, I had to wait ~ 1 hour to get connected to the right person, a with every telephone tree branch saying to me that I needed to go to the website to do everything I needed. In addition to that, after waiting all that time, I was told I needed to wait until the invoice was generated.

Morale:

1. Make sure you solicit user’s action only when your system is ready for it and when that action is likely to succeed.
2. Make your user create an account that would be recognized from the go, even if it would mean that there will be nothing shown on his account.
3. Have a collection point where the reports of your “happy system” malfunctions would go.
4. Register failures to properly use the interface and progressively build a database of corner cases and edit your system fall-backs to account for them.
5. Always test for usability to check that there are no catch-22 that will waste your tech support time.

Bonus points for the website – there is a paper invoice I hold in my hands, but the website shows that no invoice was generated I could pay for. Final bonus point – COMIC SANS. On the main USER-facing GUI page. Overriding other “sane” types.