Auditing and Rebuilding an encounter page

MyPetCare was the first real product I worked on as a designer. It is a veterinary clinic management platform that helps clinics track patients, handle appointments, manage billing, and document medical records. When I joined as an intern, I was handed one of the most central features in the entire app: the Encounter Page.

An encounter is the full record of a single patient visit. It captures everything that happened during that appointment:

• Observations and vitals

• Diagnoses

• Treatments

• The handoff to billing

The structure existed. The SOAP framework was there.

But using it felt scattered:

• Treatment actions lived in their own separate panel

• The form was nested inside patient profile tabs

My job was to consolidate it. Make the experience feel like one coherent thing rather than several loosely connected pieces.

Everything a vet needed for a single visit should live on one page, in one flow.

This is the original design. The encounter form lived inside the patient profile page, tucked under an Encounters tab. A ‘Back to List’ link sat inside the tab, not at the top level of navigation. Treatment options were split into a separate panel on the right with six individual action buttons.

The biggest structural change in this redesign was splitting what used to be one crowded page into two distinct ones. The encounter list became its own page, a place to find and manage records. Selecting a visit takes you to a completely separate documentation page where the patient profile tabs disappear and the vet just has the form.

The original sidebar was a single list of eight items with no hierarchy. As the product grew, more items kept getting added to the bottom. It worked when the app was small but became harder to parse as the feature set expanded.

Now that the encounter list had its own dedicated page, it made sense to treat it like a proper data table rather than a minimal embedded list. I took cues from patterns like Shopify’s admin tables: search, status filters, a total count, and a dedicated action column. These conventions exist for a reason. Vets and clinic staff already know how to use them.

For fields like weight and temperature, the original design used placeholder text to communicate the unit. The moment a vet started typing, the ‘kg’ or ‘°C’ disappeared. In a clinical setting where the wrong unit can mean something serious, that is not a small problem. Keeping the unit pinned outside the input, always visible, removes any ambiguity.

This page changed the most. The SOAP form now has the entire screen to itself. No patient profile tabs above it, no navigation context pulling focus:

• The patient card at the top

• The SOAP sections below

• The treatments sidebar to the right

This is what it looks like when documentation gets its own space.

I designed the initial version, then handed it to a senior designer who refined it into what shipped. My starting instinct was to strip things back: fewer cards, more breathing room, closer to an Apple-style layout.

• Part of that was aesthetic

• Mostly it was about scalability

  • The fewer nested containers I introduced, the less this page would fight me when it collapsed to mobile

We went back and forth on components and on what this screen was actually responsible for. It was never just SOAP notes. Treatments and billing lived here too, so the open questions were:

1. How do final payments surface?

2. How do you display multiple products under a single service?

3. What information earns a spot on the screen and what doesn’t?

The clearest change was swapping the To-do panel for a Last Encounter summary. A to-do list felt redundant on a page you’re already inside of. You’re doing the task, so why show it back to you? What a vet actually needs at that moment is context:

• What happened last visit

• What was prescribed

• What’s overdue

That’s the information that explains why this checkup is happening.

I stayed away from proposing new functionality, since I was an intern and scope wasn’t mine to expand. But sitting next to a designer who could translate all of this to the dev team, watching how she framed constraints and articulated tradeoffs, was the part I learned the most from.

Sign & Finalize turns the encounter into a legal medical record. Three things change at once:

1. Fields go read-only

2. The draft notes become a finished summary

3. The button changes from Save Draft to Proceed to Checkout

I did the first version of this state and my senior reworked it. My version just kept the Treatments card from the editing screen, services listed, no total. But once a record is signed the vet isn’t reviewing treatments anymore, they’re collecting payment. So the final leads with a Payment card:

• Line items, a total, and a Not Paid badge, sitting directly under the checkout button

• Prescriptions linked to the bill, showing the same three meds twice

  • With prices under Payment

  • With prescriber and sig under Prescriptions

What the client pays, and what they need to know at home.

The products-inside-a-service problem was the one we kept circling. Antibiotic Injection uses Product A ×2 and Product B ×1, one of them free. Indenting them under the parent line was what finally made it read as one service instead of four separate charges.

My senior also caught the copy. I’d written “Sign And Finalized” and “Go to Billing”. Her notes:

• Billing is a place, not an action. E-commerce doesn’t put you on a button labeled Billing, it says Checkout

• Buttons start with verbs; status labels describe what already happened

So it became Signed & Finalized and Proceed to Checkout.