ANODA Discuss your product

Healthcare CRM design, one care journey, both sides

Clay is a care-management platform for care teams and their patients.We redesigned the care-team CRM and designed the patient app from scratch.

Clay’s patient record on the care team’s web app: the patient, her allergies and journey progress, and a chart of her health data; Clay’s patient app asking for a date of birth before showing an appointment
342
screens and states for the care team’s web app and patient app
AI
assistance assistant, chat in the record, suggestions to confirm
5
experts

Clay is a care-management platform : nurses, care guides and clinicians run patient journeys and conversations in a web app, and their patients book visits from a phone. We audited the clinician product and redesigned its workflows for desktop, tablet and mobile, designed the patient app for iOS, Android and desktop, and tied both to one design system in dark mode, with a refined logo and brand guidelines.

What one care journey asks of two products

The patient’s side first, then the care team’s, around the same appointments and messages:

  1. Book

    • A link by text message
    • Date-of-birth check
    • Provider and time slot

  2. Join

    • Activation and login
    • Profile
    • Health information

  3. Talk

    • Chat and attachments
    • Calls and video
    • Notifications

  4. Follow up

    • Upcoming and past visits
    • Rescheduling
    • Care programs

  5. Find

    • Patient lists
    • Filters and search
    • Patient 360

  6. Act

    • Journeys and timeline
    • Tasks and care gaps
    • Notes, labs and orders
The whole record A readable screen
Everything about a patient stays one click away, but only what matters for the next call is open.
Faster with AI The clinician decides
Suggestions and generated drafts are marked as such and wait for a person to accept them.
Desktop depth Tablet and phone
The patient list, its controls and the menu keep working when the care team leaves the desk.

Patient 360: the whole record, one level at a time

Found
Demographics, allergies, mood, programs, journeys, tasks, health data, notes, appointments and care gaps all belong to one patient, and a care guide has a few minutes before a call.
Decided
Who the patient is and what is risky stays pinned at the top, with where care stands beside it; the rest of the record lives in tabs that open one at a time without leaving the page.
For the user
Before a call, the care guide sees the patient’s allergies and journey progress without opening a second screen.
Patient 360 for one patient: her details, allergies and mood pinned at the top, journey progress and smart actions beside them, then tabs for activity, appointments, timeline, journeys and AI, and a chart of her health data
After: Patient 360 for one patient, health data below the tabs

  1. Who the patient is

    Details, allergies, mood and journey progress.

  2. One record, several tabs

    Activity, appointments, timeline, journeys, AI.

  3. The record itself

    The health data for the tab in view, opened without leaving the page.

How the work progressed

From competitor research and an audit of the running product to two sets of UI, one system and a handoff the development partners could build from.

  1. Discovery

    How other healthcare products handle booking, care and support, before anything was drawn

    Artifact Competitor research and the first information architecture

    Competitor research table: how Parsley Health and Modern Age handle making an appointment, with pros, cons and screenshots of their sign-up and booking screens, including Parsley Health’s photo of a clinician with a patient

  2. UX audit

    Where the care team’s existing product slowed them down

    Artifact An audit of the running workflows, each finding with a recommendation

  3. User flow

    Every path through appointments, journeys, care gaps and messages, for each role

    Artifact Multi-role user flows

  4. Wireframes

    What each patient and care-team screen holds, before colour

    Artifact Wireframes for the patient app and the clinician web app

    Three patient-app wireframes for changing the phone number: the password step empty, with the keypad, and with the required-field error

  5. UI — Web CRM

    A dense clinical workspace that still reads calmly in dark mode, with AI inside the work

    Artifact Moodboards, visual directions and the final UI at desktop, tablet and mobile sizes

  6. UI — Patient app

    A patient app that speaks plainly, on the phone and at a desk

    Artifact The patient app for iOS, Android and desktop, with every message state

  7. Delivery

    What the development partners needed to build without guessing

    Artifact Screen maps, clickable prototypes, UI kits and a Zeplin export

The path from a text message, mapped before a screen was drawn

