Get in touch

Case study · Work in progress, on test data

ProVita

Web design and a hospital management system for ProVita, a fertility hospital in Tema, Ghana.

Role
Product designer, build lead
Team
With Smart Ekene, and AI agents
Scope
Website, patient portal, front desk
Year
2026
39Patient and front desk storiesSource: 21 patient, 18 front desk
298Commits in six weeksSource: git, 10 Sep to 24 Oct 2026
56Questions for the hospitalSource: the hospital questions list
In short
The project
ProVita Specialist Hospital is a fertility hospital in Tema, Ghana. It needed a hospital system behind its new website: a portal for patients and screens for every member of staff.
The problem
Everything a patient sees in a portal was typed by somebody at the hospital first. If a staff screen doesn't capture a value, the patient's screen stays empty, or worse, wrong.
What I did
I broke the requirements into stories by role, designed the patient's side first, then read every patient screen backwards to decide what each staff screen must capture. Four decisions shaped it: invitation-only access, a short session, one source for every value, and a front desk that sees who and when, never what is wrong.
My part
Product design, the design system with Smart Ekene and its translation into code, and directing the build with two AI coding agents, Claude Code and Codex. Smart led the rebrand. We designed the website together, and Smart built it in Webflow.
Where it is
The patient portal and the front desk work end to end on test data, and a member of staff at the hospital is testing them now. Nurse and doctor screens are next, and 56 questions are waiting on the hospital.
How I worked

  1. Plan

    126stories

    Patient, front desk, nurse, doctor

  2. Design

    4decisions

    The patient's side first, in Figma

  3. Build

    298commits

    With Claude Code and Codex

  4. Check

    56questions

    Each one with a safe default

Chapter 01The brief

A new website, and a hospital system behind its Patient Portal button.

ProVita's public face came first. Smart Ekene, a designer and Webflow developer, led the rebrand. We designed the new website hand in hand, and Smart built it in Webflow: a calm, blue site built around booking an appointment and understanding your options.

Behind that site's "Patient Portal" button there was nothing yet. Part of the requirements came from the hospital, and I added scenarios of my own. Together they described the whole hospital system: patients, the front desk, nurses, doctors, finance and the hospital admin. I used them to plan the design, then broke them into user stories: short descriptions of what each person needs to do, one set per role, so each role could be designed and built on its own.

In this case study 39Next 87

The website is still in progress. Screens captured on 26 October 2026.

  1. P1The record is deeply privateFertility care is personal. A wrong person opening the portal is the main risk.Solved in Decisions 02 and 03
  2. P2Phones are sharedA family phone or a shared computer can leave a portal open for someone else.Solved in Decision 03
  3. P3Somebody typed every valueIf no staff screen captures it, the patient's screen has nothing to show.Solved in Decision 01
  4. P4The desk needs less, not moreReception needs who, when and whether. Clinical detail at the desk is a leak.Solved in Decision 04
  5. P5Open hospital decisionsOpening hours, services and deposits weren't settled when the build started.

The five problems this project had to solve. Each decision below names the ones it answers, by number.

Chapter 02Reading backwards

The patient portal is a mirror.

I designed the patient's side first. Then, before drawing a single staff screen, I went through every patient screen and asked the same three questions of each value on it: who creates it, at what moment, and what their screen must capture so it can appear here.

Decision 01P3Somebody typed every valueThe problemIf no staff screen captures it, the patient's screen has nothing to show.

Design staff screens from what the patient sees.

Every value on a patient screen falls into one of three kinds. Typed: a person entered it once, so it needs a staff screen. Worked out: the system calculates it, so it needs no screen at all. Set up once: someone sets it up in advance, so it needs a settings area.

Instead of
Starting from the requirements' list of staff tasks. It lists what staff do. It doesn't say what they must write down for the patient to see it later.
Trade-off
Staff screens wait. Nothing on the staff side could be designed until the patient's screens were settled.
Proof
A gap the mirror caught. The patient's appointment card shows why a booking was cancelled, but no staff screen anywhere asked for a cancellation reason. The front desk's cancel screen now does.

The third kind is the one nobody designs. Nobody asks for it as a screen, and most of the hospital's open decisions live there. Try it below.

Try it · Reading backwards

Abena's portal stays empty until somebody at the hospital fills it.

Do the hospital's side, one step at a time, and watch what appears on her screen.

