EYThe LogEmre Yakut
← all entries
Field · Systems

Let them fill in the decision, not the form

Writing the request form for an inspection laboratory, I realised something: people do not know the answer to “which inspection type do you want?”. They do not need to — the system can work it out.

Emre Yakut 3 min read works/termolab
talep tek giriş sayaç tipi? ısı · su ilk muayene yeni sayaç periyodik 10 yıl / şüphe ölçüm planı TÜRKAK AB-0606-M her adım tek soru sorar — cevap bir sonraki soruyu belirlerkullanıcı formu değil, kararı doldururmevzuat dalları veriden değil politikadan gelir: koda gömülmez, tabloya yazılır

Termolab is a heat meter inspection laboratory. It is accredited, its scope is defined, and who applies when is set by regulation.

Rebuilding the site, the critical piece was not the home page — it was the request form. The form is the door to the business. Every badly filled request means a phone call and two days of delay.

The wrong question

The old form opened with this:

Inspection type:  ( ) Initial
                  ( ) Periodic
                  ( ) Complaint
                  ( ) Stock

A correct question asked of the wrong person. A building manager or a plumber does not have to know which regulatory scope their meter falls under. They only wonder “is this meter due?”

A good form asks the user what they know and calculates what they do not.

What they know: the manufacturing year

Two things are printed on the meter: its type and its year. Both are readable. The rest is arithmetic.

the periodic inspection window
inspection_year = manufacture_year + 4 · apply: January–February

A meter made in 2021 is due in January–February 2025. The user types “2021”, the system says “overdue”, and the box turns red.

By the end of five steps the user has not selected a single regulatory term. The system determines the correct scope itself and shows one of three states:

  • overdue — red, “apply now”
  • approaching — amber, “your window is opening”
  • not due — green, “next inspection in this year”

The third one matters most: letting the system say no. A form that filters out unnecessary applications at the door makes the laboratory’s job easier too.

Regulation does not belong in code

These calculations invite an if ladder. I did not write one.

The reason: these rules do not come from the data, they come from policy. The period is five years because the regulation says so. Tomorrow it could be four. A new nominal diameter could enter the accredited scope.

A rule buried in code makes every change a release. A rule in a table makes it a row update.

the distinction

Measurement is data: what the meter reads. Policy is a decision: when it must be inspected. The second is never derived from the first. Putting them in the same layer is a mistake I keep seeing on the billing side too.

Documents are the host, not a guest

On an accredited body’s site, documents are not decoration; they are why the visitor came. Twenty-one PDFs — ten accreditation and authorisation certificates, eleven regulatory texts — are all hosted locally, with no external links.

The reason: an external link breaks eventually. Tying corporate documents to the uptime of a server you do not control is a bad idea.

And a small bug

what I found

A count-up animation was rendering the accreditation year with locale formatting: 2021 → “2.021”. A thousands separator is meaningless for a year. I removed the animation.

Moving a number is not worth showing it wrongly. When formatting a number you have to know whether it is a quantity or an identifier.

What I learned

Form design is not about reducing the number of fields. It is about reducing the number of decisions.

Taking five pieces of data and making three decisions for the user beats taking three and forcing five decisions on them — even if the form looks longer.

FieldSystems