Most business software starts with a request: "We need a system to manage X." The assumption is that X is well-understood, that the existing manual process is simply waiting to be digitized, and that the software just needs to replicate what is already happening on paper.
In my experience, this assumption is almost always wrong. The existing process is full of workarounds, exceptions, and undocumented steps that exist precisely because the manual system is inadequate. Mapping the surface process produces software that automates the wrong thing.
The spreadsheet trap
Before VetOps, the veterinary clinic managed appointments, patient records, and billing through a combination of a legacy desktop application, paper forms, spreadsheets, and sticky notes. When I asked how the appointment scheduling worked, I got a confident answer. When I watched the front desk for two hours, I saw something entirely different.
Spreadsheets and sticky notes were not failures of the existing system. They were features. They handled edge cases the legacy system could not: same-day add-ons, clients who walked in without an appointment, emergency cases that jumped the queue, reminders scribbled during a phone call. Any new system that ignored these real-world adaptations would simply create new workarounds.
Watch, do not ask
There is a difference between what people say they do and what they actually do. It is not dishonesty; it is that the workarounds have become so ingrained that they are invisible to the people performing them. The receptionist does not think of the sticky note as part of the workflow. It is just how things get done.
The most valuable design activity I do is observation. Sitting in the clinic, watching the front desk handle a rush, seeing the vet review a patient history between consultations. These observations reveal constraints and patterns that never come up in requirements meetings:
- Speed matters more than completeness. A checkout flow with five required fields will be abandoned. The receptionist needs to collect payment and move to the next client.
- Context switching is constant. The front desk answers phones, checks in clients, processes payments, and responds to staff questions simultaneously. The UI must support interruption and recovery.
- Paper is not the enemy. Vaccine certificates need to be printed and handed to the client. Digital-only workflows create friction, not efficiency.
Building for how work actually happens
VetOps was built around observed workflows, not abstracted requirements. The appointment screen shows a grid of time slots and available staff, but it also supports drag-and-drop rescheduling, same-day walk-in insertion, and a quick-search that finds clients by name, pet name, or phone number in under two seconds.
The checkout flow collects payment first and asks for optional data later. It prints a receipt and a digital vaccine card automatically. It does not block the receptionist from serving the next client while data syncs in the background.
None of these decisions came from a feature request. They came from watching someone do their job and asking one question: "What would make this easier for you?"
The lesson
Business systems fail when they optimize for an idealized version of the workflow instead of the real one. The real workflow is messy, exception-driven, and full of tacit knowledge that no one writes down. The only way to capture it is to go see it.
Every product I have built since — KitchFlow, VetOps, the systems at ButFor and PwC — starts the same way: watch the work, understand the constraints, and build around how the job actually gets done. The features come from the work, not the other way around.