The address, not the phone number

The form worked

Order creation on the platform did what the specification said. You searched for a customer, picked them from a list, filled in the order, and submitted it. Every field validated. Nothing errored. By any test we had written, it was done.

Then we spent a morning standing behind the counter watching pharmacy staff use it, and it became obvious that the search result was showing the wrong thing.

Why the phone number was the wrong identifier

The customer picker showed a name and a phone number. That is the natural choice when you are designing against a database, because the phone number is unique, stable and short. It identifies the record unambiguously.

It does not identify the person. Pharmacy staff were not trying to confirm they had the right row; they were trying to confirm they had the right delivery. Two patients share a surname, and what tells them apart is the address the medication is going to. Staff were selecting a customer, opening the order, scrolling to the address, checking it, and going back if it was wrong.

We swapped the phone number for the delivery address at the point of selection, and confirmed it again in the flow. The database did not change. The query did not change. The thing on screen changed, and a four-step check became one.

The field that filled itself in

The order had a required field called "Submitted by". It was free text. Every person using it typed their own name into it, every time, correctly, because they knew who they were.

A required free-text field whose value is already known to the system is not data capture. It is a toll. We filled it from the session user and made it read-only, which removed a field from a form that people complete dozens of times a day.

This is the least interesting change we made and probably the one that saved the most time.

The target nobody could hit

Opening an order meant finding a small icon button at the end of a crowded table row. Our own audit had flagged icon-only actions as a recall burden months earlier, and we had left it because it was correct: the icon had a label, the label was accurate, the control was keyboard reachable.

Correct is not the same as usable at speed. We made the whole row open the order and kept an explicit control for keyboard and assistive-technology users, because making a row clickable and calling it done would have moved the problem onto the people least able to work around it.

Nine findings, one release

The review produced nine changes worth making. We shipped them together rather than spreading them across a quarter of sprints, because individually each one is too small to be worth a release note and collectively they are the difference between a form people tolerate and a form they stop noticing.

What we would do differently is go and watch earlier. Everything in that list was findable in one morning at the counter, and none of it was findable from the specification, the ticket, or the test suite. The specification described the order. The counter described the job.