Work Lab results a patient can read, and meal orders a ward can trust.
Lab results in the patient app, final design: results grouped by category with tabs for All, General tests and Infection tests, then a result that points to an attached PDF and lists the other tests the same file covers. Sample data.
In progressMedPark HospitalSep 2026 – now

Lab results a patient can read, and meal orders a ward can trust.

I've worked onsite at MedPark Hospital since September 2026 as UX/UI designer and BA. So far: lab results in the patient app, and the inpatient meal system.

My role
UX/UI and business analysis
Team
Development team, hospital IT, clinical teams
When
Sep 2026 – now, onsite
Tools
Figma, Jira, my AI second brain

Impact

14 → 4hospital result categories into patient groups
20clinical diet types in the meal ordering flow
3nutritionists in the first meal-flow usability test

Part 1 · Lab results in the patient app

New result types were coming: microbiology PDFs, pathology, genomics. The brief was to fit them in without redesigning the screen patients knew.

75%of 1,255 hospital tests keep the real result in a file
14 → 4hospital categories into patient groups
1 → 3one PDF can cover three results

How I read the backend

How the hospital system stores a result

  1. Visit
  2. Orderhas an Order No.
  3. Lab reportone per lab section and release · files show here
  4. Specimenone tube, so one blood draw can be three
  5. Testvalue, flag, range · the app shows one card per test

What I designed around it

The feed can't name the tube
Grouping by specimen was dropped
Every test has a category
Group by category, cut to 4
Files sit above the test
Rules decide which card shows a file
We don't own the hospital system
Every fix lives in the app
My reading of the lab data, checked with hospital IT and the lab team

From my first idea to what the data allows

Scroll. Each step names a problem, then shows the change in place.

  1. Problem 1

    One long list

    Blood, urine and immunology already shared one list. File-based results were about to join it.

    Before · Everything mixed
    After
  2. First idea

    Group by what was taken from you

    Patients remember a morning blood draw, not a lab category. One card per specimen and day, collection times inside.

  3. Problem 2

    The data is shaped differently

    In the hospital system a specimen is a tube, so one draw is three. Files sit on lab-section reports, and the feed can't say which tube a file came from.

    Before · Not in the data
    After
  4. Fix 2

    Group by category, 14 → 4

    Every test has a category, so I grouped by it, then cut 14 lab-bench names to 4 groups. Each name must be true for every test in it.

  5. Problem 3

    A card shows another test's file

    Files hang on the whole lab report, so ANA and Anti-dsDNA ordered together each show both files.

    Before · Someone else's file
    After
  6. Fix 3 · proposed

    Match the file, or show none

    The uploader notes the Order No. in the file's description. No match, no file. Unreleased results never show.

  7. Problem 4

    One file, three results

    Three blood bank results come back as one PDF. Each opens the same file with no hint it covers the others.

    Before · No hint it's shared
    After
  8. Fix 4

    A quiet line under the file

    “This document may also include results for…” with light links. No extra box, so the result stays the focus.

  9. Problem 5

    A file can carry a hidden result

    Some results are hidden from patients, one test at a time. A shared file could still contain one.

    Before · Hidden result inside
    After
  10. Fix 5

    One hidden test hides the file

    If any test in the group is hidden, the shared file and that test's link don't show.

  11. Result

    Old or new?

    Flip between the list as it was and the four groups.

    Old
    New

Screens redrawn with sample data. No real patient, doctor or result is shown.

GroupHospital categories
General tests
ตรวจทั่วไป		Chemistry, hematology, immunology, urinalysis and body fluid, POCT, blood bank, stool exam, referral lab (already in the app today)
Infection tests
ตรวจหาเชื้อ		Microbiology, molecular biology
Biopsy & cell tests
ตรวจชิ้นเนื้อและเซลล์		Surgical pathology, cytopathology (GYN), cytopathology (non-GYN)
Genetic tests
ตรวจพันธุกรรม		Genomics
The 4 groups. When unsure, a test goes to General tests: incomplete is acceptable, wrong is not.
InteractiveThe mockups behind the walkthrough