At the hospital

    What Abena sees

    DashboardAppointmentsResults

    Good morning

    Here's everything you need to know right now

    Next appointmentNoneNothing booked yet
    New results0Nothing released yet

    Recent results

    No results yet

    Appointments

    No appointments yet

    If you need urgent helpNot set up yet

    Each step comes from the project's own list of what every staff screen must record, written by reading the patient's screens backwards. Names, dates and amounts are test data.

    Chapter 03Letting a patient in

    A portal you're invited into.

    Decision 02P1The record is deeply privateThe problemFertility care is personal. A wrong person opening the portal is the main risk.

    The hospital invites. The patient proves who they are.

    A portal account starts from an invitation the front desk sends to the phone or email on the patient's record. To activate it, the patient confirms their hospital number, date of birth and the last four digits of that phone, then sets their own password.

    Instead of
    Open sign-up. Anyone could claim to be a patient and go looking for a record.
    Trade-off
    A patient can't start alone. They need the desk to invite them, and links run out, so "expired" and "already activated" needed screens of their own.
    Proof
    Each link works once, for 72 hours, and the system stores only a scrambled fingerprint of it, never the link itself. The front desk can re-send an invitation but never sees a password or a code.

    Signing in opens on the password, with a one-time code by text as the other way in, because every text message costs the hospital money. I drew every state a patient could land in, including the unhappy ones: a code that hasn't arrived, too many wrong tries, a link that's expired. The build has more than 20 sign-in and recovery screens, down to "Online recovery unavailable", which sends a patient to Patient Services when their details can't be checked online.

    Invited. Activate your portal access: hospital number, date of birth and the last four digits of the registered phone.
    Every way in, designed and builtActivate your portal access: hospital number, date of birth and the last four digits of the registered phone.
    Chapter 04A short session

    Thirty minutes, on purpose.

    Decision 03P1 P2Phones are sharedThe problemsThe record is private, and a family phone or shared computer can leave a portal open for someone else.

    Sign a patient out after 30 idle minutes, 15 on a shared device.

    On 20 September I reversed an earlier plan to keep patients signed in for 30 days. The risk I kept coming back to was an unattended phone in a house where somebody else has an interest in what's on it. The shared-device checkbox can only make a session shorter, never longer.

    Instead of
    30 days signed in. Convenient, and common in consumer apps. This record is about fertility treatment.
    Trade-off
    People get signed out more. So the timeout needed two screens of its own: a "Still there?" countdown two minutes before, and a clear "Session ended" screen after.
    Proof
    Checked on the build. On a patient's own device, the portal loads at 5 and 29 idle minutes and shows Session ended at 31. On a shared one, it loads at 5 and 14 and ends at 16.

    Getting the clock right took two fixes. First, patients were signed out at 35 minutes instead of 30, because the portal didn't check the session often enough. It now checks every 5 minutes, and an automated test keeps it that way. Then the warning popped up for people who were still using the portal, because moving to another page didn't reset its countdown. Now a page change counts as activity, and the countdown follows the hospital server's clock.

    Try it · A short session

    Leave the portal alone and watch what happens.

    Pick a device, then press play, or drag the timeline yourself.

    Idle for0:00

    Signed in. Reading a result, or just looked away.

    The timings are the portal's own: 30 minutes on your own device, 15 on a shared one, with the warning two minutes before. The dialog and the signed-out page use the built product's wording.

    Chapter 05The patient's home

    What needs you, first.

    I designed home to answer one question: what do I need to know right now? Three cards up top: the next appointment, the things waiting on you, and new results. Below them is a list of actions, each with how urgent it is, like a pre-visit form your doctor needs today. Results only appear once the care team has released them.

    A brand-new patient sees a genuinely empty home. I treated that as a success state with one clear next step, booking a first appointment, so it never reads as broken.

    New patient. A new patient's home: nothing scheduled, nothing waiting, and one action: book your first appointment.
    The patient's home, designed and builtA new patient's home: nothing scheduled, nothing waiting, and one action: book your first appointment.
    Chapter 06Appointments and medicines

    Moving a booking shouldn't cost you twice.

    Fertility treatment runs on a cycle, so appointments move a lot. I made the deposit a patient already paid move with the booking when they reschedule, and the screen says so before they confirm: "Your deposit carries over." The old slot, the new one and the doctor sit side by side, so there's nothing to remember.

    Prescriptions show each medicine with how to take it, who prescribed it and whether it's active. A patient can set their own reminder for each dose. The screen says plainly that reminders live on their device and don't notify the care team, so nobody assumes the clinic is watching.

    Treatment also needs signed consent. The doctor sends the form to the portal, and the patient reads it, signs it themselves or declines.

    Booking, from both sides.

    Booking takes three steps: a time, then the service and how to pay, then a review. Abena can pay online with Mobile Money or a card, or pay at the hospital, and she sees the deposit and the estimated cost before she commits. The review shows the cancellation policy in plain words: cancel at least 24 hours ahead for a full refund, paid back to her ProVita balance.

    If no time suits her, she can join the waitlist from the same screen. Bookings that need a person land in the front desk's Requests list: the same request, seen from the other side.

    Pick a time. Step 1: a time on the calendar, in Ghana time, with a link to join the waitlist if nothing suits.
    Booking an appointment, both sidesStep 1: a time on the calendar, in Ghana time, with a link to join the waitlist if nothing suits.

    Her record, and who can change it.

    Abena can see everything the hospital holds about her. Her name, date of birth, sex and hospital number confirm who she is, so she can't edit them herself. She sends a correction request instead, and the front desk approves it only after checking a supporting document, like an ID card. Every decision is logged with a name and a time.

    Results appear only after the lab and her care team have released them, each with a download. Invoices show her hospital balance and every payment in and out.

    Profile. What ProVita holds about her. Identity details are confirmed at reception and changed only by request.
    Her record, both sidesWhat ProVita holds about her. Identity details are confirmed at reception and changed only by request.
    Chapter 07The front desk

    The other side of the mirror.

    I wrote the front desk's 18 stories from the backwards reading of the portal: register a patient, catch a duplicate, invite them to the portal, book, reschedule, cancel, check in, run the queue and the waitlist. Every value a patient sees that starts at the desk has a story that captures it, and a test keeps that list honest.

    Decision 04P4The desk needs lessThe problemReception needs who, when and whether. Clinical detail at the desk is a leak.

    The desk sees who, when and whether. Never what's wrong.

    Front desk screens show identity, contacts, appointments, arrival and whether a patient is ready to pay. They never show notes, results, diagnoses or prescriptions. The queue board shows names and stages, never the reason for the visit, because it may be seen by people waiting.

    Instead of
    Giving reception the full record because it's simpler to build one patient page for everyone.
    Trade-off
    More hand-offs. The desk can flag "looks urgent", but deciding urgency belongs to nursing.
    Proof
    Every change is signed. A name, date of birth or sex can only change with a reason and the document seen, and the old value stays in the history.

    The desk also catches what falls through. A missed appointment, an unpaid deposit or an urgent arrival without ID each becomes a task that closes itself once it's fixed. When a slot frees up, the waitlist offers it to the first patient it fits and holds it for them for two hours.

    Today. Today's desk on a working day: who's expected, who's arrived, and a "Next to check in" card for a patient running late.
    A day at the front deskToday's desk on a working day: who's expected, who's arrived, and a "Next to check in" card for a patient running late.

    When the usual flow breaks.

    Then the cases that go wrong at a front desk. If what reception types matches an existing patient, the system stops and asks for a reason before it creates a second record for the same person. Someone too unwell to give their name is registered with a temporary label and sent straight to the nurse, to be identified later. A missed appointment is marked as a no-show, and when a doctor asks to see a patient again, it reaches the desk as a booking to make.

    All patients and staff on these screens are made-up test data.

    Chapter 08One system, two tools

    One design system in Figma, the same one in code.

    Smart and I built a design system in Figma that we use across our projects: colour, type, spacing and around 40 base components. I translated it to code as 54 design tokens, the named colours and sizes the screens are built from. Each one matches a Figma style and has a light and a dark value. One rule kept the two in step: a new value goes into Figma first, then into code. When the written brief asked for a deep medical green, Figma won. The real design is blue, like the ProVita logo.

    I directed the build with Claude Code and Codex, two AI coding agents, each owning its own screens. I wrote the rules, the stories and the questions for the hospital, and I reviewed what they made. Where the hospital hadn't decided something, like opening hours, the system runs on a safe default and the question goes on one list. There are 56 so far.

    For research I use my own design library: 155 UI kits and 4,324 tagged screens. For the sign-in code, I compared how other products mark the box you're typing in and what they do after a wrong code.

    Try it · Design tokens

    One card, two themes, one set of tokens.

    Switch the theme, then point at a token to see where the card uses it.

    KO

    Fertility Consultation

    Dr Kwame Osei · 19 Sep, 10:30 AM

    Confirmed
    Where
    Consultation Room 4
    Deposit
    GHS 300, paid
    RescheduleView details

      Values from the portal's code. The main blue (#335cff) stays the same in both themes; backgrounds, text and borders change.

      Sep – Oct 2026Work in progress

      September

      1. First commit
      2. Design tokens pulled from Figma
      3. Patient sign-in done, the 30-minute decision
      4. Front desk stories ready for design

      October

      1. First questions to the hospital
      2. Nurse dashboard under way
      3. Doctor stories draftedLatest

      From the git history and the project's own documents.

      Chapter 09Where it stands

      Two roles built, and in testing at the hospital.

      The patient portal and the front desk work end to end with made-up patients: invite, activate, sign in, book, reschedule, check in. A member of staff at ProVita is testing them now. It's too early for usage numbers, so I have none to show, and I won't guess at any. Nurse screens are in progress and the doctor's stories are written.

      What I've learned so far:

      1. Ask the set-up questions on day one. Opening hours, the services list and deposits sit behind many screens, and they're still open. I'd put them to the hospital alongside the requirements, not after the build began.
      2. Treat a security choice as a design job. The 30-minute timeout only worked once it had screens of its own, and both bugs I found were in how the clock was kept, not in the screens.
      3. One owner per screen. Splitting the screens between agents, and writing down who owned what, kept two builders from overwriting each other.

      Credits

      Rebrand
      Smart EkeneDesigner and Webflow developer, who led it
      Website
      Smart Ekene and Egbemode AbayomiDesigned together, built in Webflow by Smart
      Design system
      Smart Ekene and Egbemode AbayomiShared across our projects
      Product design, stories and build direction
      Egbemode AbayomiFigma, Claude Code, Codex
      The client
      ProVita Specialist HospitalTema, Ghana