All case studies6 min read
UX Case Study · Healthcare · Clinical Software

MEDH Clinic Management System

A UX Case Study in Clinical Decision-Making

RoleLead UX Designer
Sole designer on the product
LocationSingapore
DurationJun 2019 – Jan 2020
Seed Funded · Full Build Greenlit
01 / 13Results

A greenfield clinical product built from research with practising clinicians, not screen documentation. I was the only designer across six months of research, decisions, and trade-offs — partnered with a Singapore-based clinical SME for domain expertise and on-the-ground research access.

Outcomes

The Results — Measured, Not Estimated

Measured across 20 users from 2 clinics, over 1 week of remote moderated testing. Prescription time was also reduced from a clinician-reported ~5-minute baseline.

5%Staff Error RateReduced to 5% across all critical flows
94%Task SuccessAcross all critical flows
3×Faster Condition Entry8s vs 23s — body map vs dropdown
4/4Doctors Preferred MEDHOver their current tool
The investor demo was approved and the full build greenlit — seed funded.
Context

The Problem: Small Errors, Inevitable at Scale

Singapore has 2,200+ GP clinics. Most run on paper, memory, and a shared desktop from 2012. MEDH already owned a hospital product and wanted to expand into this underserved clinic market — starting from zero.

Scoped as a SaaS product from the outset — in discussion with the SME, designed to be redistributed across many clinics rather than built for a single site.

The errors this market produced weren't dramatic — a duplicate bill, a missed follow-up, the wrong patient file. Small, invisible, accumulating. In a high-volume, low-staff clinic they were inevitable, not exceptional. That was the real problem to design against.

2,200+GP Clinics in SingaporeLargely underserved by modern software
0Starting PointGreenfield product, no existing design
1Designer on the TeamSole UX designer across the full engagement
Research

Research: From "What to Build" to "How It's Really Done"

This was the earliest stage of a brand-new product, so I sequenced the research to move from what to build to how the work is actually done today.

Stage 1 — Stakeholder InterviewsI started with the people funding and shaping the product, to understand expectations and business context: what a clinic actually is, how it operates, and what success needed to look like.
Stage 2 — Generative ResearchWith that grounding, I ran remote interviews with clinic doctors and staff, walking through how the work is done today — surfacing the friction, workarounds, and error points that shaped every later decision.
Findings

The Insight That Reshaped the Product

I worked with four users across two clinics — two doctors and two clinic staff.

A clear daily rhythm surfaced in the interviews: a morning rush, lunchtime queues, and a scramble at closing — two assistants juggling 40–60 patients at once, a doctor seeing someone every 6–8 minutes, prescriptions written by hand then retyped into a legacy system.

The insight that changed the product: both doctors described starting to type mid-consultation, feeling the patient disengage, and abandoning the computer entirely. The breaking point wasn't the software — it was the physical gesture of reaching for a keyboard. That single insight drove five downstream decisions.

DoctorsNeeded flow protected — "When I type, the patient thinks I'm not listening."
Clinic StaffWeren't inefficient — they were systemically overwhelmed, every task crossing three tools. Their real fear: giving the wrong medication to the right patient.
User Research

Three Relationships With One System

Surfaced through the doctor and staff interviews — each group defined "working" differently, and designing for one without the others would have broken the whole.

Doctors — "Don't break my flow."Consultation is a performance of attention. Their natural instrument is a pen; the system had to honour that physical reality, not fight it.
Clinic staff — "Help me not make a mistake today."Managing 50 patients with 2 people isn't about efficiency — it's survival. Their biggest fear: giving the wrong medication to the right patient. Error prevention wasn't a feature; it was the product.
Patients — "Stop asking me to repeat myself."Every visit restarted from scratch: name, DOB, allergies, medications, reason for visit. The system needed to remember patients so staff didn't have to ask.
Design Principles

Four Principles I Held Every Decision To

1
Error Prevention Over RecoveryIn a clinic, recovering from a medication error is a safety event.
2
Match the Real WorldDoctors think in handwriting and anatomy; staff think in queues.
3
Recognition Over RecallNo field asks a user to remember what they haven't already seen.
4
Progressive DisclosureToday's context by default, depth one tap away.
Signature Decision

