Praesent bibendum a elit non efficitur. Etiam et velit vitae quam aliquet fermentum. Quisque sit amet nulla dictum, cursus erat a, tempus est. Sed laoreet, magna eget mattis tincidunt, felis tellus vestibulum augue, in lobortis mauris risus eu nunc. Vivamus sed condimentum leo. Nunc efficitur, magna condimentum gravida egestas, ligula mauris posuere neque, sit amet sagittis dui velit vitae neque. Donec in dapibus arcu. Aliquam efficitur suscipit magna, vel pretium mi.
rakan.site
Rakan AlkhattabiUX Designer
Three case studies on the wall. SelectTap a poster to read one.
02
Patient Kiosks
Service design
Self check-in for patients who are tired, rushed or unwell.
Case 02rakan.site
Scroll to read ↓
Patient Kiosks
Designing the entire check-in service: corridor, queue, screen, token, armband and recovery.
① At a glance
Role and leadership. I led UX research and service design for the kiosk check-in experience. I worked with business analysis, development and hospital stakeholders to design a complete, implementable service across the public corridor, the touchscreen, fingerprint reader, token printer and armband printer.
Executive summary. Kiosk success was not only a screen-completion problem. It depended on whether people understood the machine before touch, could recover from a failed fingerprint scan, remained confident while printers worked, and left no personal information visible on a shared public screen.
70kiosks live
2check-in methods
00:20clean-reset target
AR + ENmirrored layouts
01 · context
② The queue is part of the interface
A person could approach the kiosk, hesitate without touching it, look at the reception desk and the queue behind them, then leave to join the desk queue. Conventional task-success measures miss that moment. The patient may be standing, unwell or accompanying someone who is, using an unfamiliar machine while others wait.
Check-in also ends beyond the screen: a queue token must print, then an armband must print and be worn. The product was therefore a service made of four connected parts (arrival, screen interaction, token slip and armband), not simply an interface.
One check-in spans four things. Only one of them is a screen
ArriveFinds the kiosks, unsure it is the right machine
ScreenIdentifies, picks the appointment, checks in
Token slipA queue number, printed
ArmbandPrinted, worn, carried to the waiting area
The highlighted step is the only part a screen design normally covers
| METHOD | MEASURE | SETTING / TIMING |
|---|---|---|
| Timed live observation | Dwell time per person and queue growth | Public corridors at KFSH&RC, Riyadh · 2026, before launch |
Dwell was the number that mattered. Two behaviours dominated: hesitation before touching anything, and walking away mid-flow.
Research focused on dwell and walk-aways at live kiosks.
| EVIDENCE CARD | |
|---|---|
| PARTICIPANTS | People using the kiosks, including patients and those accompanying them |
| CONTEXT | Timed live observation in public corridors, KFSH&RC Riyadh, 2026, before launch |
| QUESTION TESTED | What makes a person hesitate, abandon the flow or slow the queue at the kiosk? |
| WHAT CHANGED | Language-first welcome, finger choice before failure, a visible 00:20 reset and narrated print states. |
| LIMITATION | Prototype sessions were seated and unhurried, so they understated the pressure of the queue. |
| STAGE | ARRIVE | IDENTIFY | CHECK IN | WAIT | LEAVE |
|---|---|---|---|---|---|
| WHAT PEOPLE DID | Found the kiosks and assessed whether they were appropriate. | Used medical record number (MRN) or fingerprint. | Confirmed appointment details at arm’s length. | Waited for the token and armband. | Took the token and band and found the waiting area. |
| WHERE IT BROKE | Hesitation caused people to ask others or join the desk queue. | Fingerprint failure felt personal and recovery was unclear. | Extra decisions slowed a public, standing interaction. | Silent printing looked like a fault. | A mid-flow departure could leave a record on screen. |
| DESIGN OPPORTUNITY | Use a bilingual welcome that asks for language first. | Offer two entry paths and a finger-selection diagram before failure. | Show one decision per screen on a wide landscape layout. | Narrate token and armband-print waiting states. | Show a visible 00:20 timer and clear fully on expiry. |
The check-in journey: one check-in, five stages. The screen is only one part of the experience.
02 · approach
③ Design the machine and the queue
| OBSERVATION | IMPLICATION | MY DESIGN RESPONSE |
|---|---|---|
| People stood at the kiosk without interacting. | The kiosk did not clearly announce its purpose. | I created a bilingual welcome that asks for one low-risk action: language. |
| Fingerprint reads failed and people retried the same finger. | Recovery was invisible, so a technical fault read as personal rejection. | I surfaced a finger-selection diagram before failure. |
| Sessions were abandoned mid-flow. | A public device could expose a previous patient’s record. | I implemented a visible 00:20 countdown and complete session reset. |
| People waited through silent printing and assumed a fault. | The physical hardware was invisible to the person relying on it. | I designed explicit token and armband wait states. |
Synthesis: observation → implication → response.
before the screen
The corridor, the queue, the walk-away
01Measure dwell, not task success
I observed the live environment and timed how long each person occupied a kiosk, watching the behaviours that made the line grow. Two patterns mattered: uncertainty before first touch, and walk-aways that left a medical record on a public screen. Dwell exposed friction that a completed-flow metric would conceal.
Plan view: row of kiosks, main corridor
Kiosk
Kiosk
Kiosk
Reception desk
- Dwell: how long one person holds the machine
- “Am I even at the right machine?”, the pause before the first touch
- Walk-aways that leave a medical record on screen in a public corridor
Dots are people waiting. The desk stays open for cases that need a person
02Treat the kiosk as four machines in one cabinet
The cabinet combines a wide landscape screen, a fingerprint reader, a token printer and an armband printer. A substantial part of the experience is explaining what the hardware is doing while nothing changes on screen. The token prints first to secure queue position; the armband follows with an explicit wait state.
Elevation: one cabinet, four things to explain
ScreenWide landscape, read standing at arm’s length
Fingerprint readerThe common failure point. Recovery is a different finger
Token slipQueue position, printed first so the place is secured
Armband printerFour to six seconds of silence that has to be narrated
The screen is one of four outputs. Three of them are physical
| LANE | ARRIVE | IDENTIFY | CHECK IN | LEAVE | |
|---|---|---|---|---|---|
| PATIENT | Approaches the kiosks | Enters MRN or presents a finger | Confirms details | Waits | Puts the band on |
| FRONTSTAGE | Bilingual welcome | Two entry paths, finger diagram | One decision per screen | Token number, then wait state | Confirmation and instruction |
| BACKSTAGE | Idle loop, session cleared | Reader poll and match | Record lookup | Token printer, then armband printer | Session clears, returns to welcome |
| EVIDENCE | The cabinet itself | A read or a retry | The details on screen | A printed token | A band around a wrist |
Service blueprint: person, interface, system and physical evidence.
at the screen
Standing, watched, rarely used
03Wireframe for standing distance and public pressure
I designed low-fidelity flows for a wide, short screen read at arm’s length by a standing person. The rules were intentionally simple: one decision per screen, action placement where a right hand naturally rests, a hospital-information rail throughout, and plain Arabic and English. Every unnecessary decision can add a person to the queue.
04Provide two ways to identify
People can check in with their medical record number or fingerprint. Fingerprint paths included a finger-selection diagram because recovery from a failed read is typically a different finger. By offering this choice before a failure, the interface makes the recovery path available without making the person feel rejected in public.
05Make the reset visible to the next person in line
A 00:20 inactivity timer appears in the header and restarts with every touch. It is visible because it communicates not only with the active user but also with the person waiting next. On expiry, the session clears fully and returns to the bilingual welcome. Arabic layouts are mirrored, not merely translated.
after the screen
A slip, a band, and a desk still open
06Finish with the physical objects
The final interaction is not the final screen. The journey secures a token first, then explains the armband-print wait, and finally tells the person what to do with the physical items: put on the band and proceed to the waiting area. The interface finishes only when the service handoff is complete.
03 · outcome
④ Outcome, evidence and next measures
Live on 70 kiosks in public areas across the hospital, in Arabic and English as fully mirrored layouts. The person from the opening now gets one question first: which language. The reception desk keeps the cases that actually need a person.
Verified launch and delivery signals
70kiosks live
2identification paths
00:20clean reset
2mirrored languages
These are verified rollout and delivery facts, not performance outcomes. Performance results will be added once they are approved.
Results being measured
- Median kiosk dwell time and its change by flow.
- Share of check-ins completed at a kiosk rather than reception.
- Abandonment and walk-away rate, including reset-related privacy incidents.
- Fingerprint retry and recovery behaviour.
- Queue length and reception workload during peak periods.
The kiosk experience is live in public areas. Results are being tracked and will be published once approved, with a stated time period, alongside the rollout figures.
04 · what I’d do differently
⑤ What I’d do differently
What I learned. Live observation showed the real pressure of the queue, but seated, unhurried prototype sessions made the flow feel calmer than the corridor.
What I would change next time. Run more prototype sessions standing up, with three people visibly waiting behind the participant.
Expected benefit. Queue friction shows up in testing rather than after launch, where it decides whether people use the kiosk at all.
Next stop
Case 03 · Discharge Summary Generator
Designing a clinical-AI drafting tool that keeps the clinician in control and every section traceable.
03
Discharge Summary Generator
● AI tool
Case 03→
03
Discharge Summary Generator
AI tool
Turning clinical notes into a summary people can act on.
Case 03rakan.site
Scroll to read ↓
Discharge Summary Generator
Designing a clinical-AI drafting tool that keeps the clinician in control and every section traceable.
① At a glance
Role and leadership. I led UX research and product design for an ICIS-integrated clinical-AI tool. I worked with business analysis, development and clinical stakeholders to define a trust-centred workflow: clinician-selected source notes, structured draft sections, per-section provenance and explicit human approval before anything enters the clinical record.
Executive summary. The clinical bottleneck was not typing. It was retrieving the relevant facts from a long encounter history and verifying them. I designed a constrained drafting experience that assists with retrieval and composition while preserving authorial control, traceability and the ability to say “not found.”
73 → 11notes selected
13traceable sections
3steps to draft
5steps to save
01 · context
② Low-value writing on the critical path
At the end of a shift, a clinician may face one encounter with 73 notes to review before writing a discharge summary. The discharge cannot complete until the summary exists. In the existing workflow, the summary is written in ICIS from scratch or assembled from earlier notes, which can carry errors forward.
Writing quality was not the central problem. The time cost sat in reading back through the record, finding the relevant facts and checking claims. A useful tool had to support retrieval without presenting an opaque, authoritative-looking clinical document.
One encounter, one clinician, end of a shift
73notes on this encounter
13sections to fill
0of them written yet
Every note on the encounter. The eleven that matter are in here somewhere
Finding them is the work. Writing is quick once they are found
| METHOD | PARTICIPANTS / SETTING | WHEN |
|---|---|---|
| Contextual inquiry through the real task | 6 clinicians writing discharge summaries on the ward at end of shift, KFSH&RC Riyadh | 2026, before pilot |
The reading is the work. Typing is quick once the facts are found, so the tool had to earn its keep at retrieval.
Research observed the actual discharge-summary workflow rather than relying on retrospective accounts.
| EVIDENCE CARD | |
|---|---|
| PARTICIPANTS | 6 clinicians writing discharge summaries |
| CONTEXT | Contextual inquiry on the ward at end of shift, KFSH&RC Riyadh, 2026, before the pilot |
| QUESTION TESTED | Where does the time go when a discharge summary is written? |
| WHAT CHANGED | Source selection before generation, thirteen traceable sections, View Source per section and an explicit “not found” state. |
| LIMITATION | The “not found” state was designed after generation; it should have come first. |
| STAGE | OPEN ENCOUNTER | READ BACK | ASSEMBLE | CHECK | SAVE |
|---|---|---|---|---|---|
| WHAT CLINICIANS DID | Opened an encounter with dozens of notes. | Read through notes to find relevant facts. | Typed in ICIS or pasted from earlier notes. | Reread for missing or incorrect information. | Saved so discharge could complete. |
| WHERE IT BROKE | No sense of the reading effort ahead. | The real cost was invisible retrieval work. | Pasting could propagate earlier errors. | No direct trace from claim to note. | Discharge waited for a completed summary. |
| DESIGN OPPORTUNITY | Show note count and support deliberate source selection. | Use thirteen named sections with independent source states. | Draft from selected notes only. | Provide View Source per section. | Require human approval before saving to ICIS. |
The current journey: the reading is the work. Typing becomes fast once the facts are found.
02 · approach
③ Draft, but never speak for the clinician
| OBSERVATION | IMPLICATION | MY DESIGN RESPONSE |
|---|---|---|
| Clinicians spent time reading, not writing. | Retrieval, not composition, was the bottleneck. | I intervened at the source set before generation. |
| Summaries were assembled from earlier notes. | Errors could propagate without visibility. | I created per-section provenance. |
| A whole clinical document from a machine was not trusted. | Trust had to be earned at the unit of disagreement. | I used thirteen independently editable and regenerable fields. |
| A confident claim with no source was the major fear. | Plausible invention could end the pilot. | I designed explicit “Not found in selected notes” states and manual fields. |
Synthesis: observation → implication → response.
before the draft
Seventy-three notes, and the eleven that matter
01Observe the writing work directly
I sat with clinicians while they created discharge summaries. The key finding was simple: typing is quick once the facts have been found. That shifted the product priority from generic text generation to controlled retrieval, source selection and inspection.
How one summary gets written today
01Read backthrough 73 notes on the encounter
02Retypethe same facts into ICIS by hand
03Or pastefrom an earlier note, errors included
04Dischargecannot complete until it exists
The reading is the work. The typing is quick once the facts have been found.
The last step of an admission, and the one on the critical path
02Model the output as thirteen sections, not one blob
A structured section can be empty, sourced, regenerated or edited on its own. A single generated block can only be accepted or rejected wholesale. I designed thirteen named sections so the clinician can inspect exactly the unit they disagree with, for example one line in Discharge medications rather than a full summary.
Thirteen sections, each with its own source, state and regenerate
Date of admissionAlways
Attending physicianAlways
Principal diagnosisAlways
Secondary diagnosisOften
Past medical historyOften
ProceduresSometimes
ConsultationsSometimes
History of present illnessOften
Physical examinationSometimes
Condition on dischargeSometimes
Discharge instructionsSometimes
Follow-upSometimes
Discharge medicationsOften
Always presentOften presentSometimes empty, and allowed to say so
| STEP | 1 · ENCOUNTER | 2 · SOURCE SET | 3 · GENERATE | 4 · REVIEW | 5 · SAVE |
|---|---|---|---|---|---|
| CLINICIAN | Opens patient and encounter | Picks which notes feed the draft | Waits | Reads, edits, regenerates a section | Presses Save |
| THE TOOL | Shows 73 notes, grouped by type | Shows a running count and a time estimate | Drafts thirteen named sections | Offers View Source on each section | Saves the approved summary into ICIS |
| GUARDRAIL | Nothing is chosen silently | Commit is explicit | Only the selected notes are used | Empty sections say “not found” | Nothing saves without a person |
Decision flow: where clinician control stays explicit.
the draft
Thirteen sections
03Wireframe the argument before the interface
I wireframed patient and encounter selection, note selection and review in low fidelity. The central design argument was how much control to hand over before generation, rather than how the output should look. The contested decisions were source selection, inspection and the refusal case.
04Make the source set a deliberate decision
An encounter may contain 73 notes. The clinician chooses the notes that feed the draft, with notes grouped by type, filters, a running count and a time estimate before committing. A system that selected sources silently could be faster, but it would be much harder to trust.
The source set is explicit because clinicians need to know what the model was allowed to read.
after the draft
Provenance and refusal
05Make provenance available per section
View Source sits on each of the thirteen sections and opens the note that produced the content beside the draft. Per-document provenance would be easier to implement but would not match the clinical unit of disagreement. A clinician challenges a medication line, not an entire document.
Provenance is per section because clinicians disagree with one line, not with a whole document.
03 · outcome
④ Outcome, evidence and next measures
In pilot with a small number of departments. The clinician chooses the notes that matter, gets a draft in three steps, and checks each section against the note it came from. Where the notes are silent, so is the tool.
Verified launch and delivery signals
73 → 11notes selected
13reviewable sections
3steps to draft
5steps to save
These are verified rollout and delivery facts, not performance outcomes. Performance results will be added once they are approved.
Results being measured
- Time from encounter open to approved summary, segmented by specialty and complexity.
- Section-level edit, regenerate and “not found” rates.
- Clinician confidence, acceptance and source-view behaviour.
- Clinical quality review of every generated section against its source notes.
- Safety incidents, escalation patterns and ICIS save completion.
The tool is in pilot across a small number of departments. Clinicians check accuracy section by section against the source notes before anything is saved into ICIS. Results will be published once the pilot analysis is approved.
04 · what I’d do differently
⑤ What I’d do differently
What I learned. Generation was built first and the “not found” case second, so the full-content pattern set the terms for the empty state.
What I would change next time. Design the refusal state before the ideal output.
Expected benefit. In a tool that writes into a clinical record, what it says when evidence is absent is a load-bearing safety feature. Specifying it first makes it robust rather than an afterthought.
Next stop
Case 01 · KFSH Employees
Redesigning the employee experience around a hospital shift, not a department.
01
KFSH Employees
● Mobile app
Case 01→
01
KFSH Employees
Mobile app
The staff app for a hospital that never closes.
Case 01rakan.site
Scroll to read ↓
KFSH Employees
Redesigning the employee experience around a hospital shift, not a department.
① At a glance
Role and leadership. I led end-to-end UX design and research for the employee app. I worked directly with business analysis, development and stakeholder partners to turn field evidence into an implementable, secure experience spanning attendance, HR self-service, credentials, policy guidance, directory and on-call escalation.
Executive summary. The existing app reflected departmental ownership rather than the reality of a hospital shift. I restructured the experience around the moments staff need support (arrive, identify, work, ask and leave), so common employee tasks could be completed from one authenticated mobile experience.
16K+employees on the app
6tasks moved into the app
40+screens shipped
iOS + Androidplatform
01 · context
② The app opened, then the walking started
A staff member ending a night shift could open the app to correct a missed 02:40 punch and find no route to do it. The workaround was an email to a manager, followed by a delay that might only become visible on a payslip two weeks later. The same fragmentation affected payslips, employment letters, policy questions, proof of identity and on-call information.
The hospital already had an employee app, but it was partial and organised by the service owner. A clinical workforce does not carry a laptop around the hospital, so every gap became a phone call, a walk or an HR ticket. The opportunity was not merely to add features; it was to organise the product around the timing and pressures of a shift.
Still done somewhere else
Payslipwalk to HR
Employment letterraise a ticket
Proof of IDplastic badge
Policy questionphone a colleague
Missed punchemail a manager
Who is on-call?printed rota
Six of the most common tasks: none of them in the app
| METHOD | PARTICIPANTS / SETTING | WHEN |
|---|---|---|
| Shadowing and semi-structured interviews | 11 clinical and non-clinical staff at KFSH&RC | 2025 |
The day has a shape: arrive, prove who you are, work, need an answer, leave. The old app was ordered by department instead.
Research method used to establish the shape of a working shift.
| EVIDENCE CARD | |
|---|---|
| PARTICIPANTS | 11 clinical and non-clinical staff |
| CONTEXT | Shadowing on shift and semi-structured interviews, KFSH&RC, 2025 |
| QUESTION TESTED | What does a working shift contain, and where does the current app stop? |
| WHAT CHANGED | Navigation rebuilt around five moments of the shift; Justify Absence and the digital badge added; PolicyGPT shows its source. |
| LIMITATION | PolicyGPT was tested with staff who ask policy questions, not the HR officers who answer them. |
| STAGE | ARRIVE | IDENTIFY | WORK | ASK | LEAVE |
|---|---|---|---|---|---|
| WHAT STAFF DID | Punched in at a wall terminal or used the old app. | Carried a plastic badge for doors and checks. | Sought payslips, letters or the rota elsewhere. | Asked a colleague about policy. | Punched out and hoped it registered. |
| WHERE IT BROKE | A missed punch had no in-product route. | A forgotten badge created a locked-door problem. | Tasks lived in offices, tickets and printouts. | Answers varied and lacked a visible source. | The same attendance gap surfaced on a later payslip. |
| DESIGN OPPORTUNITY | Place punch in/out above the fold; create Justify Absence. | Use the phone as a credential surface. | Make Home a high-frequency task hub. | Provide PolicyGPT with answer, source and policy authority. | Keep the day’s record with the attendance record. |
The shift journey: one shift, five stages. The product was redesigned for the day people actually have.
02 · approach
③ Make the shift the unit of design
| OBSERVATION | IMPLICATION | MY DESIGN RESPONSE |
|---|---|---|
| Staff opened the app, then still walked to an office or called someone. | The app was a departmental directory, not a container for the day. | I created five areas organised around the shift. |
| Policy questions were directed to colleagues. | The trusted source was a person who might be unavailable at 03:00. | I designed PolicyGPT with answer-first access and the source document beside every answer. |
| A forgotten plastic badge stopped people at doors. | Identity was essential and tied to a physical object. | I designed digital badge and door-access states to be unambiguous. |
| A missed punch became an email that could surface weeks later. | The error path lived outside the product and was therefore invisible and slow. | I made Justify Absence a first-class route. |
Synthesis: observation → implication → response.
the shift
Where the day actually goes
01Start with the day
I started with shadowing and interviews rather than a feature wish list. The question was: what does a shift contain? The pattern was consistent: arrive, prove identity, work, need an answer, leave. The previous app served fragments of that day in an order that matched the organisation chart. A working day does not.
One shift, end to end
ArrivePunch inJustify a missed punch
IdentifyDigital badgeDoor access
WorkOn-call escalationDirectoryReport incident
AskPolicy questionPayslip / letter
LeavePunch out
02Name the navigation for moments, not departments
I defined five areas: Home for the day, HR for the record, PolicyGPT for the question, Directory for the person and On-call for the escalation. Payslips and letters remain in HR because people seek those records by owner. High-frequency tasks, including the badge and the missed punch, sit on Home, ordered by how often they are needed rather than by the department that owns them.
KFSH Employees
Home
- Attendance
- Punch in / out
- Justify absence
- Quick access grid
- Report incident
HR
- My information
- Payslip
- Letters
- Leave balance
PolicyGPT
- Ask a question
- Answer + source
- Generated-text notice
- Error state
Directory
- Search staff
- Department
- Contact card
- Extension
On-call
- Today's rota
- Level one
- Level two
- Escalate
Five areas in the bottom nav. Everything else reached from Home
| HOME | HR | POLICYGPT | DIRECTORY | ONCALL |
|---|---|---|---|---|
| Punch in / out | Payslip | Ask a question | Search staff | Today's rota |
| Justify absence | Letters | Answer + source | Department | Level one |
| Quick access | My information | Generated notice | Contact card | Level two |
| Report incident | Leave balance | Error state | Extension | Escalate |
Information architecture: five destinations named for a moment in the day.
03Resolve sequence before visual design
I used low-fidelity flows for attendance, the policy assistant and credentials before moving into visual design. These three flows carried most of the traffic and established the patterns for the remaining screens. The design debate was intentionally about sequence, recovery and control before colour or polish.
what they opened it for
Attendance, policy, credentials
04Put attendance where people need it
Punch in and punch out sit above the fold with the time and date. Justify Absence gives the missed-punch scenario its own route, replacing a fragile email workflow with a visible, actionable path inside the product.
05Make policy guidance inspectable
PolicyGPT was designed for a trust-sensitive use case. The experience presents the answer first, then the source, with a persistent notice that the text is generated and the policy document remains the authority. A one-time consent step precedes the first question. I tested the concept with staff who ask policy questions, replacing a reliance on colleagues who may be unavailable during overnight shifts.
06Turn the phone into a reliable credential surface
The credential set brings together the digital badge, door access, mask-fit records and safety reference cards. I designed it for its physical context: one hand, a corridor, a locked door and people waiting behind the user. Door-access states are deliberately unambiguous; uncertainty at a door is operationally worse than a clear refusal.
03 · outcome
④ Outcome, evidence and next measures
Live on iOS and Android, with more than 16,000 employees on it. The missed 02:40 punch is now justified in the app before the shift ends. The payslip, the letter, the badge and the policy answer sit in one place, behind one login.
Verified launch and delivery signals
16K+employees reached
6common tasks moved
40+screens shipped
1authenticated app
These are verified rollout and delivery facts, not performance outcomes. Performance results will be added once they are approved.
Results being measured
- HR-ticket volume for the six migrated tasks.
- Time to correct missed punches and completion rate for Justify Absence.
- Self-service completion for payslips and employment letters.
- PolicyGPT use, source-view behaviour and confidence in the answer.
The app is live on iOS and Android. Performance figures are confidential for now and will be added once approved, with a stated time period and source.
04 · what I’d do differently
⑤ What I’d do differently
What I learned. Testing PolicyGPT with the people who ask policy questions proved that accessible answers matter, but it missed the hard cases.
What I would change next time. Involve the people who answer policy questions, especially HR officers, earlier and more systematically.
Expected benefit. HR officers expose contested wording, edge cases and escalation needs, which makes policy guidance resilient in practice.
Next stop
Case 02 · Patient Kiosks
Designing the entire check-in service: corridor, queue, screen, token, armband and recovery.
02
Patient Kiosks
● Service design
Case 02→
Mauris leo erat, placerat quis semper eu, pulvinar in est. Nam eget justo quis ligula faucibus pretium ac nec mi. Aliquam lacus est, auctor sed arcu at, luctus condimentum lectus. Quisque vitae eleifend quam, vel suscipit nisl. Duis efficitur est nunc, eget efficitur felis porttitor in. Donec facilisis ultrices mattis. Quisque blandit ac enim non accumsan. Donec euismod magna turpis, ut blandit purus tempor sit amet. Suspendisse et hendrerit mi. Integer gravida, sapien quis ullamcorper auctor, metus eros aliquet ante, ut dictum ipsum tortor eget elit. Maecenas eu rutrum dui, ut faucibus lectus. Vivamus porttitor bibendum tortor.`
Education
Vestibulum Euismod Ultrices (Congue)
Suspendisse Aenean Lectus
2023
Vestibulum Euismod Ultrices (Tincidunt)
Aliquam Faucibus Tellus
(3 years)
Employment
Vestibulum Ultricies
Suspendisse Aenean Vestibulum
2023 - 2024
Pellentesque Habitant
‘Morbi Tristique Senectus’
Nunc Euismod Faucibus,
Porta Libero
2024
Volutpat Ultricies
Curabitur Fringilla Ornare,
Duis Quis
(since 2020)
Accumsan Dui
‘Integer Consequat’
Purus Euismod Facilisis, Pharetra Massa
2022
TEMPUS, TEMPUS, TEMPUS
Aliquam Faucibus Tellus, Euismod Ornare
Tincidunt Quam
2021
Referrals
Tincidunt Nibh
Ultricies Vestibulum
Facilisis Ornare,
Porta Libero Universitas,
tincidunt.nibh@portolibero.edu.au
0491 570 006
Dictumst Gravida
Auctor Ligula / Founder
Aliquam Aliquam Congue, Felis
dictumst.gravida@gmail.com
0491 570 156
Rhoncus Mattis
Suspendisse Professor
Facilisis, Bibendum Ornare & Congue
rhoncus.mattis@facilisis.edu
0491 570 157
Sollicitudin Euismod
Founder
Pellentesque Mounds, Porta Libero
sollicitudin@vestibulum.com
0491 570 158
Egestas Convallis
Deputy Parturient Dictum
Duis & Ultricies Vestibulum
egestas.convallis@vestibulum.edu
0491 570 159
Skills
Vestibulum Ultrices
Congue Nisl
Tincidunt Euismod
Auctor Gravida
Molestie Vulputate
Tempor
Parturient
Nibh Ultricies
Aliquet Pellentesque
Rhoncus Tempor
Ullamcorper / Ornare
Porttitor Quisque
Lacinia
Bibendum Facilisis
Suspendisse Tristique
Viverra Dictum
Duis Convallis Et Congue
Semper Facilisis
Exhibitions
(upcoming) Tincidunt TBA
Ultricies Ultricies,
Congue Nisl
2024
(upcoming) Vestibulum-Vitae
Auctor Ipsum,
Dictumst Ligula,
Porta Libero
2024
Suspendisse
Molestie Aenean,
Facilisis Tellus,
Porta Libero
2024
Ultrices
Parturient Felis,
Pharetra Nibh,
Porta Libero
2023
Bibendum
Adipiscing Nunc,
Tincidunt Tristique Congue,
Vestibulum Porta Libero
2023
Eu & Fringilla, Collaborative
Imperdiet with Quam Sodales,
Donec Tristique Porta Libero
2023
Semper
Cursus Tempus,
Porta Libero
2023
Dictum, Elit. Vestibulum
Gravida Congue
2023
Rhoncus Congue
Ullamcorper Suspendisse,
Duis Ornare Porta Libero
2023
Awards
Tempus Egestas Nibh Vestibulum
Facilisis: Ultricies Ornare Ligula
2021
Rhoncus Auctor Ornare; Tincidunt Tristique, Porta Libero
2020
Press
‘Vestibulum Inceptos Gravida’, Ornare Review,
by Tincidunt Nisl
2024
‘Ullamcorper Faucibus (Congue) Euismod’, by Ligula Parturient, Bibendum Review Porta Libero
2023
Dictumst Tristique, Facilisis Magazine, Edition Two, Porta Libero
2021
Auctor Adipiscing Art Magazine, Porta Libero
2020
Sollicitudin Ornare Magazine,
Porta Libero
2020
Profile (Sample)
Vivamus sed sapien fermentum, fermentum metus ut, efficitur nunc. Pellentesque sit amet ex sed est dapibus vestibulum. Donec ornare urna metus, ut mollis risus dignissim in. Phasellus tristique sed leo et dignissim. Nam lobortis vitae leo at finibus. Aliquam eget efficitur lacus.
Mauris leo erat, placerat quis semper eu, pulvinar in est. Nam eget justo quis ligula faucibus pretium ac nec mi. Aliquam lacus est, auctor sed arcu at, luctus condimentum lectus. Quisque vitae eleifend quam, vel suscipit nisl. Duis efficitur est nunc, eget efficitur felis porttitor in. Donec facilisis ultrices mattis. Quisque blandit ac enim non accumsan. Donec euismod magna turpis, ut blandit purus tempor sit amet. Suspendisse et hendrerit mi. Integer gravida, sapien quis ullamcorper auctor, metus eros aliquet ante, ut dictum ipsum tortor eget elit. Maecenas eu rutrum dui, ut faucibus lectus. Vivamus porttitor bibendum tortor.
Email, Instagram ↗
Education
Vestibulum Euismod Ultrices (Congue)
Suspendisse Aenean Lectus
2023
Vestibulum Euismod Ultrices (Tincidunt)
Aliquam Faucibus Tellus
(3 years)
Employment
Vestibulum Ultricies
Suspendisse Aenean Vestibulum
2023 - 2024
Pellentesque Habitant
‘Morbi Tristique Senectus’
Nunc Euismod Faucibus,
Porta Libero
2024
Volutpat Ultricies
Curabitur Fringilla Ornare,
Duis Quis
(since 2020)
Accumsan Dui
‘Integer Consequat’
Purus Euismod Facilisis, Pharetra Massa
2022
TEMPUS, TEMPUS, TEMPUS
Aliquam Faucibus Tellus, Euismod Ornare
Tincidunt Quam
2021
Referrals
Tincidunt Nibh
Ultricies Vestibulum
Facilisis Ornare,
Porta Libero Universitas,
tincidunt.nibh@portolibero.edu.au
0431 070 713
Dictumst Gravida
Auctor Ligula / Founder
Aliquam Aliquam Congue, Felis
dictumst.gravida@gmail.com
0404 965 983
Rhoncus Mattis
Suspendisse Professor
Facilisis, Bibendum Ornare & Congue
0415 843 581
rhoncus.mattis@facilisis.edu
Sollicitudin Euismod
Founder
Pellentesque Grounds, Porta Libero
0422 221 072
sollicitudin@vestibulum.com
Egestas Convallis
Deputy Parturient Dictum
Duis & Ultricies Vestibulum
egestas.convallis@vestibulum.edu
0402 254 956
Skills
Vestibulum Ultrices
Congue Nisl
Tincidunt Euismod
Auctor Gravida
Molestie Vulputate
Tempor
Parturient
Nibh Ultricies
Aliquet Pellentesque
Rhoncus Tempor
Ullamcorper / Ornare
Porttitor Quisque
Lacinia
Bibendum Facilisis
Suspendisse Tristique
Viverra Dictum
Duis Convallis Et Congue
Semper Facilisis
Exhibitions
(upcoming) Tincidunt TBA
Ultricies Ultricies,
Congue Nisl
2024
(upcoming) Vestibulum-Vitae
Auctor Ipsum,
Dictumst Ligula,
Porta Libero
2024
Suspendisse
Molestie Aenean,
Facilisis Tellus,
Porta Libero
2024
Ultrices
Parturient Felis,
Pharetra Nibh,
Porta Libero
2023
Bibendum
Adipiscing Nunc,
Tincidunt Tristique Congue,
Vestibulum Porta Libero
2023
Eu & Fringilla, Collaborative
Imperdiet with Quam Sodales,
Donec Tristique Porta Libero
2023
Semper
Cursus Tempus,
Porta Libero
2023
Dictum, Elit. Vestibulum
Gravida Congue
2023
Rhoncus Congue
Ullamcorper Suspendisse,
Duis Ornare Porta Libero
2023
Awards
Tempus Egestas Nibh Vestibulum
Facilisis: Ultricies Ornare Ligula
2021
Rhoncus Auctor Ornare; Tincidunt Tristique, Porta Libero
2020
Press
‘Vestibulum Inceptos Gravida’, Ornare Review,
by Tincidunt Nisl
2024
‘Ullamcorper Faucibus (Congue) Euismod’, by Ligula Parturient, Bibendum Review Porta Libero
2023
Dictumst Tristique, Facilisis Magazine, Edition Two, Porta Libero
2021
Auctor Adipiscing Art Magazine, Porta Libero
2020
Sollicitudin Ornare Magazine,
Porta Libero
2020