Found
A patient arrives from a text message; a nurse arrives from a long list of patients. Both end up at the same appointment, and either path can fail halfway.
Decided
The patient’s way in was mapped screen by screen with its failures first: a date of birth that doesn’t match, a wrong entry on the keypad. Then one navigation per product.

  1. From the text message to the date-of-birth check

    The link in the message, the date-of-birth field with the keypad and the calendar, the wrong-entry branch, and the loading states before the provider step.

    Open the full map
    Part of the appointment screen map: a text message with the booking link, then the date-of-birth screen empty, with the keypad, filled with the calendar open, with the year picker, and the error branch below

  2. Picking a time, and a slot that’s already gone

    The specialist’s calendar, a date, a time slot, then the case where another patient took it first and the app has to say so.

    Open the full map
    Part of the appointment-booking screen map: the specialist’s availability calendar, a date and a time slot selected, the Time slot is not available message, and the updated slots without it

  3. Care gaps, from an empty record to a disease page

    The care team’s side: no chronic diseases yet, the drawer that adds one, then a controlled or uncontrolled disease, each with its own clinical guidelines.

    Open the full map
    Part of the care-gaps user flow: whether chronic diseases are filled in, the empty page and the Add chronic disease drawer, the page with added diseases and its content, then whether the disease is controlled
The tabs of a patient record: Patient 360, Activity, Optimization, Appointments, Timeline and Journeys, with the sub-tabs Health Monitoring, Care Management, Care Gaps and Member and Family History below

Two levels of tabs inside one record

Patient 360, activity, appointments, timeline, journeys and AI sit in the top row; the record’s own sections sit in the row below, so the page never changes.

  • Competitor research
  • Information architecture
  • Multi-role user flows
  • Clickable prototypes

Six jobs across the two products

The AI help first, then the care team’s day, then the patient’s side of it.

An assistant that counts the day’s work

Found
A nurse with hundreds of patients cannot open each record to find out who needs attention first.
Decided
Clayton opens beside the patient list with what needs attention, counted: recommended journeys, new health risks, readmit predictions, navigation opportunities. A field below takes a question in plain words.
The patient list dimmed behind a Clayton panel that lists recommended journeys, new health risks, risk score predictions and other suggestions, each with a number, above a field that says Ask Clay

Asking inside the record

Found
Once a clinician is in one patient’s record, the next question is about that patient, and a blank chat box asks too much of a busy person.
Decided
An AI tab inside the record with starting prompts (next best action, lab results, follow-up plan, risk factors) and a message field, so the first question is one tap.
The AI tab in a patient record with the question How would you like to start, nine prompt chips such as Next Best Action and Lab Results Analysis, and a message field

Everything that happened, in one feed

Found
Messages from the care team, payments, lab results and agreements arrive in different places, and nobody can tell what happened to a patient this week.
Decided
One activity feed per patient, grouped by day, with a filter and a time range, and each file attached to the event that produced it.
The Activity tab of a patient record with events grouped under today, yesterday and an earlier date: a message from a doctor, two payments, a lab result with its file and an agreement with its file

Care gaps and the notes that close them

Found
A patient with several chronic conditions has a long list of open items, and a care guide has to see which condition is uncontrolled and what is missing for it.
Decided
Each condition opens into its description, medication, education material, clinical guidelines and tests, with the unresolved gaps marked in red. Notes open in a side drawer, so the record stays in view.
The care gaps tab with the diabetes row open: general information, education resources, clinical guidelines with resolved and unresolved items, and medical tests, above the collapsed rows of other chronic diseases
A Create Note drawer over the care management tab with a subject field, a note field and Cancel and Create buttons

Booking from a text message

Found
A patient opens a link on their phone and has to prove who they are, find a provider and pick a slot, and any wrong turn ends in a phone call to the clinic.
Decided
A short path from the text message to a confirmed visit: a link, a date-of-birth check, the provider’s available times and a confirmation.
A text message thread from Clay Healthcare with a link to complete an appointment booking
The appointment confirmation screen with the provider, her details, the selected time and a Confirm button

The patient app between visits

Found
After booking, patients need to find their next visit, change it or cancel it without calling anyone.
Decided
Upcoming and past visits in two tabs, each visit with its time and provider and a way to reschedule, and a plain confirmation before anything is cancelled.
The Upcoming tab of the patient app with one appointment: the provider, her details, the time and a cancel button next to a Reschedule button

One brand on both screens

Found
A patient’s phone and a care team’s dense dark workspace could easily read as two companies that happen to share a logo.
Decided
The brand guidelines went into the UI kit as sheets both products draw from: the logo on the dark background, colour families with their shades, Inter for headings and Poppins for the rest, and one set of health illustrations.
Two UI kit sheets side by side. Colors: greys from white to near-black, Vibrant clay, Sunrise yellow, Fern green and Moonstone blue in six shades each, and three gradients, every swatch with its hex value. Typography: Inter with its heading sizes, then Poppins, each with a full alphabet and numerals
The Clay logo, a radiating mark above the spaced CLAY wordmark, in light grey on the UI kit’s near-black background
The UI kit’s Illustrations sheet on dark: line drawings of a heart, liver, lungs, stomach, brain and intestines, then teal glass icons of a smartwatch with a heart, an ambulance, a doctor in a cap and mask, a lotus, an info card and a shield with a check, a red warning sign and a white support headset beside a medical cross

