Q&A in forms

 

How to write good questions

When writing questions, the aim is to be clear yet concise. To achieve this:

Only collect information that is needed for a business process

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 fulfill a business function.

This is consistent with privacy policy, which says if personal information isn't explicitly used, you're not legally allowed to collect it. 'Good to know' is no longer a valid or even legal justification.

Be consistent

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

Don’t:

Forms design: Example of using different terms to refer to the same concept.

Do:

Forms design: Example of not using different terms to refer to the same concept.

Use correct spelling and grammar

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

Don’t:

Form design: Example of poor grammar and spelling

 

Do:

Form design: Example of good grammar

Use a tone that encourages the right behaviour

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

Don’t:

Form design: Example of poor tone.

Do:

Form design: Example of good tone.

Don’t:

Form design: Example of over-complicated language.

Do:

Design forms: Example of using the right tone.

Use the form-filler's language

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.

Match form-fillers' thinking

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

Aim for concise rather than short

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:

Form design: Example of poor terminology.

Do:

Form design:Example of a concisely worded question.

Have questions be self-contained and self-explanatory

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:

Design forms: Example of where the question might need explanation

Do:

Form design: Example of clear terminology and extra explanation.

Explore only one concept at a time

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:

Forms design: Example of an overly complex form question

Do:

Form design: Example of breaking complex ideas into multiple questions.

Beware of satisficing

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:

Form design: Example of what not to do, putting the sub category is at the end.

Do this:

Forms design: Example of framing the question properly at the start.

Recognise the context

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:

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

Do:

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

Key choices

Closed versus open

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

For more information, visit the Closed question response categories page on the Formulate website.

Full sentence questions versus brief stubs

Full sentence question:

Form design: Example of a full sentence question.

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

Form design: Example of brief stub of text.

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.

Second versus third person

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

Form design: Use this flowchart to work out if 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).

Defaults

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.

Acceptable characters

Text fields must allow entry of characters commonly used when answering the corresponding question (see Layout of forms - key components for more information).

The table below shows the special (that is, non alphanumeric) characters that must, at a minimum, be allowed in text fields for common question.

Names

Characters that must be accepted Examples of legitimate answers
Apostrophes D'Arcy
Hypens Gordon-Levitt
Diacritical marks (a glyph added above, below or through a letter, to change its sound) Müller
Spaces Emma Lee

Addresses

Characters that must be accepted Examples of legitimate answers
Commas Level 1, 243 Collins Street
Apostrophes D'Anguilar QLD 4514
Hyphens Kippa-ring QLD 4021
Slashes 4/67 Church Street
Spaces The Meriton Apartment

Phone

Characters that must be accepted Examples of legitimate answers
Parentheses (03) 9810 1107
Hyphens 03-98101107
Spaces 03 9810 1107

Email address

Characters that must be accepted Examples of legitimate answers
Apostrophes (before @ sign) martin.o'hanlon@gmail.com

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).

Form design: Example of where a field cannot accept special characters that a form-filler is likely to use, and stating this before the field.

Manipulating answers

By default, data should be accepted and stored in exactly the same format as it was entered by the form-filler.

If legacy systems require a change in format — for example, to all upper case — look first to update the legacy system.

If and only if the legacy system cannot be updated, or a third party system — for example, CrimTrac — requires data in such a format that the form-filler’s answer must be manipulated:

  • allow the form-filler to enter their answer in the format that suits them:

Form design: Example of letting the form-filler to type their answer in the format that suits them.

