<- All work
Building now2021–2026

VZTR Help

Hospital visit coordination that respects the patient’s energy — not the group chat.

Product lead, UX/UI, full-stack build

Overview

VZTR Help started as a real problem I lived through as a primary caregiver during the COVID era — then became my UC Berkeley UX/UI capstone, where I pitched the concept, led our team, and mapped patient and visitor flows end to end. Today it is a deployed MVP on the path to hospital-grade visitor coordination: one link, clear rules, no double-booking, and rest when the patient needs quiet.

The problem

When someone is hospitalized, visitation should help recovery — but it often becomes another job for the patient. Friends and family call the patient, the caregiver, or both (50% of visitors in our research contacted both). Schedules collide with hospital caps and visiting hours. Patients want connection but also rest; visitors show up tired or unannounced; coordinators repeat the same updates dozens of times. Existing visitor-management tools optimize front-desk check-in for buildings — not a patient-centered schedule the person in the bed can actually control.

At a glance

One link replaces the group chat. Patients set the rules; visitors self-serve; hospitals sync in the roadmap.

System map

Three sides, one schedule
PATIENT / COORDINATORSets rulesAvailability & restShares one linkVZTR HELPSingle source of truthvztr.help/v/••••••Caps · hours · no double-bookingVISITORSSelf-serve slotsParking & check-in infoNo account requiredFUTURE · HOSPITAL SYNC · EXAMS · REST ALERTS · FRONT DESK

The patient or coordinator owns the calendar. Visitors book through a single link. Hospital systems receive visitor data automatically in the next phase.

User flows

Parallel paths, shared link
PATIENT FLOWVISITOR FLOW1Open visit window2Set hospital rules3Mark availability4Share one link1Open invite link2Read rules & parking3Claim open slot4Confirm & arriveONE LINK

Patient-side setup and visitor-side booking stay in sync — no duplicate calls, no surprise arrivals.

Research

What we measured
RESEARCH SIGNALSBerkeley capstone · interviews & usability testsCall patient & caregiver50%before visitingSchedule via coordinator62.5%not direct with patientPrefer text availability67%over icon-only UI

Findings from Berkeley capstone interviews and moderated usability sessions — not assumptions.

Product surface

Coordinator and visitor views
Coordinator · Room 412TODAY'S AVAILABILITY2:00 PMAvailable4:00 PM1 of 2 bookedTomorrowRest dayPause requestsVisitor invitePICK A TIME · MAX 2 VISITORS · 11AM–8PMWed 3:00 PM — OpenWed 4:00 PM — FullPARKING · GARAGE B · VALIDATION AT DESKCheck-in · Main entrance · Room 412

Availability, capacity, rest days, parking, and check-in guidance — visible before anyone arrives at the hospital.

Gallery

Origin & discovery

The idea did not start in a classroom — it started at a hospital bedside. During the COVID pandemic I was the main caregiver for a close friend fighting cancer. I hit every friction point our research later confirmed: conflicting hospital rules, coordinating who could visit when, guessing whether she had energy for guests, and fielding calls from well-meaning visitors who did not know the full picture. In UC Berkeley’s UX/UI program I brought that experience into our final team project, pitched Visitor Help, and led the group through research and flow design.

  1. Step 01

    Lived problem → design brief

    Caregiving during COVID meant navigating visitor limits, stamina swings, and hospital policy changes in real time — while also being the person everyone called for updates.

  2. Step 02

    Team research plan

    With Kavitha Karunakaran, Janet Limon, Fiorella Bernal, and Rasheem Tareq we ran parallel interview guides for patients and visitors, plus surveys for patients with visitors, patients without visitors, and visitors-only cohorts.

  3. Step 03

    What research surfaced

    62.5% of visitors scheduled through a friend or coordinator; 50% called both patient and caregiver before visiting. Recurring themes: “I want to know who is coming,” “sometimes I just need rest,” and “coordination exhausts the person who is sick.”

  4. Step 04

    Primary persona — Cameron

    We synthesized Cameron Williamson: a detail-oriented children’s book illustrator expecting her third child — wants loved ones nearby but needs predictable, manageable visit windows and zero surprise arrivals.

Patient user flow

The patient (or designated coordinator) stays in control. Hospital rules are captured once; availability is shared through a single link instead of a fragmented group chat.

  1. Step 01

    Open a visit window

    Patient or caregiver creates a visit period — admission dates, room info when known, and who is allowed to coordinate on their behalf.

  2. Step 02

    Set hospital rules & limits

    Enter max visitors per slot, visiting hours, and hospital-specific caps (e.g. 1–3 people). Rules propagate to every invite so visitors see constraints before they request time.

  3. Step 03

    Mark availability & rest

    Block times for rest, procedures, or low-energy days. Usability testing favored explicit “Available / Unavailable” labels over ambiguous icons — 67% of participants chose the text-forward pattern.

  4. Step 04

    Share one link

    Send a single invite link by text or email. Visitors self-serve scheduling instead of calling the patient repeatedly for “is now okay?”

  5. Step 05

    Review & adjust

    See who requested which slot, approve or move visits, and pause all incoming requests when recovery requires quiet — without awkward one-off rejections.