Alongside this I worked out how DICOM scan images should display in the app.

Part 2 · Inpatient meals

Ward staff order meals for inpatients. Each order must respect the doctor's diet order, the patient's swallowing, the room type and the kitchen's billing rules. Much of it ran on paper slips and food cards.

Discovery

I recorded a walkthrough with ward staff and sent the clinical nutrition team a round of questions. Then I mapped the journey and the menu rules, because those rules decide which colour of slip reaches the kitchen.

Decision flow for setting a patient's menu. From the dietary profile, the flow splits on allergies, disease or halal, then on how each meal is served: normal, swallowing training or tube feeding. Each path ends in a white, green or pink slip for the kitchen.
InteractiveSetting a patient's menu: decision flow, in Thai. Zoom in to read it.

Three questions per meal pick the slip the kitchen cooks from:

1 · RestrictionsAllergies, disease or halal?

No: the regular path. Yes: the same steps on a separate path, ending in a pink slip (ใบชมพู).

2 · How it's servedNormal, swallowing training or tube

Normal: pick a template set for the meal. Swallowing training: pick the level, a training template and training dishes. Tube feeding: pick how many meals to serve and the bags per meal.

3 · ExtrasMilk, or a training dish on top?

Milk can be added, in a bag or not. A tube-fed patient can also get a swallowing-training dish.

The slips

ใบขาว white regular meals · ใบเขียว green swallowing training · ใบชมพู pink allergies, disease or halal

The one rule that overridesIf at least one dish is swallowing training, the slip is always green.

The diet type drives the flow

The old diet dialog handled restrictions, disease and patient type. But swallowing training was a yes/no switch with no IDDSI level, tube feeding had no screen, and patients who can't eat got a generic empty state. I rebuilt it so the diet type decides what can be ordered: 20 types, set by the nutritionist, from regular food to tube feeding. Five screens cover it, from the diet dialog to the kitchen's cooking summary.

Every swallowing-training dish must carry an IDDSI level, with no default. A missing level is a safety problem, so a menu with one can't be published at all.

Testing it with the nutrition team

I wrote a 60-minute moderated test on the DEV build and rewrote it after feedback. Each task hides a twist, something that happens mid-task on a real ward, to see what people do when the plan changes.

The 60 minutes · one participant on the DEV build

  1. Welcome3 min
  2. Task 118 min
  3. 2.112 min
  4. 2.27 min
  5. 38 min
  6. 3.15 min
  7. Debrief7 min
  1. Task 1Build the menu

    Create 3 dishes, then a menu template that matches the kitchen's paper menu sheet.

  2. Task 2.1Take a VVIP order

    Patient and relative order on the tablet.

    TwistThe relative asks for a dish that isn't on the menu, and someone comments on yesterday's food. The tablet has no answer for either, on purpose.

  3. Task 2.2The doctor changes the order

    Review the Cooking Summary.

    TwistA dev switches the diet order to iodine-restricted in the hospital system as the task starts.

  4. Task 3Tube feeding

    Set up a blenderized tube feed through to the Cooking Summary.

  5. Task 3.1A message from OT

    Add swallowing training on top of the tube feed.

    TwistA printed LINE message from the occupational therapist asks for 2 cups of swallowing-training food.

When someone gets stuck

  1. ✓Did it alone
  2. H1Restate the goalafter ~60 s stuck
  3. H2Point to the screen area~60 s more
  4. H3Show it, then hand back~3 min on one step
  5. ✗Facilitator completes it

Who's in the room

  • FacilitatorReads each scenario, plays the patient and relative, hands over props
  • Note-takerFills the observation sheet and minutes per task. Never speaks
  • Dev on standbyChanges the doctor's order live, reseeds data if something breaks

