The Interface Layer, part 4: forms, the human interface

The first three chapters were about seams between systems. This one is about the seams between people and systems, and every company has a name for those: forms. The supplier registration form, the expense claim, the onboarding packet, the service request, the order entry screen. They are the interface layer's other side, and they carry the same hidden cost with an extra ingredient. People hate them, and the hatred is deserved.

What a form actually asks of a person

A form is the user interface of the deterministic era. It is a system declining to do any judgment and asking the human to do all of it in advance: read the document you hold, find the twelve values the system wants, translate each into the system's vocabulary, type them in the system's order, and satisfy validation rules whose logic you cannot see. The form asks for the tax id that is printed on the invoice in your hand. It asks for the address the company already has from last year. It has no memory of the last time you filled it. When you get something wrong, it answers in red.

The hidden costs follow directly. Abandonment: the customer who closes the tab, the supplier who "will send it later". Fake data typed to satisfy validation: the date that is always the first of January, the field that says "n/a" because the form would not proceed without it, now permanent in the record. The phone call after the form: because the form could not ask a follow-up question, a person has to. And the same key-person problem as chapter 1: the one employee who knows how to fill the form correctly, because the form's real rules were never written anywhere.

Inventory the forms

The audit from part 1 extends naturally. List every form, internal and external. For each, write down: who fills it, how many times a month, how long it takes, how often it is abandoned or comes back wrong, and, the column that matters, which of its fields already exist in a document the person holds. For a supplier registration, nearly all of them exist on the company's registration certificate and its first invoice. For an expense claim, they exist on the receipt. For a service request, they exist in the email that prompted it.

That column tells you the shape of the replacement. A form whose fields all exist in a document is not a form; it is a transcription seam wearing a user interface.

The intake loop

Drop what you have. A document, a photo of one, a forwarded email, or a sentence. The person gives the system what they actually possess, in the form they possess it. Nothing is pre-structured by a human.

Extract and resolve. The fields come out of the document by parser where it is structured and by reading where it is not. Then the same resolution as chapter 2: is this supplier already known, does this employee exist, which project is this claim against. The system fills what it can and knows what it could not.

Ask only the gaps. Two or three questions, in the person's words, about the things no document could have said: which department, which of two matching projects, whether the delivery address is the same as last time. A rule with no exceptions: never ask what the document already said. Every question that breaks that rule teaches the person the system did not read what they gave it.

Review. The form does not disappear. Its job changes, from input surface to review surface. The person sees it prefilled, each value carrying a small marker of where it came from, corrects the one thing that needs it, and confirms. This is the confirmation boundary from chapter 2 applied to the human side, and it answers the power users who genuinely prefer a form: they get one, already filled, with a keyboard.

Record. Validation runs exactly as before; the form's rules encoded real constraints and they stay. What goes is the typing, the translating, and the follow-up call.

The schema stays; the labor goes. That sentence is the whole design.

Which tier does the work

Intake is one of the cheapest interface-layer jobs per correct record, because most of it is the bottom tiers. A parser reads the structured document. A small model classifies which intake this is and extracts fields from the semi-structured ones. Validation is deterministic and already written. Resolution against existing records is a lookup plus a small model for the ambiguous cases. The strongest model appears in two places only: the gap conversation, which must sound like a person and handle whatever the person answers, and the genuinely ambiguous document. The push-down rule from chapter 2 applies unchanged.

Designing the gap conversation

This is where intake succeeds or becomes a worse form.

• Fewest questions. If the system needs five answers, the extraction is not finished; go back and read harder before asking.
• The person's vocabulary. "Which team is this for?" and not "select cost center code".
• Accept any shape of answer. "The Cluj warehouse, like last month" is a complete answer; the system resolves it.
• Show what was understood before asking the next thing, so a wrong extraction is caught at question two rather than at review.
• Correct inline. If the person says "no, the other Popescu", the system fixes it and moves on, without restarting.
• End with the whole picture. The last step is always the prefilled form, visible, before anything is recorded.

External intake

The same loop works for people outside the company: a link sent to a new supplier, a new hire, a customer with a request. "Drop your documents here and answer two questions" replaces the forty-field page, and the abandonment rate is the first number to move. Three things matter more outside than inside. Provenance is shown to the submitter too, so they see what the system read from their document and can fix it themselves. Purpose and retention are stated plainly: what the documents are for, how long they are kept. And a plain form remains available as a fallback, because some people, devices, and situations want one, and forcing the conversation on them is the old mistake in new clothes.

Which forms to keep

Some forms should stay forms, and knowing which is part of the discipline.

Tax and regulatory declarations. The structured view is the safety. The fields have exact legal semantics, the person must see exactly what is being declared, and the form is the audit artifact. Intake can prefill it; the form remains the surface.

Attestations and signatures. "I declare that the above is true" is not data entry. It is an act, and the form is how the act is recorded.

High-volume entry by experts. A person who keys two hundred order lines a day from memory is faster on a keyboard than in any conversation. Give them prefill and shortcuts, not a chat.

The rule that follows: replace intake, keep attestation. If the form's purpose is to collect information a document already contains, replace it. If its purpose is for a person to commit to something, keep it and make it shorter.

Measuring intake

The numbers from part 3 apply with small renames. Completion rate, against the old form's abandonment. Time to complete, submitter side and reviewer side. Fields corrected at review, per field, which is the extraction precision in disguise and tells you exactly which field to fix. Follow-up contacts per submission, the calls and emails that used to happen after the form. And escapes: wrong values that reached the record, counted and traced, as always.

Rollout

Start inside, with one intake where the documents already exist and mistakes are cheap. Supplier onboarding is close to ideal: the registration certificate and the first invoice contain almost everything, the person doing it today is easy to find, and a wrong field is caught at the first payment. Run it in shadow: the old form stays, the prefilled version sits next to it, and you compare for two weeks. Then assisted, then the external link. Expense claims and service requests follow the same path. Two to four weeks per intake with a willing owner, the same pace as a seam.

The interface layer has now been described from both sides: between systems, in parts 1 to 3, and between people and systems, here. What remains is the practical question every Romanian company asks at this point: with the state's e-invoicing, reporting, and transport mandates already in place, where does one begin? That is part 5.