Designing a clinic-management system around real clinical work
A greenfield healthcare SaaS product for Singapore clinics, shaped by how doctors and clinic staff already work.
The Outcome
MEDH was a greenfield clinic-management product designed around a simple reality: doctors need to stay focused on the patient, clinic staff need to manage high-volume operational work without introducing avoidable errors, and safety-critical information cannot be hidden behind extra steps.
I owned the UX design direction across research, problem framing, information architecture, core flows, interaction design, wireframes and UX decisions. A junior designer supported parts of the UI / visual design.
Investor demo approved · Full build greenlit · Seed funded
The Problem
MEDH wanted to expand from its existing hospital product into the clinic market with a new clinic-management SaaS product.
The challenge was broader than designing individual screens. The system needed to support multiple roles and connected workflows across:
The source case study describes repeated friction in clinic work: duplicate billing, missed follow-ups, wrong-patient risk, medication-related mistakes, repeated data entry and switching between tools during a consultation. The core UX challenge became:
How can the system support clinic work without becoming another source of interruption or error?
Research → Insight → UX Direction
Because MEDH was greenfield, research happened before the interface was defined. I started with stakeholder interviews to understand the business context and product expectations, followed by generative research with 4 users across 2 clinics — 2 doctors and 2 clinic staff — to understand consultations, documentation, prescriptions, operational work, workarounds and error points.
When I type, the patient thinks I'm not listening.
A recurring issue was clinical documentation. Doctors described how moving from the patient to a keyboard disrupted the consultation.
That changed the design question from "How do we make digital form entry faster?" to "How can the system support clinical documentation without forcing the doctor to abandon the way they naturally work?"
The resulting design logic
| Research signal | UX direction |
|---|---|
| Typing interrupts the consultation | Stylus-first input |
| Doctors think about symptoms through anatomy | Body map |
| Safety information can be missed when buried | Persistent allergy banner |
| Staff work through different levels of urgency | Five-tier alert system |
Other documented system decisions: role selection at login established working context on shared devices; clinical-to-billing line items connected clinical and operational work.
Designing Around Real Mental Models
The strongest design decisions came from translating existing clinical and operational mental models into digital interactions.
Stylus over keyboard
Typing interrupted consultation, while handwriting was already part of the doctor's workflow.
Engineering raised a legitimate constraint around handwriting recognition and OCR. I reframed the problem: Will doctors use the product if we remove the pen?
That led to a three-tier input hierarchy:
The solution preserved the physical interaction without making OCR a dependency.
Body map instead of generic search
Doctors described symptoms through anatomy, so condition entry followed the same mental model:
The interaction was designed around recognition rather than recall.
Safety as persistent context
Allergy information was treated as safety-critical context rather than something users should remember to look up. The allergy banner therefore remained visible across the patient-record experience.
Operational urgency
Staff did not think about work as simply urgent / not urgent. The dashboard represented five levels:
The intention was to reflect the operational mental model rather than flattening everything into one alert state.
Structuring a Complex Product
The breadth of MEDH required more than a single clinical flow. The documented product structure covered:
Within the patient experience, the IA also needed to preserve clinical context across multiple tabs without hiding safety-critical information.
From UX Structure to Product Interface
My UX contribution shaped:
The final interface was team output, with the junior designer supporting parts of the UI / visual design.
Selected product areas included: Patient records · Dashboard · Appointments · Inventory · Stock management · Corporate · Communication
The final product connected clinical work with the operational tasks that followed it rather than treating each area as an isolated screen.
What Was Established
The investor demonstration was approved and the full build was greenlit. The product was also seed funded. The project established a coherent clinic-management system around evidence-grounded UX decisions:
Post-launch business outcomes such as productivity improvement, adoption, revenue impact or reduced clinic-wide errors were not established in the documented case study, so they are not claimed here.
Reflection
I would push for a live-clinic pilot earlier. Remote research and simulated tasks helped expose important interaction problems, but they cannot fully reproduce a busy clinic environment with interruptions, queues and simultaneous operational demands.
Interested in the long version?
This is the short read. The full case study goes deeper into the stakeholder and clinic research, the stylus and body-map decisions, the information architecture, the validation sessions and the trade-offs behind each choice. Email me and I'll send it over.