Self-service check-in kiosk for BMA public health centres
Overview
The BMA Health Kiosk is a self-service check-in kiosk for BMA public health centres and the first touchpoint of the patient journey. Patients verify their identity, check appointments and eligibility, pay, and leave with a printed queue ticket or receipt, before continuing in the PHCIS web system.
Scope: 6 use cases (reception, appointment check-in, entitlement check, payment, reprint, close entitlement) · 7 scenarios · 42 screens on a 1080×1920 portrait display.
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 kiosk flows, service design, UI and the kiosk product theme of the MIH Design System, working with the BA and development team. 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
Kiosk users stand at arm's length, often older or using a kiosk for the first time, with a queue behind them. Every path (appointment or walk-in, new or returning patient, self or dependant) has to end cleanly, and anything the kiosk cannot do must hand off to staff, including when the kiosk is out of service.
Timeline: the kiosk 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 kiosk included.
Goals
Check-in that a first-time user can finish without help.
Clear recovery from errors (card not found, failed face scan, failed payment).
Consistent with the clinic system so the hand-off feels like one service.
Business goal: move registration, appointment check-in and entitlement checks to self-service, offloading routine work from front-desk staff so they can focus on the cases the kiosk hands off.
Process
Flows: user flow, service design and process flow per service, from ID card, ThaiID or ID number entry through identity checks, entitlement, payment (PromptPay QR or card) and queue printing.
Kiosk design system: a dedicated blue theme distinct from the web product, the Prompt typeface at large sizes readable from standing distance (queue numbers at 100px), and components such as keypad, ID display and printing screen.
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. Kiosk journeys were built as working screens.
Cross-product journey: kiosk steps mapped into the shared journey with the web HCIS and Mobile App.
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 kiosk, that mostly meant service recipients and the general public walking up to the machine. 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 kiosk, the build includes real logic and alert conditions for each service branch.
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.
Business analysis contribution
I defined the kiosk's branching logic so every path ends cleanly (no patient data).
Journey routing: six journeys (reception, appointment, entitlement check, payment, reprint, close entitlement), each sharing screens such as ID card reading and loading but branching to the right next step.
Identity conditions: Thai ID card, ThaiID app or 13-digit number entry; visitors without a Thai ID are handed off to medical-records staff because the kiosk cannot validate a passport.
Eligibility & payment: entitlement shown for the patient or a dependant; patients whose scheme covers the visit skip payment, while others pay by PromptPay QR or card before receiving a queue ticket.
Queue routing: whether the visitor has an appointment and their visit type decides which queue number and station they are sent to.
Error and hand-off rules: dedicated outcomes for card not found, failed face scan, failed identity check and failed payment, each with a clear retry or staff hand-off.
Key design decisions
One decision per screen: large targets and a single primary action keep the pace steady for every user.
Designed error states: dedicated screens for each failure, with a clear next step or staff hand-off.
Separate theme, shared tokens: a kiosk look tuned for distance and lighting, still driven by the same token pipeline.
Outcomes & impact
42 kiosk screens delivered, covering every service path and error state.
Flow documentation that updates automatically from the codebase.
Part of 510+ screens across the BMA ecosystem built from one design system.
Learnings
When kickoff surfaced workflows beyond the TOR and management chose to include them, the two-month window left no room for a separate Figma stage. Building the kiosk directly as working software is what let our three-person team deliver it alongside the web and mobile products.
Designing for a public kiosk is designing for the worst moment: a failed card read with a queue behind you. Treating error and hand-off screens as first-class flows made the happy path simpler too.
With no time for real-user sessions, an AI usability skill playing service recipients and members of the public was the fastest way to catch obvious friction. It is a stopgap, not proof: testing with real people at the kiosk is the next step 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.