Patient mobile app for BMA public health services
Overview
The BMA Health Mobile Application is the patient-facing app for BMA public health services. It continues the same journey that starts at the Kiosk and runs through the PHCIS web system, so patients can manage appointments, see their records and join telemedicine visits from their phone.
Scope: 14 patient features (appointments, telemedicine, records, pharmacy, payment, queue, clinics, requests, consent, self-care, rating, profile, home, sign-in) · 6 AI persona test scenarios · 44 screens, built on the shared MIH Design System.
My role & team
Freelance Lead UX/UI Designer (Jul–Nov 2026 · almost done, UX/UI wrapping up by the end of November 2026), responsible for the mobile UX, UI and design system theme, working with the same BA and development team as the web HCIS. 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
Patients range from digitally confident to first-time smartphone users. The app has to reflect what happens in the clinic (appointments, queues, records, payments) while staying consistent with the staff system and the Kiosk.
Timeline: the mobile app shared the programme's timeline. During kickoff requirement-gathering, many workflows surfaced that were not specified in the TOR, and management decided to include them anyway. That left only about two months to revise and deliver every platform, the patient app included.
Goals
Make appointments, telemedicine and visit history easy to find and act on.
Stay consistent with Kiosk and web through one token pipeline.
Catch usability issues early inside a fast government timeline, with no time for real-user sessions.
Business goal: let patients manage their own appointments and join telemedicine visits from their phone, so fewer routine requests need staff time at the centre.
Process
Flows: designed as the final stage of a Kiosk → Web → Mobile design path, sharing one cross-product patient journey.
Design system: a mobile product theme of the MIH Design System (1,700+ tokens, Primitive → Semantic → Component, light and dark mode).
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. The patient app was built in working code alongside the web and kiosk.
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 patient app, the skill played 4 user roles across 6 tasks, in 3 rounds before and after fixes, with issues ranked by severity. This was AI persona-based testing, not testing with real users; real-user sessions are 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 app, 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 through GitHub with screen manifests and per-screen packets.
Business analysis contribution
I turned committee decisions into one shared set of appointment and notification rules used across the app (no patient data).
Appointment rules: booking closes one working day ahead; working days skip weekends and public holidays; each centre has its own opening days; reschedule or cancel requests are only allowed a set time before the appointment; booking and rescheduling confirm instantly with no "pending" state.
Telemedicine condition: a remote follow-up can only be booked after the patient has first seen a doctor at the centre.
Status wording: appointment and request statuses defined with consistent labels, for example "did not attend" instead of a punitive "disqualified".
Notification conditions: which events notify the patient (appointment reminders, missed appointments, service ratings) and through which channel (in-app, SMS or email), aligned with the system-wide alert registry.
Consent in sign-up: consent documents shown as a step in registration, following the same consent rules as the web system.
Key design decisions
Home as a task hub: the next appointment and the most common services sit up front instead of behind menus.
Timeline-based history: visits and results are shown in date order, matching how patients remember their care.
Shared tokens, not a separate style: the app looks like part of the same service as the Kiosk and the clinic.
Outcomes & impact
44 mobile screens delivered on the shared design system.
Usability issues found, ranked by severity and re-tested across three rounds of AI persona testing before development (real-user testing planned after launch).
Part of 510+ screens across the BMA ecosystem built from one token source.
Learnings
When the scope grew beyond the TOR and management chose to include it, the two-month window left no room for a separate Figma stage. Moving the whole UX/UI team to vibe coding is what let the patient app ship alongside the web and kiosk.
AI persona testing was a trade-off forced by the timeline, not a replacement for real patients. It caught the obvious friction early and cheaply; testing with real users after launch is the next step, and can focus on the harder questions.
Project almost done; the UX/UI work wraps up by the end of November 2026. Visuals use demo data with personal details redacted.