top of page

Two products built on one platform. A B2C patient app and a B2B staff app for clinics, sharing one live status for the whole visit, from the first phone call to results.

Kindpace App

Kindpace App - Hero image

Project Overview

A clinic visit with no black box

 

I spent four years as a medical assistant before moving into product design. I watched patients check in and disappear into a process nobody could see. Kindpace is my answer to that. I designed it as one underlying project with two products, a B2C app for patients and a B2B app for clinic staff, and built a working prototype of both by directing Claude as my AI build partner.

Role: Product designer & clinical lead

Solo. I set the product direction, wrote every prompt, reviewed every build and made the design decisions.

​

Timeline: 4 weeks ​

​

Tools: Claude, Notion and Figma

​

Scope: 

2 products · 5 roles · 4 clinics

​

B2C patient app and B2B staff app. Primary care, dental, cardiology and eye.

Business to Consumer Product

Kindpace Patient Mobile App

​

A mobile app patients download and use themselves. It's free for patients and offered through their clinic.

​

  • Booking, pre-check-in and the live wait time

  • New patient paperwork, forms and signatures

  • Results, care instructions and bills

  • 10 languages, including right-to-left Arabic

View Kindpace Patient App

Business to Business Product

Kindpace for Clinics

​

A staff app the clinic buys, running on iPad, Android tablet and desktop, with a role picker for each team member.

​

  • Front desk: queue, scheduling, registration, billing

  • Nurse/MA: rooming, vitals and intake

  • Physician: visit notes, plans of care, results

  • Admin: live operations and team performance

View Kindpace Staff App

Problem

Everyone holds one piece of the visit

​

  • Patients wait blind. After check-in they don't know if they're next or 45 minutes away. Patients with limited English get even less.

  • Staff work from fragments. Front desk, nurse and doctor each see part of where a patient is. Handoffs happen by walking over and asking.

  • Paperwork lands on the front desk. New patients fill out clipboards in the lobby, and staff re-type it. Errors in allergies and medications start here.

  • Problems surface late. Inactive insurance, unsigned consents and bottlenecks get found after the patient is already waiting.

Solution

  • One live status for the whole visit, shared by the patient's phone and every staff role.

  • A B2C patient app for booking, pre-check-in, live wait time, forms, results and bills, in 10 languages including right-to-left Arabic.

  • A B2B staff app with a view for each role: front desk queue and scheduling, nurse rooming and intake, physician notes and plans of care, and admin performance.

  • Phone-first new patient intake. The front desk books in three steps, and the patient finishes the rest of the paperwork in the app before the visit.

My Impact

From a brief to a working two-app prototype

​

This is a concept, so there are no live users yet. What I can show is the scope I defined and shipped, and the design problems I caught and fixed along the way.

 

  • 2 products on one platform: a B2C patient app and a B2B staff app that update each other live

  • 10languages, including right-to-left Arabic, across both apps

  • 3,185 interface strings written and translated into 9 languages

  • 6 → 3 required front desk steps to book a new patient by phone

  • ~60 patient screens, plus about 30 staff views across 5 roles

  • 15 staff app gaps found in one review and fixed in one round

  • 36 automated walkthrough tests that drive both apps end to end

  • 5 paperwork parts that sync from the patient's phone to the chart

​

Along the way I turned the original v1 design brief into a v2 brief that matches what was built. I also added a Kindpace Privacy Notice and Terms of Use, written as sample text and marked for legal review.

Key Design Decisions

 Design Decision Wating 1.png

Wait time on both sides of the visit

Gap

The patient's phone showed a wait estimate, but staff only saw a status. Nobody at the desk could tell that a patient had sat in checkout for 71 minutes. My first fix also showed the phase twice: a status tag plus a separate timer.

​

Fix: One label carries both, like “With provider · 22 min”. It turns red past a limit for each phase: 10 minutes in the lobby, 20 rooming, 10 waiting for the provider, 30 with the provider, 10 at checkout. The patient journey lists the time in every phase. The patient sees “About 12 minutes until you see a nurse” and their place in line.

​

 Why it matters: Waiting is the biggest complaint in a clinic, and it's invisible to the people who can fix it. Now staff see the wait the way the patient feels it, phase by phase, and can act before it runs long.

Design Decision Training 1.png

Training built around each role's real workflows

Gap: Training was a checklist of screens. It told a new MA where things were, not how to room a patient. Tapping Try it sent them to the page and the steps disappeared.

​

Fix: Each role gets its own workflows, such as Room a patient or Check in a patient, with numbered steps. Try it opens the real page with the steps pinned at the top. Staff tick each step as they go, and finished workflows count toward their progress.

​

Why it matters: Front desks and MA teams turn over often. Training inside the live tool, by role, gets a new hire productive without pulling a coworker off the floor.

Design Decision Live Update 1.png

Live team updates, where they help and only there

Gap: Handoffs happened by walking over and asking. But a feed on every screen became noise, especially for a provider moving between exam rooms.

​

Fix: Each change a teammate makes, like a check-in or a patient sent to the provider, appears in a live feed with who did it and when. New items are marked until seen. The feed sits beside the front desk queue, can be minimized, and is a switch on the rooming board. Providers don't see it on their main screen. Front desk, nurses and providers also have a Team updates page.

​

