Forms are an integral part of the internet – they’re interesting things too. Forms can be used to help people engage more with your site/application ranging from requesting an email newsletter to signing up for your shiniest, most expensive membership deal.
The problem is that so many people get it wrong when they design and build forms. Here are a few things to watch for the next time you need to make a form.
Garbage in – garbage out. This rather colourful term is basically telling us that, no matter what we do, if that data collected by the form is bad then the results of any processing will also give bad data. When we’re designing a form we should try to prevent the user entering bad data. If we want to collect the user’s name then we should consider using separate fields for ‘forename’ and ‘surname’. If we use a single field named ‘name’ we could get their full name but we might equally get just their surname, just their forename, their user name or even a nick-name. The data might also be littered with things we don’t want – like their title for example – in other words we’re going to get inconsistent and dirty data. We need to apply this kind of thinking to all fields in a form – we need to try to work out what the user might put in to any field and not just base our design on what we want the user to put in – they don’t really know what we want from them unless we communicate it clearly by setting out exactly what we want in each field and breaking down potentially complex or ambiguous fields into smaller, more easily defined fields.
Forms need to fail well. That doesn’t mean that they should explode in a shower of pretty sparks when they go wrong – it means that when they do go wrong, the failure should be limited for the user. If there’s an issue with missing data in a required field we shouldn’t empty the form and make the user start again – we should error-check the form before submission using JavaScript. When the user clicks the submit button, instead of submitting the form, it should trigger a JavaScript validation of the form. If the validation is successful, the JavaScript will then initiate the submission. This way the form will be high-level validated without triggering the page refresh that would remove the user’s data from the form. If the validation is unsuccessful we can also trigger an alert to inform the user of the exact issue whilst keeping their data in the form.
Forms should also be flattering. Jon Duhig of Objective Digital discovered that sometimes we should give the illusion of collecting data even when we don’t really need it (http://blog.objectivedigital.com/fake-form-fields-for-a-better-user-experience). Jon was creating a form with the objective of classifying users by their job type – ‘clerical assistant’, ‘labourer’, ‘warehouse manager’, etc. The form he created was the simplest possible – only asking for the data that they needed. User engagement with the form was low – very few of their users bothered to complete it. He then found that if he added a free-form text field with the label ‘Job Title’ then engagement with the form went up sharply. Users were able to complete the form with the titles they wanted – ‘clerical assistant + senior administrator’, ‘labourer + granite technician’, ‘warehouse manager + senior logistics manager’, etc. When the form was submitted, the secondary data was simply ignored as it was not the objective of the form to capture this kind of data. This secondary data was not actually needed but made the users feel that they were able to express themselves rather than simply being put into boxes.
There are plenty more things we can do to improve the performance of forms but I thought this was enough to read through for now – I’ll save the rest for another time.
Loop 13 