This guidance helps you to design digital forms filled in by the user. Most of the guidance also applies to printed forms, but there are some differences noted.
Learn about the user before you design a form
Find out about users and their needs through user research.
People use forms to access a service and to meet government requirements.
Sometimes a user will need to fill in a form on behalf of another user. Or a public servant might use a form to record what the user tells them (for example, a statistical survey).
Before you digitise a paper form, make sure you understand the user and business needs. Work out if a form is even needed.
Develop the ‘question protocol’ first
A ‘question protocol’ sets out why you are collecting information and what you will do with it. This tool makes it easier to collect the information that is actually needed.
A question protocol also gives you a way to challenge and push back against unnecessary questions. Every time we ask a user for information it costs them and the organisation. It takes time and effort for the user to provide it, and for your organisation to manage it.
Work out what information you need to collect.
- Do you actually need the information? Why?
- How much detail do you need?
- Can you get the information from somewhere else? (For example, it might already be collected in your organisation.)
Explore the experience of the user providing the information.
- Which users need to give you the information?
- How will the user discover or receive the form?
- Will the user need to collect information from other people? (For example, a form can need different people to contribute to it.)
- What happens to the user before and after they give you the information?
- Are there are other times you might be collecting related information?
Plan how you will manage the information you will collect.
- How will you check the information is accurate?
- What happens if you get the wrong response? What error messages will you need to provide?
- What will you do with the information when you have it?
- How will you keep the information up to date and secure?
Some of these answers won’t inform the design of the form, but will help you manage the information.
Information management requirements
Your question protocol becomes a record. So does anything you collect from a form. Records provide evidence of what your organisation has done and why.
Use familiar words in familiar ways
Write and design forms using plain language. Make sure all users can understand the form.
Some terms are very familiar to users, especially expert users. A form can be harder for people to find and use without certain terms.
Learn about specific words users expect to find on the form through your user research.
Test the form with the expert terms included. If they help the user understand and use the form, keep them.
If some users don’t understand the expert terms, include plain language definitions.
Follow the same rules for voice and tone for forms as in other government content.
Research with users to find out if you need to group questions
Your research with users will help you decide what order to put the questions in.
This will help you work out if you need to group questions and create sections. You might find that you do not need to group any questions.
Begin prototyping with one thing per page
Putting one thing on each page helps you see everything you need to find out, without guessing about the best way to group it.
Begin prototyping with one thing per page over any number of pages:
- one piece of information you’re telling a user
- one decision the user has to make
- one question the user has to answer.
One thing you might need to find out is the user’s birth date.
In the form, you would usually ask for the day, month and year of birth as 3 questions placed together.
Avoid putting too many questions on a page. Having a single thing on each page helps you:
- save the user’s answers as they move through the form
- capture analytics about each question
- handle branching questions and loops.
You will know you have the questions in the right order when the user can:
- understand what you’re asking them to do
- focus on the specific question and its answer
- find their way through an unfamiliar process
- use the service on a mobile device.
[Users often prefer to have username and password questions on the same page.]
Number the questions
For forms that have more than one question, number the questions.
This is helpful for the user if they need to leave the form and return to it later. It can also make it easier for them to get help to fill it in, and for them to work across a paper and digital version.
Use prefilled information and default options if appropriate for the user
If it’s appropriate and secure, prefill information. This saves the user time and effort. Research with users to make sure they’re comfortable with prefilling.
Present pre-filled information on its own page. Ask the user to check and correct the information as part of the form page.
If users are not asked to confirm details they might miss them.
Never include pre-selected gender or sex options.
[A default option for a satisfaction rating means you can't be sure if the user chose to give this feedback.]
Structure the form with clear section headings
When you know how to group the questions, you will be able to create the structure.
Organise content in the form using section headings. Describe the topic or the following section in the headings.
WCAG quick reference:
Don’t mark ‘required’ questions – only ask for what you need
You must only collect personal information if it is necessary. Collect the least amount needed for the function or activity related to the form.
Tell people when and why you are collecting their personal information. Use a collection statement on the form.
You don’t need to mark questions as ‘required’ because you will only be asking for information that is needed.
Sometimes you need to invite the user to tell you something they think is important and they want us to know (for example, to collect feedback). Mark these questions as ‘optional’.
Follow the Australian Privacy Principles when you handle personal information. The principles cover a range of things that could identify an individual, in any format.
People have a right to request access to their personal information under the Privacy Act 1988.
The Freedom of Information Act 1982 gives people the right to request access to government-held information. This includes personal information collected in a form.
Format in a single column
Don’t use multiple columns in digital forms.
Avoid using a second column in print forms.
If you have to use multiple columns, keep the same number throughout the form. Make sure the columns are visually different.
Splitting information across 2 or more columns can:
- add cognitive load for users
- slow down users of assistive technology if they miss content
- make the form harder to use on mobile devices.
Test complex forms with task lists and ‘check your answers’ pages
Complex forms can branch. They might have sections that don’t apply to some users and optional questions. This means the user might not move through the form in a predictable way.
If the user needs to know how long it will take to fill in a complex form, test the form with:
- a task list page at the start
- a ‘check your answers’ page at the end.
Check your answers pages summarise the sections of a form. The summary shows the user what information they’ve provided.
This step can help users go back and change any responses, or confirm that they’re giving the correct information.
Avoid using a progress indicator. It’s difficult to design an accurate indicator that shows a user their progress through a complex form.
If the form is short (for example, 5 questions or fewer with no branching), the user won’t need a progress indicator. Adding the indicator would be extra work that the user might not even notice.
Say who the form is for
Before a user starts a form, they need to know:
- what the form is for and if they need to fill it in
- who can use the form (if they are eligible for the service)
- what they need to submit the form
- if they can ask someone else to fill it in for them
- what happens after they submit it and any other stages.
If the form is part of a service that will involve other stages, show the full service process with a task list. Include information about any other forms the user will need to fill in.
Use form inputs that are accessible and easy to fill in
Use the following 3 form inputs. They are the most accessible for users.
If you need the user to:
- pick one preferred option, use radios
- select one or more options, use checkboxes
- write an answer, use a text input.
If you need to use other form inputs, try rewriting the questions to fit these inputs.
Form components and templates are part of the Australian Government Design System.
There is no way for a user to distinguish between radios and check boxes in in print forms. You can include a message to select only one option, but the user might not read this.
Plan for how you will use the information if the user selects more that one option.
Write short active content for forms, including ‘help text’ and error messages – this is called ‘microcopy’.
Don’t disable inputs as it can confuse the user. Only include a question if it is relevant to the user.
Avoid using select (menu items) and range sliders
Select boxes and range sliders can be very hard for some people to use. This includes people who experience essential tremor or difficulties with hand control.
Instead of using a select box, ask other questions to reduce options. Then display fewer options using radios.
Use radios instead of range sliders.
Use buttons for calls to action
Don’t use a button unless it is a call for action.
The label must clearly describe what happens when the user selects the button. Try to use one word or a short phrase as a label.
WCAG quick reference:
Use the primary button for the main action
Use a button for the main call to action on the form (for example, ‘Save and next’ or ‘Send application’).
Position the primary action button in the same place on every page (for example, at the bottom of the form, aligned with the left side of the input field). This placement makes the form predicable and easier to use.
Add secondary buttons if there are extra actions
Sometimes you need to use a secondary button for another common action (for example, ‘Save as draft’). Make sure the button action matches what it says it does.
Make secondary buttons visually different and less prominent than the primary button.
Avoid using a disabled button
Disabled buttons can confuse some users. Only include them when your research shows they make the form easier for the user.
Write labels for every question
Include one short label for every form question to make it clear to the user what to do. This is the text that appears next to a form question.
Write labels without a colon at the end. Otherwise, follow the normal rules for using punctuation marks.
Don’t put anything in the field the user will type in – this is called ‘placeholder text’.
Write clear labels and ‘help text’ instead of placeholder text.
Make sure labels are close to their question
Align most labels above and close to the questions.
For numerical fields, place the measurement symbol to the left of the question (for example, ‘$’ or ‘%’).
Position checkboxes and radios to the left of the label.
Use <label> or <legend> for digital form headings
If you have one question per page, use that question as the heading for the page.
Put the <label> or <legend> element inside the <h1> element.
This avoids screen readers reading out the same information twice.
Include ‘help text’ to provide more context
Write extra text to help the user complete the question the first time they try (‘help text’). In very complex forms, you might need to link to more detailed explanation.
Position the help text between the label and the input field. Associate the help text with the label for screen-reader users.
Don’t use headings, labels or placeholder text for help or hint text.
Add validation to help the user to complete digital forms
A form with validation will check what the user types into fields. It will trigger an error message for the user if they miss a field or make a mistake.
Write error messages so they help the user act on the problem, not blame them for making a mistake.
Apply verification checks for:
- correct numbers of digits – for example, an Australian Business Number
- including a required character – for example, the ‘@’ in email addresses.
Adding colour to show if an input is valid can help some users complete the form. Don’t use colour alone, and make sure assistive technology can detect validation.
If the user is not eligible for a service, don’t show a validation error. Use a separate page that explains:
- why they can’t use the service
- their options.
WCAG quick reference:
Use methods that stop robots, not users
A ‘CAPTCHA’ is a question that aims to prevent robots from submitting forms. Unfortunately all versions of CAPTCHA make it hard for some people to use forms. Find other ways to check for robots.
Instead of CAPTCHA you can use:
- a question that only robots will fill in (a ‘honeypot’)
- checks for very short or very long submission times.
Read the W3C’s guidance on alternatives to using CAPTCHA.
Test the form with users to make sure the method that you use does not prevent people from using the form.
Add only essential branding
Talk to your communications team for guidelines on how to brand forms.
Make sure print and digital forms meet the Australian Government branding guidelines.
Only include icons, images or colour when research shows they help the user understand the form. Make sure you create accessible images.
The digital edition builds on information about forms in the Content Guide and updates information from the sixth edition. It focuses on the digital environment.
The sixth edition included a whole chapter on forms. The focus was on printed forms but it did refer to on-screen forms.
The Content Guide has brief information about forms.
About this page
18F (n.d.) ‘Forms’, 18F Accessibility Guide, accessed 13 July 2020.
Birkett A (2019) ‘Form Design: 13 Empirically Backed Best Practices’, cxl.com blog, accessed 30 April 2020.
Christian LM, Dillman DA and Smyth J (2007) ‘Helping Respondents Get It Right the First Time: The Influence of Words, Symbols, and Graphics in Web Surveys’, Public Opinion Quarterly, 71(1):113–125, doi:10.1093/poq/nfl039.
Department of the Prime Minister and Cabinet (2019), ‘WISER: A framework for improving government forms’, Form-a-palooza 2019, Behavioural Economics Team website, accessed 30 April 2020.
GOV.UK (2018) ‘Structuring forms’, Service manual, GOV.UK, accessed 30 April 2020.
GOV.UK (2018) ‘Designing how GOV.UK content and transactions work together’, Service manual, GOV.UK, accessed 30 April 2020.
GOV.UK (2018), ‘Designing good questions’, Service manual, GOV.UK, accessed 30 April 2020.
GOV.UK (2020), ‘Making labels and legends headings’, Design system, GOV.UK, accessed 1 May 2020.
GOV.UK (2020), ‘Text input’, Design system, GOV.UK, accessed 1 May 2020.
GOV.UK (2020), ‘Help users to recover from validation errors’, GOV.UK Design System, accessed 1 May 2020.
Jarrett C (2010) ‘The Question Protocol: How to Make Sure Every Form Field Is Necessary’, UXmatters blog, accessed 30 April 2020.
W3C (2019) ‘Forms Concepts’, Web Accessibility Tutorials: Guidance on how to create websites that meet WCAG, accessed 13 July 2020.
This page was updated Thursday 30 July 2020.