Q and A in forms - digital guide

Only ask for information you have a genuine and demonstrated need to collect, and that you — or a relevant and appropriate third party — will use to fulfil a business function. 'Good to know' is no longer a valid or even legal justification.

Don’t use different terms to refer to the same concept.

Don’t:

Do:

The correct grammar and spelling improve readability, credibility, trust and form-filler satisfaction.

Don't:

Do:

Tone should be direct and active, yet professional and courteous.

Don’t:

Do:

 Don't:

Do:

Remember that the English you use daily may not be right for form-fillers.

For instance, 14% of Victorian adults have very or extremely poor literacy (as measured on an internationally recognised scale). This means more than 1 in 10 Victorians struggles to recognise common vocabulary, understand the meaning of sentences and read paragraphs of text.

In other words, a significant proportion of Victorian adults are 'unable to use and understand anything more than the simplest of prose'.

For more information, visit Adult Literacy and Life Skills Survey, Summary Results, Australia, 2006 (Reissue) on the Australian Bureau of Statistics website.

Research shows that form-fillers must do four things to answer a question on a form:

• understand the question
• find an answer
• judge whether the answer fits the question
• provide the answer

Following are some tips for helping form-fillers with each step.

Understand the question

• be aware that even familiar terms can be ambiguous (for example, does 'child' include adult children, or children who are adopted or step?)
• use plain English and the vocabulary of the target audience. Avoid jargon, technical terms, 'officialese' and internal language
• where unfamiliar or ambiguous terms must be used (for example, 'trader' or 'certificate'), provide a definition of the term at the first point(s) of use
• unless you know they are widely understood by the target audience (for example, 'VIC' for Victoria), avoid abbreviations and acronyms. If you must use an abbreviation or acronym, spell it out at the first point(s) of use

See, for example, Cognitive Aspects of Survey Methodology: Building a Bridge Between Disciplines (1984), pp 73-100 on the National Academies Press website.

Find an answer

Helping form-fillers find an answer is all about working with the constraints of human memory and cognition.

• avoid asking about the distant past
• avoid asking about things that are unlikely to be accurately remembered (for example, forgettable events or very specific details)
• provide frames that limit (for example, 'In the last six months' or 'Three most recent')
• minimise the number of questions that cannot be answered 'top-of-mind'
• if, to answer some questions, the form-filler must consult other sources, allow more time for this and choose easily found sources

Judge whether the answer fits the question

• if a form-fillers are likely to be unsure whether their answer 'counts', provide clarifying information or definitions (for example, 'Including step or adopted children')
• avoid ambiguous terms like 'usually', 'often' and 'regularly'; for person A 'regular' might mean once a week whilst for person B 'regular' means daily. Instead, be specific (for example, 'In the last week, have you <done X> more than <Y> times?' or 'What was your most recent occupation?')

Provide the answer

• choose a method for capturing answers that matches the way form-fillers’ think, rather than database design
• for Text fields, ensure the field allows sufficient number of characters for the range of answers (see Layout of forms - key components)
• for closed questions, ensure there is a response option to suit the range of answers (see Closed versus open in Q&A in forms)
• include 'not applicable', 'don't know', 'other' or 'none of the above', as appropriate. Such options should be presented at the end of the list of options. In drop downs, these options can be separated from other options by a dividing line
• if not it’s obvious, or the question is particularly personal, explain why the question is being asked. This will encourage completion

Compared to longer questions, short questions can often be harder to understand, because they use more complex or unfamiliar terminology and/or have a more complex structure. Sometimes additional words aid comprehension and thus make for better overall usability.

Don't:

Do:

Everything the form-filler must know to answer the question must be included in the question. Form-fillers should understand the terms used, without outside assistance, and no more than two lines of supporting help text should be needed.

Don't:

Do:

Our brains cannot process more than one thing at a time, and it’s taxing to hold multiple things in short- term memory. If your question involves more than one concept, try to break it up into multiple questions.

Don’t:

Do:

Form-fillers will only read as much of the question as they (unconsciously) believe they need to read, in order to answer. Thus, any framing information — for example, time periods or sub-categories — need to be at the start of the question.

Don't do this:

Do this:

Forms are often completed in a hurry, while also doing something else, and/or with minimal attention on the task. Questions therefore need to be difficult to misinterpret.

Don’t:

Mother's surname at her birth

(Easy to get confused about whose birth is being referred to.)

Do:

On her birth certificate, what is the mother's surname?

(Harder to get confused about whose birth is being referred to.)

A 'closed' question is when you provide the form-filler with a set of options from which to choose their answer. Closed question response options can be presented in a number of ways, but the most common are:

• radio buttons
• check boxes
• drop downs

For more information, refer to Closed question field types.

The opposite of a closed question is an 'open' question, where the user can provide any answer they like, into a text field. Ideally, questions should be closed, because closed questions:

• minimise data entry for the form-filler
• minimise errors
• help the user interpret the question

However, only close a question if you know — rather than are guessing — what would be an appropriate set of response options. Closed question response options need to be:

Appropriate: the options should:

• account for the main answers form-fillers are likely to give
• come from reputable, relevant and timely sources
• be at the right level of detail for the context of use
• be reviewed and updated on a regular (scheduled) and sufficiently frequent basis

Complete: there must be a response option to suit each and every form-filler

Mutually exclusive: the options should not overlap

Self-explanatory: the meaning of the different options should be clear to the form-filler

Sorted: the options should be presented in the most logical and relevant order for that context of use. If it helps, options can also be grouped into categories

Full sentence question:

What is your residential address?

Brief stub (that is, 1-4 words):

Residential address

Try to be consistent and stick mostly to only one type of question per form. Use full sentences by default, but especially when:

• brief stubs may be ambiguous
• it is difficult to phrase some questions as brief stubs
• each form-filler will use the form infrequently (for example, member of the general public registering a birth)

Full sentences should end with a question mark ('?').

Use brief stubs only when one or more of the following conditions are met:

• each form-filler is likely to use the form frequently (and thus more likely to scan, which is supported by brief labels) for example, funeral providers registering a death
• the information being collected is very common to forms that the target audience is exposed to. Postal address is an example of such information

Brief stubs can end without any punctuation or with a colon (':'). Whichever option is chosen, be consistent throughout the form.

Use this flowchart to work out whether the form should be voiced in second or third person:

Never use first person (for example, 'my'), as this creates confusion about whether 'my' refers to the form- owner (for example, Working With Children Check Unit') or the form-filler (the applicant).

A form is a conversation between the form-owner and the form-filler, albeit not person-to-person. The questions on the form are being asked by the form-owner, hence (for example) the suitability of 'you' when referring to a form-filler.

If 'my' were ever used on a form it should, to be grammatically and behaviourally correct, refer to the form-owner. But this would conflict with the questions being about the form-filler (or someone they know).

A 'default' is an answer provided on behalf of the form-filler, in anticipation that it will be the answer they wish to give. Defaults are a type of pre-population (see Layout of forms).

Defaults reduce the form-filler’s workload by providing answers for them. However, they also increase the chance of error — valid but inaccurate data — as they lower the amount of conscious consideration of the answer that the form-filler gives.

Only provide a default for a question if the vast majority (for example, 80% or more) of form-fillers will choose that answer (for example, a default state of 'Vic' for residential address).

Form-fillers must always have the ability to change a default answer.

If a field cannot accept special characters that a form-filler is likely to use, state this before the field (see the section on Help: Question level in Layout of forms).

For example:

What is this party's involvement in the complaint? Do not use apostrophes ( ' ), quote marks ( " " ) or percent signs ( % ).

Names are surprisingly complicated, especially in a multicultural society like Australia. For example, names can:

• be singular (for example, Stilgherrian or Kimbra). Based on Medicare data, at least 13,500 Australians have only one name
• be as short as one or two letters (for example, Wu Yi)
• be very long (for example, Matthew Featherstonehaugh or Velikkakathu Sankaran Achuthanandan)
• be hyphenated, but still need to be considered a unit (for example, Jean-Michel)
• contain separate words that need to be considered as a unit (for example, Vaughan Williams, a double-barrelled family name)
• contain words starting with a lower case letter (for example, Niels van der Rohe)
• contain non-alphabetic characters, especially apostrophes (for example, O’Flannery)

Any fields used for collecting name need to allow and recognise these variations. If you don't need to identify the different parts of a name, collect it this way:

Full name

Do not attempt to split a 'full name' up programmatically.

If you do need to identify different parts of the name, do this:

Given name(s)

Family name

Or this:

First given name(s)

Middle given name(s)

Family name

Do not use alternative labels for name, such as 'first name', 'last name', 'surname' or 'Christian name'. These terms are culturally specific, unclear and ambiguous.

For more information on names, visit the following:

Sex and gender - Formulate website

Personal names around the world - W3C website

Avoid collecting title: it’s extra work for form-fillers and potentially exposes highly personal information like sex, gender and/or marital status.

If title must be collected, make it an optional field:

Title should be a drop down containing the 4 most common titles, in alphabetical order, plus options of 'Mx' and 'Other'. Mx is the most commonly used non-binary title for people who want to use a title.

If needed, the selection of 'Other' can trigger a conditional text field (see  Conditional fields in Layout of forms - key components). This can be a standard text field or can autosuggest based on the characters entered by the form-filler:

This approach minimises errors (by forcing choice from a pre-defined list of options) while allowing the list of options to be large.

If you need to collect other names a person is or has been known by:

• Type of other name
• Other name

If more than one other name is acceptable, the questions above can be implemented as a set of repeated fields (see Repeated fields in Layout of forms - key components).

The types of other name should be:

