Web health information system for BMA public health centres, front and back office
Overview
PHCIS is the Primary Health Care Information System for the Bangkok Metropolitan Administration (BMA) Health Department: the web platform staff use to run a full outpatient visit at public health centres. It sits at the centre of a three-product ecosystem with a patient Mobile App and a self-service Kiosk, all built on one design system.
Scope: 19 systems (feature areas) built as 45 functional modules · 425 web screens · 49 staff roles · 16 specialty clinics · 78 reports and dashboards.
My role & team
Freelance Lead UX/UI Designer (May–Nov 2026 · almost done, UX/UI wrapping up by the end of November 2026). I own around 80% of the HCIS product surface, from client requirements and TOR mapping through Figma foundations, vibe-coded prototypes and developer hand-off. I work directly with physicians, nurses, pharmacists, finance officers and the committee working groups, alongside business analysts and developers. I started all three products from scratch, setting up the UX/UI foundations for a highly complex system, and took requirements directly from physicians, nurses, pharmacists, finance officers and committee working groups. I also worked as the business-analysis bridge for the BA and development team. I lead a three-person UX/UI team: myself and two UX/UI designers.
Problem & context
The project is defined by a government TOR, so every screen has to trace back to a written requirement and a committee decision. A single visit moves through many departments, each with its own rules: eligibility under NHSO, SSO and CGD schemes, e-Claim, pharmacy-to-finance gating, PDPA privacy rules across centres, and telemedicine. The team needed one shared picture of the journey, and a timeline measured in months, not years.
Timeline: work began at project kickoff in May 2026, in Figma, with the initial designs, the Design System and design tokens. During kickoff requirement-gathering, many workflows surfaced that were not specified in the TOR, a substantial increase in scope. Management decided to include them anyway, which left only about two months to revise and deliver across every platform and module.
Goals
Cover the TOR fully and make progress visible to the client at any time.
Give BAs and developers flows and rules they can build from without guessing.
Keep 400+ screens consistent through one design system.
Shorten the feedback loop with clinical users from weeks to days.
Business goal & measurement
Business goal: BMA wanted to reduce staff workload, cutting time spent on non-essential tasks so staff can give their full time to patient care.
How we measure it: I designed time-tracking into the workflow itself. In the worklist, selecting a patient opens a pop-up to accept them into care, and finishing a step ends with a hand-off to the next station. Each of these actions is timestamped, so the system can measure how long each step actually takes. Because working time varies by clinic and by role, the data is compared like-for-like per clinic, giving BMA a real baseline to check whether the new system actually reduces workload after launch.
Process
Requirements & research: took briefs directly from clinical and finance staff and working groups, presented every iteration and logged 320+ product decisions.
TOR mapping: built a TOR compliance checklist where each requirement is marked done, partial or missing, checked first by AI and then by a person, and linked to committee resolutions.
IA & flows: mapped the end-to-end patient journey (Kiosk check-in → Registration → Triage → Screening → Doctor examination → Post-exam nursing → Pharmacy → Finance & cashier), supported by Queue, Appointment, Consent and System administration. Each step was delivered as user flows, service blueprints and journey maps for BA and Dev.
Design system: designed on the MIH Design System, with tokens shared with the Mobile App and Kiosk.
Figma first, then code: from kickoff, we worked in Figma on the initial designs and set up the Design System and design tokens there.
Leading the switch to vibe coding: once the scope grew beyond the TOR and the delivery window shrank to about two months, I led our three-person UX/UI team to skip the Figma step and move fully to vibe coding with Cursor and Claude Code, revising and building directly in working code. Clinical users reviewed working screens, which cut client feedback cycles from weeks to days.
AI persona usability testing: with the timeline this tight, there was no time to run usability testing with real users, so I built an AI usability-testing skill that role-plays the people each feature serves: doctors, nurses, staff, service recipients (patients) or the general public, depending on the feature's context. For the staff system, that mostly meant clinical and back-office roles. This is not a substitute for real-user testing, which is planned as a next step after launch.
Flows and service design for the BA: in parallel with the build, I created user flows and service design to communicate with and support the BA, including the business logic. Because the committee saw the prototype as the real system, the build includes real logic and alert conditions.
Hand-off: developers connect through GitHub, where we share design.md and the AI memory (project context) so the dev team can continue from where design stopped. Also delivered as code, screen manifests and per-screen hand-off packets, with BA-ready rule documents (e.g. consent-form display conditions, an alerts and notifications registry).
Business analysis contribution
Beyond design, I extracted the exact business logic from requirements and committee decisions and wrote it as rules that BAs can confirm and developers can build. Rules are documented at a general level; no patient data is used.
Alert display conditions: catalogued every alert in the system (blocking dialogs, in-page alerts, toasts, success pop-ups and bell notifications), each with its trigger, recipient, channel, severity and status (working, simulated or still missing), so BAs confirm each one before it goes to development.
Drug-interaction rules: a three-level model. Fatal interactions block the order until a physician or pharmacist unlocks it with a recorded reason; serious interactions show a pop-up that must be confirmed with a clinician code; non-serious interactions are allowed, with advice carried onto the drug label.
Station-to-station routing: drug orders are routed from clinic to pharmacy by a priority list of rules (TOR 1.17.3). The first rule that matches wins, a backup pharmacy is used when the target is closed, and anything unmatched falls back to the central pharmacy. Drug categories (general, controlled, cold-chain, chemotherapy, special preparation) drive the routing.
Patient-flow logic: branching across the visit for new vs returning patients, appointment types, special clinics, consultation vs referral, kiosk failure fallback, and payment gating before pharmacy, including a bypass where several services are paid once.
Name-icon conditions: which status icons appear after a service recipient's name, when each one shows, and on which pages, with a change history that records the reason for each rule change.
Consent-form display conditions: rules for 54 consent forms, filterable by task and condition and exportable to Excel, defining when each form must be shown or signed.
Clinic registration rules: which clinics and roles can register patients and which need a registry number.
Key design decisions
Prototype in code, not only in Figma: clinical users reacted to working screens, which made decisions faster and more concrete.
One journey, many lanes: service blueprints show who acts at each step (patient, front office, back office, system), so edge cases surface early.
Privacy by default: patient identifiers are masked in worklists and revealed only when needed, in line with PDPA cross-centre rules.
Docs generated from the product: flows, alerts and rules update from the codebase so documentation never drifts from what is built.
Outcomes & impact
Business impact: ~96% of 684 TOR requirements delivered across web, mobile and kiosk within a roughly two-month crunch by a three-person UX/UI team; client feedback cycles cut from weeks to days; built-in timing data ready to measure workload reduction after launch.
Across the overall project (May–Nov 2026), 684 TOR requirements delivered across 32 systems and 190 modules (~96% complete), with the workflows added beyond the TOR absorbed in a roughly two-month delivery crunch.
510+ screens on one design system across the ecosystem, 425 of them in PHCIS web.
320+ product decisions documented and traceable.
Learnings
The scope grew well beyond the TOR at kickoff, and management chose to include the new workflows, so we had about two months to revise and deliver every platform and module. Keeping the Figma step would not have fit that window, so I led our three-person UX/UI team to skip it and move fully to vibe coding with Cursor and Claude Code. That process change, more than any single tool, is what let us absorb the extra scope within that window.
Design delivered as working software also raises expectations. The working committee of doctors, nurses and staff saw the prototype as the real system, not as UX/UI screens, so business logic and alert conditions had to be designed and built in from the start. And when the design lives in code, documentation becomes the hand-off: design.md and the AI memory shared through GitHub let developers continue from where we stopped, while user flows and service design kept the BA aligned on the logic.
Skipping real-user testing was a deliberate trade-off, not an oversight. An AI usability skill playing doctors, nurses and staff caught obvious friction early and cheaply, but it cannot replace the people who use the system every day, so testing with real users comes next, after launch.
Project almost done; the UX/UI work wraps up by the end of November 2026. Visuals use demo data with personal details redacted.