One system for the clinic and the patient

Found
Two products for two audiences could easily drift into two looks, and a dark theme doubles every colour decision.
Decided
A standalone design system with a UI kit for the web app and one for the mobile app, built from the same tokens and parts, dark mode first.

The same provider card, before and after booking

One card for the provider in the patient app: on the confirmation screen it ends in Confirm, on the upcoming list in Reschedule.

  • The provider card on the confirmation screen: photo, name, phone, city, distance, the selected time and a Confirm button
    Confirmation: The card with the selected time and a Confirm button
  • The provider card in the upcoming list: photo, name, phone, city, distance, the appointment time, a cancel button and a Reschedule button
    Upcoming: The same card with the appointment time, a cancel button and Reschedule

Every control drawn in every state

The kit lays out each control in its states: disabled, default and pressed; default, focused, filled and error; an available day and a selected one.

  • The UI kit: a Continue button disabled, default and pressed, a Reschedule button default and pressed, and a date field default, focused, filled and with an error message
    Buttons and date fields
  • The UI kit: the calendar default and with a day selected, with a legend for available, unavailable and selected days
    Calendar
  • Five clinical guidelines in the care team’s app, one with a Resolved dropdown and four with Unresolved dropdowns, marked by teal and red edges
    Clinical guidelines

The care team’s app away from the desk

Kept
The patient list itself: the same controls above the table and the same columns in the same order.
Changed
On a tablet the stat cards and the table scroll sideways; on a phone the controls sit in one row above the table and the menu moves behind a button.
The patient list at tablet width: a menu button, the greeting, two stat cards, the view, filter and sort controls and the table with paging
Tablet · Patient list The same list at tablet width, with the header centred
The patient list on a phone: a menu button, the greeting, a stat card, three controls in a row and the first rows of the table
Mobile · Patient list The same list on a phone

What the development partners received

The product was built by ANODA’s development partners from screen maps, prototypes, UI kits and Zeplin specs.

Screen map
The appointment flow, every screen placed and every transition drawn.
Clickable prototypes
Appointment booking, and the patient app with its message states.
UI kits
Component sheets for the web app and the mobile app, in dark mode.
Design system
A standalone system the two kits are built from.
Brand guidelines
The refined logo and how it is used.
Zeplin export
Specs and assets for the developers.

Flows in the handoff

  1. Moodboard
  2. Wireframes: the care-team web app and the patient app
  3. Care-team web app: the redesigned desktop UI
  4. Patient app: the UI between visits
  5. Appointment booking: UI, screen map and clickable prototype
  6. UI kit: components and their states, in dark mode
The upcoming-appointments screen map: an upcoming visit with reschedule and cancel, the empty state, rescheduling through the calendar, a specialist with no free time, and hiding past visits, joined by arrows
Screen map: upcoming visits: reschedule, cancel, hide, and the empty states.
The mobile UI kit sheet Components (inputs, buttons and pickers): buttons, date fields, calendars, pickers, tab switches and status controls, each in its states
UI kit: inputs, buttons and pickers of the patient app.

Where the product ended up

One design for both sides of care: a clinician workspace redesigned around the patient record and AI help that stays a suggestion, a patient app for booking and appointments, and one system in dark mode behind both. Later, a separate audit of Clay’s website followed.

screens and states across both products
342
experts on the team
5

In the client's words

ANODA took the time to understand how we coordinate care for VIP patients and what each person involved needs from the product. Our care team needs to stay aligned on each patient’s care, while patients need a personal, discreet and straightforward experience. They understood how the CRM supports the work behind the scenes and how the mobile experience carries that service through to the patient. That understanding gave us confidence in their recommendations throughout the design process.

Rajiv Prasad Clay

5.0

Will your premium promise survive inside the product?

Clay’s promise is personal attention, and it has to hold for the member and for a care team that can’t afford to retype what it already knows. Here that meant one record both sides read, AI that suggests while a person decides, and one system underneath. Show us your product, and we’ll show you where the promise gets lost.

Discuss your product Explore more case studies

What we brought to Clay

The product

The work