Patient App — Layout & Navigation Overhaul

The Patient App is the screen physicians work in during every OPD visit: reviewing history, checking labs, writing notes, and placing orders. Years of feature growth had left it crowded — information scattered across the page, a left menu that kept growing, and core actions buried under clicks.

This project was a structural overhaul, not a feature add: re-lay the page, re-order the flows, and re-group the navigation — in roughly two weeks, with just enough research to de-risk each decision.

The work had two layers. The outer layer was the full layout and flow overhaul of the whole page. Nested inside it was a focused sub-study on the left-menu navigation — the hardest information-architecture decision, so it earned its own round of card sorting and testing. This case study zooms out to the system, then in to that deep dive, then back out to the final layout.

With two weeks, the sprint needed sharp edges. We defined success as measurable behavior change, not visual refresh:

How physicians actually worked through a visit: open last visit's history → review labs → write/print the OPD card — with some cases still handwritten on paper. Current screens were annotated end-to-end to trace where time went. Pain points were mapped to UX solutions across four areas:

Efficiency & Time. Heavy screens, information overload (e.g. Clinical Chemistry), slow scanning across a crowded page.

Data Visualization & Alert. No summary of "what's new to review", lab trends hard to see in context, missing alert color conventions.

Input & Action. Templates under-used, "Remed" placed far from the medication list, no "load previous session", saves fail silently when mandatory fields are missing.

Others. Frequently-used labs (Clinical Chem & Hemato) hard to reach, cost summary buried.

A time-boxed 30-minute workshop: sketch solutions on paper against the HMWs, present, vote, and let PD/PM arbitrate scope. Kept ideation cheap and fast — fitting the two-week constraint.

The left menu had grown item by item until it violated its own purpose:

Too many items to scan — classic Hick's Law territory. Icons ran out — custom icons everywhere, recognisable to no one. Hover-cascading submenus — fragile and easy to lose. No user memory — the menu never adapted to how a physician actually works.

Design questions we set out to answer: How should items be grouped? Does hover or click work better for submenus? Would shortcuts / favourites help? Can a panel listing all menus replace deep nesting?

First proposal grouped every menu item by the stage of a clinical visit:

A clean model on paper — but it was our mental model, not necessarily the physicians'. So we put it in front of users.

Three quick test formats, 10–15 minutes each, with 7 participants: card sorting (paper), a live menu test on the real system, and a prototype usability test — the menu validation run together with the design team. Physicians re-sorted the menu into a structure that matched how they think:

Physicians didn't think in process stages — they think in "what already happened, what I'm doing now, what I'm waiting on."

Same task, same physician workflow — different number of clicks and seconds.