Vet Clinic OS

A veterinarian in a small practice sees ten to twenty patients a day. The clinic’s software is opened before the appointment and after it, and never during: while the patient is on the table, the record lives in a paper notebook. The first reason for the notebook is not privacy, it is physics — she writes with one hand, standing, because the other one is holding the cat.

Everything after that is a transfer between tools: seven of them in one appointment, two of the same number — the weight goes into the system, then by hand into a dose calculator on her phone. That is where her one real near-miss came from: a decimal point moved by hand, caught by her and by nothing else. Services reach reception by voice — “put down two hundred, I’ll clarify later” — and are not clarified. The record itself is written at home at nine in the evening, part of it from memory.

The cost of that is not paperwork. Thursday’s appointment was never entered, so on Saturday a colleague sees the same cat, finds a last entry a year old, examines from scratch and nearly prescribes a second anti-inflammatory on top of the first. What stopped it was a phone call answered on a day off. The system was no part of the safeguard, because it did not know the visit had happened.

The brief asked for faster closing of visits, and the metric behind it was the share closed in the system on the day of the appointment. Both are reasonable, and the person they were written for took one sentence to show they were wrong.

“The previous patient hasn’t left yet and the next one is already in the room. I have a choice: sit down and enter it, or smile at the next one. I always smile at the next one. Twelve times a day.” A product that asks for the whole record inside that window does not get half a record. It gets postponed whole — which is exactly what the current one does.

So the object the system has to hold is not the closed visit. It is the trace: the smallest record worth having — weight, drug, dose, one line of free text — made in seconds, visible to a colleague immediately, completed later without being overwritten. The measure moves with it: not completeness by the end of the shift, but whether a trace exists by the time the veterinarian leaves the room.

This clinic was not coming from paper: practices of this size already run specialised software, so the product had to beat an incumbent rather than replace a filing cabinet — which makes it the only hard evidence there is. I audited it screen by screen against heuristics, with a severity scale that keeps “blocks the work” apart from “looks untidy”, and with a limit written into the report: the veterinarian’s own visit screen, the schedule and the owner cabinet were not in the material I had, and no conclusions were drawn about them.

Then desk research on the market and on the regulation around veterinary records. Three of its numbers could not be traced to a primary source, so they were marked unverified and kept out of the PRD rather than rounded into it. Everything the conversations could not confirm carries the same mark and stays a hypothesis for real customer development — including the two that changed the product, because a hypothesis that flatters your redesign is still a hypothesis.

Then scope: 31 Must-haves out of 62 requirements, with the core of the appointment declared indivisible — seven parts that ship together or not at all. Then a 44-screen sitemap, three flows, twelve low-fidelity frames. Then the design system, then twelve high-fidelity frames carrying one story end to end, from the queue to the discharge summary on the owner’s phone, with 31 edge cases built as hidden states instead of described in prose. Then a React prototype, a catalogue in Storybook, and synthetic agent runs over three scenarios, whose findings came back in four waves of fixes.

Booking. A free slot in the schedule created a visit with no patient, no owner and no reason — a record that exists and says nothing, in a product whose whole argument is that a record must be worth having. The scenario was in the sitemap; the screen for it was in neither the design file nor the specification. It appeared first in the prototype and had to be registered there as prototype-only: the design source and the build had diverged quietly.

Saving. The workspace showed the save status twice — once in the header, once in the side rail. On a product whose one dealbreaker is a lost draft, two indicators of the same fact is the defect you can least afford: the first time they disagree, neither is believed again. The fix was not to make them agree. It was to delete one.

And that deletion was not finished when the thing was gone. The rule pinning the save status to the bottom of the rail stayed behind, took the navigation as its new last child, and slid every menu item down into an empty column. The screens passed, the build passed, nobody saw it. I found it weeks later, shooting the frames for this page — a screenshot has no opinion about which part of a rail you meant to look at.

Eighty-five variables — 54 primitive, 31 semantic — 21 text styles, 31 logical components, 136 variants. Every fill and stroke resolves through a semantic variable and every text node through a named style. A full read-only scan, not a sample, found zero hardcoded colours, zero text nodes without a style and zero detached instances; the thirty geometry values still unbound are listed as debt, not hidden behind a claim of parity.

The one I deleted is the card container: three variants, zero instances anywhere in the product. A component carries exactly the anatomy it was created with, and this one had a title and a single row, while the real blocks here need two to five elements, several of them nested instances. Keeping it “for later” would have meant every screen quietly working around it, which is worse than not having it.

Coverage is not checked by eye: a script walks the catalogue against the variant matrix, and the states below are shot from the catalogue, not assembled by hand.