Why it matters: The same information helps the front desk and distracts a provider. Letting each role decide where it shows keeps it useful.

Design Decision One patient app 1.png

One patient app for every clinic

Gap: A patient who sees a family doctor, a cardiologist, an eye doctor and a dentist has four portals and four passwords. No single place has their full medication list.

​

Fix: One Kindpace account connects to all four clinics. Appointments, documents, medications and health history are combined, with each item labeled by clinic and provider. Booking starts with what the patient needs and then shows providers from every clinic that offers it. Each clinic's staff see only their own chart, plus the date and type of the patient's visits elsewhere.

​

Why it matters: Patients managing several conditions are the ones most likely to have a missed medication or a duplicate test. One place for everything is a safety feature, not just a convenience.

Design Decision Patient share 1.png

Patients share records, but only what a provider verified

Gap: Patient-controlled sharing is fast, but a clinic can't safely act on a diagnosis the patient typed in. Without a source, shared records are just another form to re-check.

​

Fix: Only items from a provider's signed records can be shared, each labeled “Verified by” the provider who signed it. Things the patient reported are listed as not shared until a provider confirms them at a visit. The patient's note travels with the share but isn't added to the record.

​

Why it matters: The patient decides what moves and when. The receiving clinic knows who stands behind each item, so it can be trusted without a fax and a phone call.

Design Decision Performance 1.png

My performance: feedback, not a leaderboard

Gap: Only the admin saw team numbers. Staff got no feedback until a review, and a ranked list of coworkers would make people defensive rather than better.

​

Fix: Every role has its own My performance page with numbers for their own job. They can compare with earlier today, the same day last week, their 30-day average or any date, against the team's usual range, which never names anyone. AI recommendations suggest one change each, and the person marks it “I'll try this”, Done or Not helpful.

​

Why it matters: People improve when feedback is specific and compared to their own past, not to a named coworker. The page says up front that these numbers are feedback, not targets.

Kindpace started with my own experience, first as a medical assistant working the clinic floor, then as a patient keeping track of my care across several clinics.

​

As a medical assistant

We ran the day from memory

  • Which room, and whose patient? We relied on remembering where each patient was and which provider they were waiting for.

  • Rooms by provider broke down on uneven days. Each provider had their own rooms, but when one provider had many more patients than another, we borrowed the other rooms. That's when the confusion started.

  • Who's next? It was hard to tell which patient needed to be seen first, or who was up next.

As a patient

One portal for every clinic

  • A separate portal for each clinic. Primary care, dental, eye and specialists each had their own, which meant multiple apps and confusion about where things were.

  • Too many logins. Keeping track of credentials for every portal was its own job.

Research & Background

The tools I looked at each solved part of this. Some portals and phone health apps can pull records from more than one health system. But I didn't find one app that brings together every clinic a patient uses, with booking and live visit status for each, or one where the patient's app and the clinic staff's app talk to each other both ways.

​

Why a prototype

I decided to design the app I wished I'd had, on both sides. Building a working prototype was the fastest way to find out what that product needs to be, and whether one shared live status could fix both the confusion on the clinic floor and the scattered portals on the patient's phone

​

​

​

The Gap I Saw

Building the prototype with Claude was an incredible experience. I worked prompt by prompt: Claude built, I tested each build by walking through it as the user, and then I revised the prompt and ran it again, over and over. It let me see the vision working much sooner than a Figma prototype, where I'd have to connect every screen and element by hand. I was new to coding with AI when this started, and I learned that the prompt is the spec. Clear goals, real constraints and a way to check the result mattered more than clever wording.


1  Ask first: 

I had Claude ask clarifying questions before building, each with a recommended option. Choosing between concrete options was faster and more precise than writing a long spec.

​

2  Write constraints, not just features

I named the rule as well as the feature: who must fill a field, what must match, what stays optional, what order to work in (“translate after”, “all at once”).

​

3  Verify against intent

I asked questions that check the build, like “does each clinic have its own staff?”. I also reported bugs with the exact input that failed.

​

4  Walk the roles

I acted as each person in a side-by-side live demo: Rosa at the desk, Maria rooming, Dr. Chen signing, and the patient on the phone.

​

5  Automate the walk

36 Playwright scripts click through flows end to end in both apps and flag errors. Others gather every untranslated string in all 9 languages.

​

6  Review screenshots

Every change was checked on screen, at tablet and phone size and in other languages, before I approved it.

​
 

Prototyping & Testing

Reflections

The prompt is the product spec

The best results came when I described the user, the rule and the exception, not the screen. Letting the AI ask me questions first showed me what I hadn't decided yet.

Clinical experience finds the real gaps

The fixes that mattered most, like who can sign, how a patient proves who they are, and how new patients really book, came from remembering the clinic floor, not from the requirements.

A flow that works can still be wrong

My first registration flow passed every test and still didn't fit a front desk on a busy morning. Walking through it as the person using it is what caught that.

Every change can break consistency somewhere else

New features brought back old problems: untranslated text, mismatched rules, wrong counts. Automated checks and screenshot reviews after every round kept the two apps in line.

Disclaimer

​

Kindpace is a concept project. Clinics, staff and patients shown are fictional sample data. The privacy notice and terms are sample text and need legal review. Built by directing Claude as an AI build partner.

bottom of page