Four ways to improve sign up and survey form performance

Given that the completion of forms are often the end goal for many online conversion processes it’s surprising how badly many sites still present them.

Web forms have been around since the internet first became popular, nearly 30 years ago. Unfortunately, in many instances their usability hasn’t improved much. I’m still constantly coming across sign-up and survey forms on supposedly ’modern’ sites that, styling aside, function not much differently to those 20 years ago.

Below is a basic checklist of commonly understood but often omitted techniques to improve form performance and overall usability. They aren’t all mandatory requirements, but it is worth thinking about these techniques when reviewing or briefing in your next customer web form.

1.  Are you using in-line validation?

One of the most frustrating aspects users have with forms is the validation process. This is where the information that users have input into the form elements is checked for correctness and completion. The typical default method of validation tends to occur server side (on the server housing the website) rather than the browser itself. Generally this means that the user is taken back to the form page after they click submit and displayed the list of missing information and/or incorrect data they have added. This is really annoying and is arguably the biggest cause for user attrition through the form process.

With fairly basic use of client side scripting (at the users’ browser) most, if not all, validation can take place as the user inputs their data. This is called “inline validation”. When a user, for example, fills in their first name (assuming this is mandatory) the script will recognize that this field has been completed instantly and show a green tick to indicate that this part of the form is complete. Below are some other examples of inline validation techniques that can be used while the user is completing a web form

  • Checking data formatting – emails, credit card numbers and phone numbers can be checked for correct format ensuring that users haven’t, for example, left out the “@” symbol or “.com” in their email addresses, left out numerals in their credit card number or omitted their area codes in phone numbers. Just about any data requested that has a standardized format (set number of characters and character types) can be validated automatically inline using fairly simple scripts.
  • Checking field completion – As outlined above, and mandatory fields can be identified as being completed immediately. This can be further augmented with progress indicators that show the number of fields a user needs to complete as opposed to the typical pages of form fields left in a process. You can even set the submit button to not be clickable until all the necessary fields have been completed.
  • Cross referencing existing data – For some time now it has been possible to pass data to and from a webpage without the need to refresh that page. The technical term for these transferences of data is an “Ajax request” or even more technically an XHR request (“XMLHttpRequest” although data is more often passed as JSON or TXT files these days – but that’s super geek talk). In practical terms what this means is that it’s relatively easy to check if someone is trying to setup an account with an email address or username that already exists or replicates/conflicts with any data already existing on your database.

2. Are you pre-formatting fields where possible?

The ability to type is often taken for granted by those that can. For those that can’t type, seeing a page full of empty text fields to fill out can appear daunting to say the least. By using as many checkboxes, radio buttons and drop downs as possible, filling in large forms presents more as a clicking exercise than a typing one.

An additional benefit to using check boxes, drop downs etc. is that all the data that’s being passed to you is preformatted. This makes sorting and analysis of data significantly easier as you don’t need to re-interpret what users have typed into open text fields. If, for example, you ask people what their interests are and one of your internal categories is sport – how many ways can users identify that they like sport: “Rugby”, “Netball”, “Running”, “Rock climbing”, “Kung-foo” etc…

Phone numbers are notorious for format errors; is the area code included or not, what about the country code, will the numbers include or exclude spaces? By using separate text areas for each of these requirements you can ensure they are all completed correctly. You can also setup each text area to only allow a specific number of characters to be input and even disallow spaces and letter characters to be input. Not only does this help you to standardize data collected it also makes it visually clear to users what their input expectations are

3. Are you using users’ data to pre-populate fields?

Addresses are particularly problematic for data normalization (technical term for standardized format). There are lots of pre-developed tools available to help users select predefined state, city, suburb and street values or better yet you could ask for their post code first. This will allow you to then automatically populate what state, city and list of suburbs they live in – see my previous article for more details on how to achieve this

The number of brands and sites users belong to now can be quite daunting. I often try to rejoin a site I already have a membership to or an affiliate site that shares the same user authentication. If this maybe the case with your user group then consider asking for users email address before anything else. That way you can tell users immediately (using inline validation) if they already have an account before they carry on to fill any other data

4. Is your form as small as it can be?

The basic rule of thumb is that there is a direct correlation between the size of a form and the amount of user attrition in its completion.

The scale of forms can be measured in a number of ways

  • The number of fields and quantity of data you are trying to collect.
    Often data requirements are determined by committee, and often committees are full of people who ‘need’ to be involved. This can result in a lot of data requirements for a single business process. Before finalizing technical requirements, have a think about what the basic business goals are, and what the minimum data requirements are to achieve these goals.
  • The area on a page that the form takes.
    Often this is measured in “page folds” i.e. how far down users’ need to scroll to get to the bottom of the form. Excessive scrolling is a pain. It makes it hard for users’ to assess the amount of work they need to do and can be fiddly on mobile devises and tablets. Using 2 columns can help reduce the overall vertical space a form takes up, as can using expandable accordions to house categories of data e.g. Address details or content/product preferences
  • The number of pages the full form requires.
    Ideally forms should sit on a single page. If your forms are spread out over a number of pages you might want to consider using some of the techniques above to reduce the overall page count. Accordions in particular can be good at this. For larger forms, it’s not always possible to include all content on a single page (excessive scrolling is often worst that multiple pages). For these instances make it clear to the user how long the form is and how far through the process they are as they complete the form.

It’s not rocket science

There’s nothing new in any of the techniques above, but they’re so often missed out. And from a development perspective using these techniques doesn’t have to break the bank.

All too often the development of forms is left solely to the developer building the site with maybe some visuals from a designer. Good forms don’t just happen, they need to be planned and designed from the users’ perspective. Make sure that you consider the efficiencies of your forms as early as possible in the design process. Better yet, include some of these techniques in the initial requirements documentation so your dev team knows exactly what to do and you don’t have endless rounds of amends.

 

 

Alan Clark
Alan Clark
Alan has spent over 10 years working in digital and database marketing, running a variety of both small and very large projects from initial strategy through to full delivery

Alan Clark's LinkedIn profile

Read more of Alan Clark's articles

Similar articles from our blog

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Please type the characters of this captcha image in the input box

Notify me when others comment

Stay up to date

Sign up to receive fortnightly updates on all the latest changes in our crazy digital world

Your email will never be shared