Rules I set

  • Task sheets name the screen to go to. Buttons stay unnamed
  • Never say right or wrong. “What do you think?” instead
  • A 1 to 7 ease score after every task
  • White paper only: pink and green slips are real kitchen signals
  • Test patients seeded in DEV instead of printed patient cards

Draft 1 → version 2

8 scenarios cut to 5 tasks, patient cards, a payment report

3 tasks in 5 parts, with the twists that matter: a live order change and requests the system can't handle

Run sheet, tasks and twists, hint ladder and roles. The printed sheets were in Thai.

I ran it with 3 nutritionists. The flow held up. Most feedback was about features we hadn't built yet, and those went into the backlog.

Part 3 · The patient order list

Nutritionists start every day on the Patient Order List, then open a patient to set meals and publish the menu. The team sent 10 feedback points. I grouped them by the real problem and prototyped with Claude; the domain decisions stayed mine.

10 → 4feedback points, grouped into problems
8+ → 3status labels, plus “–”
10developer cards in Thai, with acceptance criteria
  1. Problem 1

    A Setting button on every row

    A whole column repeated one button. It used space and said nothing.

    Before · Same button, every row
    After
  2. Fix 1

    The name is the link. Menu Type takes the column

    One change answered 3 of the 10 comments.
  3. Problem 2

    Red everywhere, and “–” meant two things

    “–” could mean not needed or not done yet. With most cells red, nothing stood out.

    Before · 8+ labels, mostly red
    After
  4. Fix 2

    3 statuses, plus “–”, counted on top

    ต้องตั้งค่ารอผู้ป่วยเลือกเรียบร้อยยังไม่มีรายการสั่ง

    Needs setup · waiting for the patient · done · nothing ordered yet

    Chips with counts show what's left across the hospital.
  5. Problem 3

    Pages, or one long list?

    The team wanted pagination gone. I worried about load time.

    Before · Pages or one list?
    After
  6. Fix 3 · decided by data

    One hospital-wide list

    The September census: about 87 inpatients a day, 11 wards, the largest about 19. Loading 87 rows is fine. Scanning them is the hard part. I also built ward sections; the team compared both hands-on and kept the flat list.
  7. Problem 4

    “A Menu Type means the profile is set”

    My early idea. The real settings page showed Menu Type sits in the doctor's diet order, apart from the dietary profile.

    Before · My wrong guess
    After
  8. Fix 4 · a real screen corrected me

    Menu Type comes from the doctor

    The team confirmed 3 rules: Menu Type is read-only and never blocks anything, tube-fed patients can also eat normal meals, and the only hard gate is dietary profile first.
  9. Problem 5

    Publish To Take Order, or Skip Take Order?

    Both describe what the system does, and neither fits an order that is only tube feeding or milk.

    Before · System words
    After
  10. Fix 5

    Say who picks the menu

    • Normal meals Let the patient choose, or assign the menu
    • Tube feeding or milk only One button: confirm order
    • No profile yet Disabled, with the reason next to it
    • Editing after publishing Back to draft, with a warning if the patient already chose
  11. Result

    Old or new?

    Flip between the list as it was and the list in the prototype.

    Old
    New
Open full screen ↗
InteractiveFilter by status, open a patient, publish a menu. Sample data only.

What I took from it

  • Feedback is a list of symptoms. Group it by the problem before designing.
  • Check ideas against the real screens early. One screenshot overturned my assumption.
  • Data settled the pagination debate faster than opinion.
  • Building an option and dropping it is fine when the team gets to compare both.

Also in the build: admit and discharge as separate sortable columns, scroll position and filters kept when you come back from a patient. No production numbers yet. Next: a ward settings page and cleaning up menus published without a profile.

What I'm learning

In a hospital, a label that's slightly wrong is worse than one that's vague. Most of my decisions here came from asking what happens if a nurse or a patient takes the screen literally.

Next caseTwo bids, mapped workflow first: a LINE OA platform and a licence plate audit system.