The Signature Decision — Stylus Over Keyboard

How it played out

The conflict. Engineering argued handwriting recognition was risky and would blow the timeline; the safe option was structured forms with autocomplete.

The reframe. I changed the question from "can we build handwriting recognition?" to "will doctors use this at all if we don't?" — and played the research recordings in the meeting: two doctors, two accounts of abandoning typed input mid-consultation.

The resolution. A three-tier input hierarchy. It satisfied both sides — engineering got a buildable deliverable simpler than full OCR, and doctors kept their pen.

In testing, a GP who'd refused digital tools for 15 years completed the prescription flow unprompted, then asked when it would be available.

The Three-Tier Input Hierarchy

1
Primary PathFreehand stylus annotation on a canvas — no OCR required.
2
Secondary PathA blank sheet for longer handwritten notes.
3
Last ResortStructured typed fields, mostly for staff.
Key Feature

The Body Map — A Decision I Could Prove

I replaced dropdown condition codes with a tappable body silhouette: tap where it hurts, and the map surfaces conditions for that area while showing existing conditions as dots. In a within-subjects test (same 20 users, randomised order), the difference was decisive.

8sBody MapAverage time to enter a condition using the tappable body silhouette
23sDropdownAverage time using the legacy dropdown — nearly 3× slower
Doctors called the dropdown "like filing paperwork" and the body map "like showing me the patient."
Design Decisions

The Reasoning Behind Every Screen

Persistent Allergy BannerOn all 10 patient-record tabs — rejecting the industry-standard dedicated-tab approach because it made safety opt-in. In testing, users paused and flagged a planted drug conflict without being prompted.
Billing Integrated Into the Clinical RecordClinic staff described disconnected billing as a recurring source of daily errors, so line items generate from diagnosis and prescription rather than being re-entered by hand. It removes an error source, not just a workflow step.
5-Tier Alert SystemNamed directly from staff's existing mental model, to prevent the alert fatigue of a binary flag.
Role Selection at LoginTo stop wrong-context errors on shared devices.
Product Scope

What Was Built — MEDH v0

ClinicalPatient records (10 tabs), diagnosis + prescription, body map, persistent allergy banners, stylus annotation
OperationalMulti-doctor calendar, queue integration, patient registration, role-based access
FinancialVisit billing with GST, multi-payment, insurance auto-application, corporate invoicing
CommunicationsEmail + notes, referral letters, MC generation, letter templates
Supply ChainInventory with pricing schemes (CHAS / NTUC / AIA), batch tracking, expiry, recall, purchase orders
IntelligenceSales analytics, patient demographics, 5-tier alert system

User Interface

Selected screens from MEDH v0.

Reflection

What I'd Do Differently Next Time

Research the Business-Model Layer EarlierI treated clinic types too uniformly — GP, specialist, polyclinic, and TCM have different staffing, billing, and regulatory realities.
Fight for One Live Clinic Pilot Before Prototype TestingRemote sessions and simulated tasks can't reproduce a 9am Monday rush with 60 people in the queue.
Keep a Design-Decision Log From Day OneA future engineer shouldn't have to guess why the allergy banner lives on every screen.

Where This Experience Applies

HealthcareDeep domain experience designing for clinical workflows and patient safety in high-volume environments.
ProductGreenfield to funded — end-to-end ownership of research, strategy, and interaction design.
B2B SaaSDesigned for redistribution across many clinics — multi-role, multi-context, error-critical environments.

Like how I work? Let's build the next one.

You've just read how I think — the research, the trade-offs, the decisions I defended and the ones I'd make differently. I'm open to Lead and Senior Product Designer roles, remote, hybrid or in-office. Tell me what you're building and I'll tell you where I'd start.

UXUXChronicle

Lead Product Designer turning complex systems into clarity. 13+ years, 11+ products shipped.

Open to Lead / Senior Product Designer roles
© 2026 Huseini IndorewalaCurrently reading: Refactoring UI
Indore, India · IST (UTC +5:30)