Forms
Part of No-code forms and interfaces
Designing a form around the user's task
Choose form fields, order and instructions from what a user knows and needs to finish at the moment of entry.
Follow one person's job from start to submission. Ask for information they can reasonably supply then, place questions in a useful order and explain what submitting achieved.
The database may need fields that this person should never have to fill in.
Write the task in one sentence
Consider a stock-count difference: “A staff member records enough detail for a supervisor to investigate.” This hypothetical task gives each proposed field a test. Can the reporter know the answer now, and will it help the next person act?
The reporter may select an item and location, enter the counted quantity and describe what they found.
The app may already have their signed-in identity or entry time, but confirm how those values are captured before relying on them.
The supervisor's adjustment decision belongs to a later step.
Put questions in working order
Start with context that helps the user answer later questions. Keep related inputs together. “Counted quantity” tells the person more than “Value”; “What differed from the expected stock?” is clearer than “Comments”.
Use a visible label for each field. State what is required and show format guidance where it is needed. Do not rely on disappearing placeholder text as the only label or instruction.
A text date field may need an example format; a date control still needs to work for the intended users. Give a set of related choices a clear group name.
Conditional questions can shorten the usual route. For example, ask for a damage description only when damage is reported. If the person later changes that answer, decide what happens to the now-hidden description. Retaining, clearing and reviewing it lead to different records, and the builder's configured behaviour matters.
Require information when it becomes knowable
Separate what creates a useful record from what completes the wider workflow. A supervisor may need an adjustment reason later, but requiring one from the reporter invites a guess. A field should be mandatory at this step only when its value is needed and the person can reasonably provide it.
For a longer form, split at meaningful task stages. Show progress and make clear whether moving forward saves a draft or only changes screens. Let users review earlier answers where the builder supports it.
Form Design Best Practices from W3C Guidelines
- Use mandatory fields only when value is knowableReduces errors and improves data quality
- Split long forms at meaningful stagesImproves completion rates and user confidence
- Allow review of earlier answersSupports accuracy and reduces rework
Finish the interaction
Name the button for the action, such as “Record discrepancy”. Say whether submission was received, queued for sync or confirmed in the shared record, as appropriate to the configured app. Receipt is not approval. If submission fails, identify what the person can correct and retain entries where possible.
Before rollout, use fictional details to see whether an intended user can complete the task without explanation. Inspect the resulting record as well as the screen: an apparently easy form may still store the wrong information.