• Aboriginal or tribal name
• Adoptive name
• Alias
• Foster name
• Maiden name
• Previous married name

If the business doesn’t need it, 'Type of other name' can be left off the form.

Never just ask for 'address'. Instead, be specific about type:

• Residential or physical
• Postal
• Billing
• Shipping

As needed, also be clear about whether the address is current or previous.

Australian addresses

Regardless of type, Australian addresses should be collected using a single text field with autosuggest:

This approach significantly minimises errors and workload, but does rely on an underlying dataset that is appropriate (for example, postal addresses should come from Australia Post) and current.

Note how Australian addresses are written <Street>, <Suburb or town> <State> <Postcode>, that is:

• single comma, after <Street>
• single space between <Suburb or town> and <State>
• single space between <State> and <Postcode>
• <Street> and <Suburb or town> written in sentence case
• <State> written as 3-letter abbreviation, all upper case

This formatting should be used whenever an Australian address is presented back to the form-filler.

When the form-filler chooses 'None of the above', or autosuggest is not available, collect Australian addresses via four (required) lines, as follows:

• postal address
• street name and number
• suburb or town
• state
• postcode

Suburb or town, State and Postcode must be validated against each other.

International addresses

If an address can be outside Australia, collect country first. Do this via a text field that autosuggests based on the characters entered by the form-filler, matching on any part of the country name.

Country chosen = Australia, autosuggest available:

Country chosen = Australia, autosuggest not available:

Because international address formats vary significantly, and are very difficult to validate, addresses outside Australia should be collected via a single multi-line text field:

For a taste of the complexity of international addresses, visit Falsehoods programmers believe about addresses - Michael Tandy website. 

Collect email addresses via a single text field:

Note:

Do not ask the form-filler to enter an email address twice. If the email address is a username or primary contact method, use validation via an email link to ensure it is correct, and include a tip about how it will be used (as shown above)

Email addresses are surprisingly difficult to validate. Ensure there is an '@' symbol, with at least one character either side, but go no further. For more information, visit the I Knew How To Validate An Email Address Until I Read The RFC page - You've Been Haacked website

A daytime contact phone number should be collected via a single text field:

Do not collect more than one phone number unless absolutely necessary, for example, when a phone number is needed for each place of work:

If you need to send automated text messages, this approach balances form-filler and business unit needs:

In the example above:

• the first field:
  • captures country and thus dialling code
  • is a text field with autosuggest (country names with dialling codes appended in parentheses)
  • defaults to 'Australia (+61)'
  • should match on the entry of any characters in country name — as per the Country field in International addresses (see Q&A in forms for more information) — or the entry of '+' and digits for a dialling code
• the second field collects the number itself (for overseas numbers, leading zeros should be automatically stripped)

If international mobile numbers are not allowed, remove the country code field and reword the question, as follows:

All phone number fields should accept characters that are commonly used when writing phone numbers, namely:

• spaces
• parentheses ( )
• dashes -
• periods

Relationship status should be collected via a drop down with the following options:

The question wording and answer options shown below are consistent with multiple Australian standards:

The link 'What 'Aboriginal or Torres Strait Islander origin' means' should open a window with this information:

Collecting information

If the business has a need to collect information about an interpreter — for example, to know whether an interpreter will be needed for follow-up contact — use the following approach:

Extra information about interpreters and translations can be added, especially if the business wants to encourage users of another language to adopt an alternative channel to online (phone).

Offering services

If an interpreter or translation service is available for a form, then form-fillers should be asked whether they need such a service:

• up-front, for example, at Introduction or Eligibility (see Forms layout- key screens for more information)
• using the first question shown above, but with clarification and the interpreter symbol added:

Exact dates

When collecting exact dates, the best balance of speed, simplicity and error minimisation is achieved by using text fields, one for each component of the date:

For more information, visit the Asking for a date of birth page - GDS design notes blog.

Exact date fields:

• should accept only digits
• should not automatically move focus from one to the next. Automatic tabbing does speed up data entry for those who expect it. For other form-fillers, it leads to errors and rework. More importantly, automatic tabbing takes control of the interface away from the form-filler. For more information, visit the Why we care more about effectiveness than efficiency or satisfaction page - GDS user research blog
• should use the title attribute to describe each text field to form-fillers using screen readers, for example:
  Title='Day of birth, in the format DD'
  Title='Month of birth, in the format MM'
  Title='Year of birth, in the format YYYY'

In this way, dates are the one exception to the rule about not breaking text fields up into chunks (see the section on Text fields in Layout of forms - key components).

If an exact date is recent — for example, within three months of the current date — add a calendar control to the field:

Use of the calendar control should be optional (that is, form-fillers should still be able to enter digits directly into the text fields). Ideally, the calendar control will also be keyboard accessible.

Inexact dates

If the date required is approximate, or unlikely to be remembered exactly, use a single text field, and accept letters as well as digits: