How to write good questions
When writing questions, the aim is to be clear yet concise. To achieve this:
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
There are 2 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
- present it back in the manipulated format
- include help next to the answer, explaining the manipulation:
- if the form-filler goes from Review (see back to the field, present the data in the field as they had originally entered it (that is, without manipulation):
|Completeness||All required fields have data||Full name has at least 1 character.|
|Format||All fields have data of the right format (including number of characters)||Year has exactly 4 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.|
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:
Autosuggest relies on having an underlying list which is:
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 ).
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
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).
Related How-to guides
Reviewed 29 January 2019