To improve form completion, first define a successful submission. Then test whether people can understand the fields, correct mistakes, and reach that outcome. Remove unnecessary requests and fix observed failures before assuming that a new layout will improve conversion. A submit click alone does not prove that the application accepted anything.
What is a form completion rate?
Form completion rate is the share of eligible form starts that reach a defined accepted outcome within a stated window. For this guide, count distinct form attempts whose result the application accepted, divided by distinct eligible attempts started. Keep submit clicks separate from accepted results and from later outcomes such as email verification.
Use a stable attempt identifier so retries do not inflate the numerator. Define a start consistently, such as the first edit or a deliberate action to begin a prefilled form. Specify when a resumed visit belongs to the same attempt. Exclude staff and synthetic tests by an explicit rule, and report consent or instrumentation gaps rather than interpreting missing events as abandonment.
Record the cohort, form version, dates, and completion window alongside the rate. If you choose a 24-hour window, wait until every included start has had that opportunity. These are proposed measurement rules for your own analytics, not built-in Swarm tracking.
For signup forms, distinguish accepted account creation from email verification. Measure first value separately using the onboarding drop-off guide.
Which fields should you remove?
Remove a field when the current transaction does not need its answer, or collect it later when it becomes relevant. Keep fields needed for the task, explain why unfamiliar information is required, and distinguish optional input. Evaluate the change against accepted completion and downstream data quality, not field count alone.
Nielsen Norman Group recommends removing unnecessary fields, keeping related labels close to their controls, and generally using a single-column layout.[31] Treat those recommendations as a starting point, not a promised conversion lift. For each field, ask the team that consumes the data what would break if it disappeared.
The World Wide Web Consortium's Web Accessibility Initiative recommends asking only for information needed to complete the process and associating controls with labels.[32] Its instructions guidance says placeholders are not a replacement for labels and calls for required fields and formats to be explained.[34]
A form-specific test and measurement table
Use a test environment and disposable records. The checks below are a proposed diagnostic worksheet, not a benchmark or a claim that every form needs the same design. Keep raw field values out of analytics, especially credentials and personal information.
W3C advises accommodating valid input formats and validating on the server as well as in the browser.[35] A browser validation pass is therefore not your final acceptance check. Its notifications guidance calls for clear success or failure feedback and errors that explain how to correct the problem.[33]
For a wider recovery plan, use the empty and error-state testing guide.
When should validation appear?
Choose validation timing for the field rather than applying one rule everywhere. W3C describes immediate feedback for username availability, but notes that formatted entries such as dates may be better checked after focus leaves the field.[33] Test whether feedback helps correction without interrupting incomplete input, and keep server-side validation regardless of the timing.[35]
Trace one attempt before trusting the dashboard
This hypothetical example illustrates instrumentation, not a Swarm or customer result. A test address form emits these proposed events for the same attempt identifier:
form_started: the tester edits a field.form_submit_attempted: the tester activates Save.form_rejected: the server rejects an invalid postal code.form_submit_attempted: the tester corrects the code and retries.form_accepted: the server confirms the saved record.
That is one started attempt and one accepted completion, despite two submit actions. If the sequence stops at rejection, it has no accepted completion. If the interface displays success without server acceptance, investigate the mismatch rather than counting the message as success. Independently reload or read back the saved test record to verify the result.
Keep acceptance and visible confirmation as separate checks. A saved record with missing feedback is still a usability issue, even when your accepted-completion metric counts it as complete.
How do you know a form change helped?
Compare accepted completion for equivalent eligible cohorts and observation windows, with the same event definitions. Also inspect validation failures, duplicate records, and downstream data quality. A before-and-after difference alone does not establish causation: traffic mix, eligibility rules, and other releases may have changed too.
Use a controlled experiment when practical, and report uncertainty rather than declaring a win from a small sample. Browser checks can establish a reproduced failure and its repair. Research with people is needed to investigate confusion or trust; synthetic success is not a customer conversion forecast.
For one bounded check, follow the first website test guide and create a Swarm account. Inspect the browser evidence, then verify the accepted result independently. Check current pricing and account access before relying on authenticated testing or developer integrations.
Sources
[31] https://www.nngroup.com/articles/web-form-design - Nielsen Norman Group: Website Forms Usability [32] https://www.w3.org/WAI/tutorials/forms - W3C WAI: Forms Tutorial [33] https://www.w3.org/WAI/tutorials/forms/notifications - W3C WAI: User Notifications [34] https://www.w3.org/WAI/tutorials/forms/instructions - W3C WAI: Form Instructions [35] https://www.w3.org/WAI/tutorials/forms/validation - W3C WAI: Validating Input