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.
- Make sure you solicit user’s action only when your system is ready for it and when that action is likely to succeed.
- 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.
- Have a collection point where the reports of your “happy system” malfunctions would go.
- 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.
- 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.