There are two exceptions to this rule. First, data that draws on a very limited, clearly defined and well known character sets — such as ABNs, credit card numbers and dates as per this standard — can be collected via fields that are limited in entry to those characters (for example, digits only). Second, when it is not possible to reliably programmatically parse the data, as entered by the form-filler, to enable manipulation into the correct format.

  • leave the answer in the field as entered:

  • when presenting the answer back to the form-filler, at Review, Completion (see Layout of forms - Key screens) , or via email:
    • present it back in the manipulated format
    • include help next to the answer, explaining the manipulation:

  • if the form-filler goes from Review (see Layout of forms - Key screens back to the field, present the data in the field as they had originally entered it (that is, without manipulation):

Forms design: Example of allowing the form filler to type in their full name

Form validation

Criteria

Test

Examples

Completeness

All required fields have data Full name has at least one character.
Format All fields have data of the right format (including number of characters) Year has exactly four digits and no other characters. Note that missing digits should be detected via validation so the form-filler can make the appropriate correction, rather than automatically adding leading zeros. Number of digits in an Australian mobile phone number is exactly 10.
Sense Data is broadly sensible. A parent's date of birth is not on or after their baby's date of birth. Age is not negative. Date of problem is after date of purchase.

Autosuggest

This Standard recommends the use of autosuggestion for a number of common questions, including Address and Occupation (Q&A in forms has more information)

With an autosuggest interaction, the form-filler begins typing characters into a text field, and is then presented with matches from which to make a selection:

Form design: Example of address options and possible matches.

Implementation tips

Autosuggest relies on having an underlying list which is:

  • high-quality
  • complete
  • non-overlapping
  • up-to-date

Autosuggest can be implemented to match on:

  • the initial characters of list entries (also known as autocomplete, because the suggestions complete what is being typed); versus
  • any characters in list entries

There is also a implementation choice around whether to:

  • allow the form-filler to type their own answer, even if it doesn’t appear in the list or
  • force the form-filler to choose one of the list entries

In the latter case, unless you are sure that the list covers all legitimate answers, include a 'none of the above' option (as shown in the autosuggest image above). The 'none of the above' option can be a trigger for a conditional question to collect more information (see, for  example, the section on Australian addresses in Q&A in forms).

Often autosuggest interactions are not accessible for form-fillers using screen readers. This is because the matching values can’t be accessed or aren’t communicated. As such, autosuggest interactions should be implemented following the instructions in the Autocomplete page on the Vision Australia website.

Common questions

Some questions appear on a number of forms. Unless a valid and approved exception is made, such 'common questions' should be asked as shown in the following sections. Note that where relevant, the recommended approach is consistent with AS4590, the Australian Standard for the Interchange of Client Information (endorsed by the Australian Government).

Name

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:

Form design: Splitting up parts of the name when you don't need to identify parts of a name.

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

If you do need to identify different parts of the name, do this:Form design: Example of simple way to collect a full name

Or this:

forms design: Example of collecting christian, middle and surname.

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:

Title

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:

Form design: Collecting title information as an option

 

Title should be a drop down containing the four most common titles, in alphabetical order, plus an option of 'Other':

form design: title options should be a drop down list.

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:

Form design: Example of auto-suggest based on characters typed.

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

Other names

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

Forms design: Options for other names

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:

Form design: Example of types of other names.

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

Address

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

  • Residential or physical
  • Postal
  • Billing
  • Shipping

Forms design: Be specific about the kind of address you ask for.

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:

Form design: Collecting Australian addressess with 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:

Forms design: Four lines to collect Australian addresses.

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:

Form design: When country chosen is Australia, make autosuggest available

Country chosen = Australia, autosuggest not available:

Form design: when country chosen is Australia, and autosuggest is 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:

Form design: Example of validating an address outside Australia.

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

Sex and gender

In many cases, sex and gender will be the most personal information you collect on your form. Because of this, you must be completely sure that the information is needed, and choose carefully between the two concepts.

Sex

'Sex' is the biological — but not binary — distinction between male and female. 'Biological' can mean anatomical (for example, breasts or a penis), hormonal (for example, level of oestrogen) and/or chromosomal (for example, X, XY or XXY).

Consistent with Australian and Victorian standards, there should be three answer options for a question collecting sex (in alphabetical order):

Forms design: three answer options for a question about the form filler's sex

Because of the sensitive nature of the information, if possible, make the question optional or give the form-filler a non-disclosing answer:

Form design: Making a personal question optional.

Form design: Making a personal question optional and offering non-disclosure.

You may be surprised to learn that intersex is quite common. The rate is difficult to accurately measure, but there is solid reasoning to suggest that it may be as high as 1 in 150 births, or even 1 in 70. Victoria has a population of approximately 5.8 million people, of which 83,000 may be intersex.

Gender

'Gender' is how a person identifies (psychologically) and/or expresses themselves.

Someone’s gender may or may not make reference to their biological sex. For example, a person with female genitalia may feel like, and identify as, a man. Another person may identify as 'genderqueer', signifying that they see themselves outside the binary constructs of male and female.

Besides 'female' and 'male', the range of terms used to describe gender is wide and culturally specific. Examples include:

  • androgyne
  • neuter
  • third gender
  • transsexual
  • nongender
  • agender
  • questioning
  • male-to-female (MTF)
  • female-to-male (FTM)

In most DJR forms, for example, sex is likely to be the required information — for example, for identification purposes — rather than gender. If gender is collected, use a single (optional) text field:

Form design: Sample question about making a question about gender optional

This accommodates the huge variety of terms used and avoids causing offense. For more detailed information about sex and gender on forms, visit the Sex and gender page on the Formulate website.

Occupation

Occupation should be collected using a single text field with autosuggest:

Form design: Occupation should be collected using a single text field with autosuggest:

The dataset for the suggestions should be the Australian standard list of occupations (that is, the fifth and lowest level of the Australian and New Zealand Standard Classification of Occupations, ABS catalogue number 1220.0).

Matching should begin after three characters have been entered, and involve any part of the occupation (not just the first three letters).

If there are no matches, show no suggestions:

formdesign: Occupation - If there are no matches, show no suggestions.

In such cases, the form-filler has the option of either entering their occupation as they refer to it:

Form design: Example of offering an occupation as they refer to it.

Alternatively, they can look for matches based on different terms:

Form design: Occupation. Alternatively, they can look for matches based on different terms:

As the example shows, the question needs to be clear whether it is a current or previous occupation.

Email address

Collect email addresses via a single text field:

Form design: Example of collecting email addresses with 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

 

Phone

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

Form design: Example of collecting a daytime contact phone number with 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:

Form design: Example of collecting a phone number for each place of work.

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

Form design: Example of text and options when you need to send automated text messages.

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:

Form design: Example of when international mobile numbers are not allowed.

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

  • spaces
  • parentheses ( )
  • dashes -
  • periods

Relationship status

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

Form design: Example of collecting relationship status with a drop down.

Indigenous status

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

Form design: The question wording and answer options shown below are consistent with multiple Australian standards for indigenous status.

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

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

Interpreter

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:

Form design: Example of how to ask if an interpreter is needed.

This approach is recommended by The Victorian Government Standards for Data Collection on Interpreting and Translating Services (PDF, 212KB). Note the second question is conditional and only shows when the answer to the first question is 'Yes'.

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:

Form design: Example of interpreter symbol added.

Dates

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:

Form design: Example of using text fields, one for each part of a date.

Form design: Example of using text fields, one for each part of a 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:

Form design: Example of adding 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:

Form design: Example of allowing the user to decide the date format.

Related How-to guides

How to manage security

How to design and develop a digital presence

How to make websites and content accessible

How to test an online product or service

How to manage privacy

How to do online financial transactions

Join the conversation on digital

Get advice and share your insights about this topic with other digital practitioners on the WoVG Digital Group on Yammer (VPS access only).

Can’t access Yammer? Contact us by email: contact@dpc.vic.gov.au. (We may post your comment on Yammer for general discussion. Please tell us if that’s not OK.)