LumaCare

The Approach

Instead of listing every possible feature, the design focused on four decisions that directly respond to the problems above:

Visual Identity

LumaCare's visual language was built around trust and calm — a deep navy accent paired with soft neutral surfaces, generous spacing, and a rounded, approachable geometry. The palette and logo needed to feel credible enough for a healthcare product while staying warm rather than clinical.

Information Architecture

How LumaCare Is Organized

The product is organized around 5 primary areas accessible from the bottom navigation — Home, Appointments, Reports, Notifications, and Profile — with Doctor Search and Pharmacy reached contextually from Home. This keeps the main navigation short and predictable, while still giving quick access to the two most time-sensitive tasks.

The Primary Flow

The Core Task: Finding and Booking a Doctor

The main flow we designed end-to-end covers the task most patients need to complete: going from "I need a doctor" to a confirmed appointment.

UX Problems & Iterations

What Changed Along the Way

The main flow we designed end-to-end covers the task most patients need to complete: going from "I need a doctor" to a confirmed appointment.

Early versions revealed a few recurring issues, fixed through iteration rather than assumed correct on the first pass.

Example 1 — Doctor cards: Problem: Initial cards tried to show too much information, making results hard to scan. Iteration: Reduced to key decision criteria only (photo, rating, price, next availability); secondary details moved to the profile.

Example 2 — Home screen visual hierarchy: Problem: An early version treated all sections with equal visual weight, so nothing stood out as "what matters right now." Iteration: The upcoming appointment became the single largest, most prominent element, with everything else secondary.

The Final Product

The 11 screens below represent one continuous flow, but they group naturally into four stages of the user's actual task: finding a doctor worth considering (Discovery), narrowing that list down to one (Decision), completing the appointment details (Booking), and getting a clear confirmation that it's done (Confirmation). This structure — not just screen count — is what the earlier flow and iteration decisions were built around.

Handoff & Specifications

Design work isn't finished when the screens look right — it's finished when a developer can build them without guessing. Alongside the final screens, LumaCare's handoff package includes:

• Spacing & sizing specs — exact padding, margins, and element dimensions annotated directly on key screens

• Component states — default, pressed, disabled, and error states for buttons, chips, and input fields

• Content rules — max character limits, truncation behavior for long doctor names or clinic addresses

• Interaction notes — what happens on tap, on validation error, and expected transition timing

• Accessibility requirements — touch target minimums, contrast ratios, and focus order, tied directly to the design system's accessibility guidelines

Below is a redline example from the Doctor Profile screen, showing the level of detail carried into developer handoff.

Reflection

This project reinforced a few things: reducing information often improves decision-making more than adding features does. Healthcare interfaces need extra clarity because users are rarely in a calm, attentive state. And showing availability and price early removes a major source of friction that's easy to overlook when designing around "features" instead of "tasks."

What I'd test next

Symptom-based search comprehension · doctor comparison usage · filter priorities · booking completion rate · accessibility with less tech-confident users