Visitor user flow

Visitors get clarity before they arrive: rules, timing, parking, and confirmation — reducing the guilt of showing up when the patient is exhausted or lost on campus.

  1. Step 01

    Receive invite

    Visitor gets a link from the patient or caregiver — replacing the old loop of calling both parties to find out whether a visit is welcome.

  2. Step 02

    Read rules & context

    View visiting hours, capacity limits, and any notes (e.g. “short visits preferred today”) before picking a time.

  3. Step 03

    Claim a slot

    Choose an open window; the system prevents double-booking and over-capacity slots so two groups cannot collide in the same period.

  4. Step 04

    Confirm & prepare

    Receive confirmation with check-in guidance and parking information — lot or garage, validation rules, entrance, and where to go once inside — addressing top visitor pain points from affinity mapping: not knowing where to park, where to go, or who to ask at the hospital.

  5. Step 05

    Check in (roadmap)

    Future state: QR or kiosk check-in tied to the scheduled visit, aligning with hospital visitor-management systems without putting the burden back on the patient.

Design & validation

We treated Visitor Help like products that outgrow the classroom — the same arc as design-school projects that became real companies: research → narrow scope → test → ship. Competitor analysis (Envoy, SwipedOn, iLobby, etc.) showed strong front-desk tools but a gap for patient-led scheduling.

  1. Step 01

    Ideation & prioritization

    Crazy 8s, “I like / I wish / What if,” and a priority matrix focused the team on scheduling + communication — deprioritizing nice-to-haves that did not reduce patient load.

  2. Step 02

    Storyboard & IA

    Storyboarded Cameron’s scenario: overwhelmed before admission, wanting family nearby but not the mental overhead of organizing them. Affinity diagrams clustered timing, hospital navigation, feelings, and coordination pain.

  3. Step 03

    Wireframes → hi-fi prototype

    Low- and mid-fidelity flows for patient availability and visitor scheduling evolved into a hi-fi Figma prototype with Tajviraj display type, Libre Franklin body, and a warm purple/gold palette tested for contrast and calm.

  4. Step 04

    Usability & preference tests

    Moderated sessions on availability UI and navigation color combinations. Participants wanted readable states, professional warmth, and less cognitive load — feedback that directly shaped the MVP UI.

From class project to hospital product

The capstone proved the concept; the MVP proves I can build it. The north star is a service hospitals offer — integrated with their visitor policies, not another app families discover in crisis.

  1. Step 01

    Shipped MVP

    Built and deployed VZTR Help with authenticated visits, slot logic, and Postgres row-level security — moving from team prototype to a working product Roberto owns end to end.

  2. Step 02

    Hospital sync

    VZTR Help will sync with hospitals for accurate visiting information. When a doctor schedules an exam, that time is automatically blocked off. When a doctor decides the patient needs rest, the patient, coordinator, and visitors are notified. The hospital front desk and nurses' desk will automatically have each visitor's information and visiting time ready in their systems.

  3. Step 03

    Arrival experience

    QR check-in, pre-registration, optional ID scan, and parking details on the visitor confirmation — so front desk staff see expected visitors without the patient re-explaining the schedule.

  4. Step 04

    Vision

    Hospitals provide VZTR Help as part of admission — patients get control, visitors get clarity (including parking), caregivers get relief. Happy visitors because the system protected the person they came to see.

Approach

  • 01Grounded the product in lived experience: caregiving for a friend with cancer during COVID, then validated with interviews, surveys, and affinity mapping across timing, hospital friction, feelings, and coordination load.
  • 02Led a Berkeley team (research, IA, visual design) through Crazy 8s, “I like / I wish / What if,” and a priority matrix — narrowing to scheduling plus communication in one place.
  • 03Designed dual-sided flows: patients set availability and rules; visitors claim slots through a single shared link — inspired by award-winning hospital apps (Providence, Nemours) and class-project-to-company stories like Airbnb’s early design-school origins.
  • 04Validated availability UI with moderated tests (67% preferred explicit Available/Unavailable copy over icon-only states) and palette preference tests for warmth and contrast under stress.
  • 05Shipped a full-stack MVP (Next.js + Supabase) with slot claiming, capacity checks, and RLS — bridging from academic prototype to something hospitals could eventually offer as a service.

Outcomes

  • Research-backed problem framing: patients need advance notice, control over rest windows, and relief from being the switchboard.
  • Documented patient and visitor user flows — from setting hospital rules to confirming a visit — used as the backbone of the case study process timeline.
  • Deployed MVP at vztr-help.vercel.app — not a Figma-only deck.
  • Clear product roadmap: hospital sync for accurate visiting info, parking on the visitor side, QR check-in, pre-registration, and front-desk handoff.

Stack

FigmaUser research & usability testingNext.jsTypeScriptSupabase (Postgres + Auth)Tailwind

Want the deeper story?

My AI advocate can walk you through the decisions behind this project - or how it maps to a role you're hiring for.