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.

By Atheerium6 min read
  • forms
  • process
  • digitisation
All articles

A paper form is a process with the rules hidden in its layout: which boxes are mandatory, who initials the margin, which copy goes to the accountant, and what the clerk does when a number looks wrong. Scan it into a screen and you keep the boxes but lose the judgement. The order is therefore: audit the form, then design the screen. The exception is a form with no exceptions — a plain request slip where every field is written down and nothing is ever corrected by phone. Those are rarer than they look.

Who fills the form, and who actually reads it?

The person who fills it is rarely the person the form serves. A delivery note is written by a driver, signed by a customer, checked by a storekeeper and read a month later by an accountant.

Each reader uses a different subset: the storekeeper wants quantity and condition, the accountant wants price and date, the customer wants proof that something arrived. A digital form that asks everything from everyone trains people to skip fields — and a skipped field is worse than a missing one, because it looks complete.

Ask each reader which fields they use, and what they do when one is empty. The answers usually shrink the form and add two fields nobody had written down.

What happens today when a field is wrong?

Walk through the correction, not the happy path. In most paper processes the repair is informal, and that informality is the process.

A wrong quantity is caught when the storekeeper counts the boxes at the door and writes the real number in the margin, with initials. A missing price is filled in later from a phone call. A customer who cannot sign makes a mark and the driver writes "refused to sign" beside it. None of this is on the form, and all of it keeps the business running. Digitise the fields and ignore the repairs, and you have removed the only mechanism that caught errors: the system now accepts the wrong quantity without complaint.

What does the signature actually prove?

It proves that a named person accepted the record at a moment in time, which is an accountability claim, not an accuracy claim. That distinction decides how to digitise it.

  • If it transfers responsibility — the driver is answerable for the delivery, the supervisor for the expense — the digital equivalent is a named account, a timestamp and a record of what was accepted. An image of a signature proves nothing extra.
  • If it is evidence to a third party — a customer disputing a delivery, an inspector, a bank — you need the artefact, and a photo of the signed sheet attached to the record is often the honest answer.
  • If it is decoration, a box the form always had, drop it.

The general principle is that a signature should be replaced by an identity you can verify, not by a picture of a pen stroke.

The field-by-field audit

Do this on paper, with the people who use the form, before anyone designs a screen — one field at a time.

Field What it decides Verdict
Quantity What is invoiced and what is stocked Keep, and validate against the order
Margin note The correction when a count is wrong Replace with an adjustment record
Signature Who accepted the delivery Replace with a named login
"Remarks" Everything the form did not anticipate Keep, but short and optional

The verdict column is the point. Most fields fall into four groups: keep, merge, replace with a rule, drop. A field nobody can justify belongs in the last group, and removing it is the cheapest improvement the project will make. Two tests help: ask what happens if the field is empty, and ask who would notice an error in it, and how soon. A field nobody checks will be wrong.

Why pilot on one form?

Because the audit finds the rules you can state, and the pilot finds the ones you cannot. One form, one team, one month, with the paper still running beside it.

Choose the form with the highest volume and the fewest exceptions, not the most important one: a mistake is cheap and the volume produces evidence quickly. Then compare time per form and errors that reach the next step. Keep the paper as the fallback for the whole pilot, and say so out loud — people tolerate a tool that might fail and resist one that pretends it cannot.

A decision procedure

  1. Pick one form. Not the department's whole paperwork — one sheet, with a name.
  2. Collect a few months of completed copies. They contain the real distribution of values: blanks, margins, corrections, initials.
  3. Interview each reader — filler, signer, checker, accountant — about the fields they use and what they do when one is wrong.
  4. Write the rules the form implies: mandatory fields, valid ranges, who may approve what, what happens when a value is out of range.
  5. Decide the signature question separately: identity, artefact, or nothing.
  6. Design the screen from the rules, not the paper's layout. Paper order is a constraint of paper.
  7. Run the pilot with the paper live, then compare errors and time before switching.

Accessibility belongs in step 6: labels tied to fields, errors described in text rather than by colour alone. The Web Content Accessibility Guidelines (WCAG) 2.2 state the requirements, and a form nobody can operate with a keyboard is a form people fill in wrong.

Where this goes wrong

  • The form is photographed into a PDF and called digital. Nothing is validated or searchable, and corrections still happen by phone. It is a scan, not a process.
  • The screen copies the paper's layout. Paper is arranged to fit a sheet and a pen; a screen can show the three fields that matter and hide the rest.
  • Every field becomes mandatory. The team enters placeholders to get past the screen, and the data is worse than the paper.
  • The exception path is left for phase two. If the tool cannot record "customer refused, left with neighbour", people use paper for exactly those cases and the system becomes a partial record.
  • Approval is assumed to be a button. A supervisor approving on paper took responsibility; a button with no named account and no timestamp is a click, not an approval.

What this does not cover

This is about one form and its rules, not the system the data lands in: a well-digitised form feeding a spreadsheet nobody reconciles is still a broken process. It does not cover retention obligations for signed originals, which depend on your sector, and it does not judge whether the process should exist at all: sometimes two approvals and a duplicate copy can simply go.

We digitise forms by first writing down the rules the paper was enforcing, then building the screen that enforces them.

Services in this article

Start a project

Have something to build?

One short brief is enough. You get a written scope and a fixed quote before anything starts.