Articles
A form nobody finishes: designing data entry people actually complete
Every field you add is a reason to stop. What separates a field the clerk knows from one they must look up, and where the deciding field belongs.
- forms
- ux
- data-entry
A form is abandoned at the field the person cannot answer, not at the submit button. The clerk knows the item, the quantity and the customer in front of them; the form asks for an account code, and the queue decides the rest. Every field you add is a reason to stop.
Which fields does the clerk already know?
Sort every field into three groups: known at the counter, known by the system, known only later by someone else.
Known at the counter is what the person is holding: the item, the quantity counted, the name as spoken, today's date. Known by the system is what the tool can derive: the account, the price, the warehouse, the tax category. Known later is what only the office supplies: the accounting code, the invoice reference, the approval.
Only the first group belongs in the form. The second is prefilled once the deciding field is answered; the third is a queue. The test for each field is one question: who, standing here, can answer this without walking away? If the answer is "the accountant", the field belongs on the accountant's screen.
Which fields are required now, and which can arrive later?
Required means the process cannot continue without it, not that a report would like it. A delivery note with no quantity is not a record; one with no accounting code is a record with an open item, and open items can be counted.
Everything that can arrive later should arrive later, into a named queue with a visible count: twelve records waiting for a code, four for a price. The count is what makes deferral honest; a missing field nobody counts is a missing field nobody notices.
| Field | Who can answer it | When |
|---|---|---|
| Item and quantity | The clerk, at the counter | Now, required |
| Customer account | The system, from the name | Now, hidden |
| Price and accounting code | The office | After save, own queue |
Which field decides the whole record?
One field determines what the rest of the form must ask. For an order it is the customer; for a stock movement the item; for a maintenance ticket the plate number.
Put it first, alone, and make it a search that accepts the words the person has: the name as it was said, the plate with or without dashes, the local name beside the official one. Once it resolves, half the form disappears — address, unit, price, zone.
Two rules follow. Never continue with an unresolved deciding field: a typed name that matches nothing becomes a duplicate somebody reconciles by hand later. And when the search returns several candidates, show the town and the last order date, never a column of identical names with codes.
How should validation talk to the person filling it?
Validation explains; it does not scold. The message says what is wrong, where, and what to do, in the form's words: "the delivery date is before the order date — check the day", not "invalid input".
Four habits do most of the work. Keep what was typed; never clear a field because it failed. Fix silently what can be fixed: stray spaces, a phone number with or without the country code, a decimal comma. Validate when the field is left, not on every keystroke, because an error mid-word accuses someone still typing. On a long form, summarise at the top and link each line to its field.
Accessibility is part of this: a visible label tied to its field, and an error described in text rather than by a red border alone. The Web Content Accessibility Guidelines (WCAG) 2.2 state the requirement, and a field a keyboard cannot reach is a field that gets skipped.
What happens when the form is interrupted?
At a counter the form is interrupted constantly: a second customer, a phone call, a delivery arriving, a power cut that takes the router with it. A form that loses the work on the first interruption gets filled on paper the second time, and the paper wins permanently.
So save a draft without asking, keep it visible, and let any named colleague resume it, not only the author. An abandoned draft should age into a short exception list, not disappear. Where the connection drops, the form should open, hold its data until the line returns, and say it is offline.
How many fields can a counter form carry?
No number transfers between businesses, and any figure offered as a rule is wrong for someone. The mechanism decides: the budget is the queue, each field spends a decision, each lookup spends a trip away from the counter, each error spends a correction later.
So the count that matters is lookups, not fields. Nine fields the clerk knows finish faster than five where two need a file, and a field that needs a lookup does not belong at the counter, whatever its position.
A decision procedure
- Stand at the counter for one hour. Watch one person fill the form as it exists, and note every moment they stop or ask someone.
- Mark every field: known here, known by the system, known later.
- Move the third group out, into a queue or off the form.
- Choose the deciding field and put it first, with a search built on the words people say.
- Set the required minimum — the fields without which the record is not a record — and give the deferred queue an owner and a visible count.
- Fill twenty real records yourself, on the counter's device, with the connection off for five of them.
Where this goes wrong
- The form is designed from the report. Its columns become fields, in its order, and the person at the counter is filling a report.
- "Required" is used to enforce discipline. A mandatory field nobody can answer becomes a placeholder — 000, xxx, a hyphen — and the data is worse than blank because it looks filled.
- Validation is used as a filter. A phone rule written for one operator rejects another's numbers, and the clerk learns to type a fake one to get past it.
- The form is tested at a desk, on a laptop, by the person who designed it, on a fast connection.
What this does not cover
This is about a form one person fills many times, with the object in hand and a queue behind them. A public form filled once has different problems — motivation, trust, how much a stranger will tolerate — and the rule about lookups does not apply to a respondent with no supervisor. Nor does this decide what a record should contain: a short form feeding a report nobody reads is a different failure with the same symptom.
We build forms by standing at the counter first — the fields the clerk can answer, the deciding field first, the rest in a queue — then measure completion on the device that is actually used.
Services in this article
Articles
Related articles.
Digitising a paper form without breaking the process
A paper form encodes rules nobody wrote down. Audit the fields before you draw a screen, pilot on one form, and keep the paper as fallback.
- forms
- process
- digitisation
Why your team goes back to the spreadsheet
Your team did not reject the tool for its features. Three fields, one six-click step and a report that changed its number sent them back.
- adoption
- internal-tools
- ux
Moving a spreadsheet into a real system without losing the numbers
The spreadsheet is the specification. How to read the rules out of the file, clean it, reconcile control totals, and stop the old sheet changing.
- migration
- data
- spreadsheets
Start a project
Have something to build?
One short brief is enough. You get a written scope and a fixed quote before anything starts.
