real world columns: forms

For me, and many other people, the filling in of forms is one of the most gut-wrenchingly difficult tasks that there is. Tax forms make me cringe, and forms connected with nasty things like car insurance claims are frightening. Often the problems associated with form filling are to do with how well they cater for your particular situation. If they match well you can just get on with it, if they match badly you spend all your time filling things in and crossing them out; ‘do they mean this or do they mean that?’

A small part of good form design, be they paper or on-line forms, involves guiding the user through the filling in of the form; only asking them questions that are relevant and hiding information that is not relevant. However a deeper part of form design is the building blocks at the foundation of the very system that the form is a part of. This is the aspect I want to concentrate on here; forms as an indication of how closely systems match reality. A form that needs to be filled in is not just a means of gathering data, it is an embodiment of assumptions made by the system (and the system’s designer) about who the user is and what they are doing. Forms are the ‘skin’ of underlying systems, and systems are often set in old ways of doing things and old ways of classifying people that don’t match the real world.

Here is a common example: although a huge proportion of long-term, stable relationships do not involve marriage, there is still very little recognition of this in forms and processes. For men they must either tick ‘Single’ or ‘Married’, there is no box for ‘Actually living with someone for the last twenty years and fathering their kids and probably going to be with them a good sight longer’. For women its even worse, if they have already been married and then got divorced before settling down without marrying, then for the rest of eternity there is only one thing they can choose when faced with the choice: ‘Married, Single or Divorced’.

Even the simple, multiple-choice questions I’ve been working on recently for an on-line, user survey have had to be adjusted to take all the user’s eventualities into consideration. As well as the five optional choices, two extra options have been added. An ‘other’ option in case they have an answer different to the five choices presented and an ‘absolutely no idea’ option just in case they really don’t have any idea what the question is getting at.

The bottom line is that it’s difficult to design a form or a system to cater for every user situation; you just have to make sure that you cater for the greatest percentage and have a way for users outside this group to also express something. The more loose and un-rigorous a particular business process is, the more there needs to be scope for the user to express their situation in a way not captured by the structured interface of the form. In these situations paper forms come with plenty of white space for additional information and interactive systems need plenty of event logging with accompanying free-text comment fields to catch non-rigorous, user eventualities.

By far the best example of a ‘non-rigorous, user eventuality’ was Jane’s dad’s car crash. His car had a problem so he left it with his cousin who was a car mechanic (and scrap dealer!). At the weekend he and his family were watching the ‘Late Late Breakfast Show’ on TV, and the TV company were filming a live stunt at a scrapyard. The stunt involved dropping one scrap car from a crane onto another scrap car. Suddenly it dawned on Jane’s dad that the scrapyard was his cousin’s, and that for the shoot the TV crew had chosen two of the best scrap cars that were there, and one of them wasn’t scrap at all it was Jane’s dad’s Ford. While he tried desperately to phone his cousin at home and the TV company, his family shouted a running commentary from the lounge as the scrap car was hoisted up and dropped from the crane onto his trusty Ford.

Looking back he can now laugh about it, he says, but the funniest thing was filling out the car insurance forms. A true indication of how forms and business processes can never capture every single user eventuality, and probably the only time someone has had a laugh filling out an insurance form!