Start with the user's journey, not the data model

It's tempting to design a form around the fields your system needs. Resist it. Start instead by thinking about the person filling it in — what do they know at this point, what do they need to do, and in what order does that feel natural?

A form that maps cleanly to your data model but asks for a Tax File Number before the user knows why they're providing it is a form that will get abandoned. Group questions the way a person thinks about them, not the way your database stores them.

‍

Only ask for what you actually need

Every question you add is friction. Before adding a field, ask: do we genuinely need this, or would it be nice to have? If the answer is "we might use it one day", leave it out. You can always add fields later; removing them from an existing form is harder once submissions are in flight.

If certain fields are only relevant for some users, use Form Logic to show them conditionally rather than putting them on the form for everyone.

‍

Structure longer forms with pages

If a form has more than six or seven questions, break it into pages. Each page should represent a logical step or topic — not just an arbitrary split. Good page breaks reduce overwhelm, give users a sense of progress, and make it easier to use Form Logic to skip entire sections when they're not relevant.

Plan your page structure before you start building. Questions can't be dragged between pages after the fact — only reordered within a page — so getting the structure right upfront saves significant rework.

‍

Write questions and labels in plain language

Write field labels as direct questions or clear instructions, not internal field names. "What is your date of birth?" is clearer than "DOB". "Upload a copy of your ID" is clearer than "Identity document".

Use help text to explain why you need something when it isn't obvious. "We need your TFN to process your application — it will only be used for this purpose" is much less alarming than a blank TFN field with no context.

Avoid jargon, acronyms, and internal terminology. If you wouldn't say it out loud to the person filling in the form, don't write it on the form.

‍

Use the right question type for each input

Choosing the wrong question type causes errors and frustration. A few guidelines:

• Single Input for short free-text answers — names, reference numbers, email addresses.
• Comment for longer free-text answers where the user needs more space.
• Dropdown for lists with more than five options. For four or fewer, Radiogroup is usually clearer since users can see all options at once.
• Checkbox for multiple-select scenarios where more than one answer can apply.
• Boolean for simple yes/no decisions — it's cleaner than a radiogroup with two options.
• Date inputs via Single Input with date validation rather than freeform text — this avoids format inconsistencies (01/02/2024 vs 1 Feb 2024).
• File when the user needs to upload a document, and Signature pad only when a genuine signature is required — not just acknowledgement.

‍

Make mandatory fields intentional

Don't mark every field as required by default. Mandatory fields should be genuinely necessary for the form to be processed — if you can proceed without the information, make it optional.

When a field is mandatory, write a clear, specific required error message in the Validation tab. "Please enter your email address" is better than "This field is required". Users should never have to guess what they missed.

‍

Write validation rules that match real input patterns

Validation should help users, not frustrate them. A few things that go wrong often:

• Phone number formats — Australians write their mobile number many ways (0412 345 678, 04 1234 5678, +61412345678). If you're using a regex validator, make sure it handles the formats your users will actually enter.
• Email validation — use the built-in e-mail validator rather than a custom regex. The built-in one handles edge cases more reliably.
• Over-restrictive length limits — setting a maximum length that cuts off legitimate input (like a long legal name or a multi-line address) creates errors that are confusing to diagnose.
• Missing error messages — always set a custom error message for every validator. The default platform message is generic and often doesn't tell users what to fix.

‍

Keep Form Logic manageable

Logic is powerful but can become hard to maintain quickly. A few habits that help:

• Name your questions descriptively — question5 is meaningless in a logic rule; "HasPartner" or "EmploymentStatus" makes rules immediately readable.
• Review logic from the Form Logic tab — not just field by field. The centralised view is the only way to see the full picture and spot conflicts or redundant rules.
• Don't over-branch — if your logic is becoming deeply nested, consider whether the form should be split into separate forms for different user types instead.
• Test every branch — use Test Form to submit responses that trigger each logic path and confirm users see exactly what they should.

‍

Pre-populate where you can

If you already know the user's name, address, or account details, pre-populate those fields. Asking users to re-enter information you already hold is a friction point and a common source of errors. It also signals that you don't know who they are, which undermines confidence in the process.

Use the Data tab on each field to map pre-population from your integration, and set authentication requirements on sensitive fields so data is only revealed once identity is confirmed.

‍

Test thoroughly before publishing

Use Test Form for every form before it goes live. Work through the form as multiple different user types — not just the "happy path". Try leaving required fields blank, entering invalid values, and following every logic branch to its completion.

• Does every validation message make sense to someone who doesn't know how the form was built?
• Does the completion message feel appropriate for the context?
• Do all actions fire as expected on submission?
• Does the form look right on mobile as well as desktop?

It's much easier to fix these things before users encounter them than to patch a live form under pressure.

‍

Think about what happens after submission

A well-designed form doesn't end at the Submit button. Make sure users know what happens next — "We'll review your application and be in touch within 5 business days" is far more reassuring than a blank completion screen. Configure your completion message or redirect to set expectations clearly.

If downstream systems depend on the form data, test your Actions too — confirm that notifications fire, Webhooks deliver, and any CX  communications are triggered correctly and contain the right content.

Good form design is mostly about respect for the user's time, their attention, and their ability to understand what you're asking. Keep it simple, keep it clear, and test it properly. Everything else follows from that.

‍