Skip to content
Rakan Alkhattabi
Decision 3 of 3 ยท KFSH Patient App

One way to book

My contributionNot measuredCapability: Get started

Patients didn't know whether they needed a virtual or in-person visit before they started.

Booking with visit type up front, final
Decision 03 ยท Final screen ยท Final design, version 2 Figma design of the launched productView the evidence
01

What was difficult

Separate entries forced the choice before patients knew what they needed.

02

Evidence at the time

Usability tests in Arabic and English, 3 rounds of 6.

03

Alternatives considered

  • Keep separate Virtual and In-person entries in Services.
04

Selected direction and trade-off

Services has one Appointments entry. Visit type is a simple choice on the booking screen, before clinic, doctor and time.

Trade-off. One more field on the booking form.

Who did what. To confirm What I did, who set or approved the rule, and what engineering built.

05

Accessibility

Visit type is a segmented control on the booking screen, and secondary text was raised to #5C5F6A for contrast. These are design checks.

06

Result and status

Not measured

No booking-specific measure is in the case file.

Open question: whether video visits rose after the change.

07

The evidence

See the low-fi and final screens side by side, with what they do and do not prove

Next decision: Check in when it's actually possible Back to KFSH Patient App