Designing a collaborative experience to track client progress

Research, product design, information architecture, UX writing

Healthify (acquired by WellSky) was a startup that addressed health inequities by connecting people to social services. Case managers can find resources for their clients, create referrals, and check on progress made.

We incrementally updated our referral feature to encourage teams across payer, healthcare, and community organizations to coordinate on client care.

The challenge

Healthify’s referral feature was too vague for social workers to add meaningful updates. How could we better document client progress?

Solving this was split into two phases. Phase 1 was a low-risk MVP to test if clear instructions and small UI optimizations would encourage users to update referrals more often.

Months later, we started Phase 2 with a new company strategy: Healthify would help community organizations get reimbursed for clients sent their way. We needed a new referral tool to track their work.

What I did

In Phase 1, most of my time went into stakeholder interviews, user testing, and secondary research. For the MVP, I did UX writing and light UI design.

In Phase 2, I went through an end-to-end process (research, gathering requirements, design iterations, regular feedback sessions, QA) to get the feature shipped. I supervised a product design intern too.

Impact

Healthify brought on its first network partnership to the platform soon after referrals and admin tools were built. This also unblocked the Network Management team to continue recruiting CBOs across the US.

Since we have data on patient needs in aggregate, so we can now tie user engagement to community health outcomes in reports.

Who’s involved in referrals?

There are two primary groups.

Referral senders are case managers at an insurance plan or provider. They create referrals for their clients and may follow up periodically.

Referral receivers work at CBOs (community-based organizations), and they directly provide social services to clients sent their way. They must report client interactions like contact attempts, enrollment status, and type/quantity of services provided.

How do referrals work?

Social workers distinguish between referrals (“I called the client and set up an appointment”) and services provided (“The client came to the appointment and got the services they need”).

Healthify’s existing referral functionality consists of 1) creating a referral and 2) updating the status with 5 general options. It’s not useful because it conflates the referrals with provided services. Plus, each organization has their own policies for client interactions, so these statuses are too open to interpretation.

Phase 1: Research sprint

The goal is to match referral statuses with users’ real life workflows. Even though processes vary among customers, is there a common ground? I conducted a research sprint to find out if there’s language, tasks, anything that’s industry standard.

What happens when a client is referred?
I referenced previous user research and conducted a few interviews to see what actions case managers would generally take. Then I organized these events with a user journey map.

What happens when a case manager meets with a client?

How should actions be grouped?
I ran a card sorting activity with users to see which actions are similar. If we were to split them into 5 groups, what would those groups be?

One technical limitation was keeping 5 statuses. Adding or removing referral statuses (ie, having 4 or 6 statuses) has a very high implementation cost, because it’d drastically affect Healthify’s data models and customer reporting.

What needs to be fixed now vs. later?

My research uncovered new product limitations, so I worked with product managers to prioritize them.

👌 Included in MVP
Referral statuses should be based on actions a user would take, and some examples should be listed. I ran a writing session with Product, Marketing, and Client Services to decide on new names and definitions.

⏳ Saved for Phase 2
Ongoing services that require multiple appointments and/or a longer timespan need to be differentiated from one-time services.

There are occasions when a referral is on hold, where progress can’t be made, but canceling a referral doesn’t make sense.

✂️ Scoped out
Sometimes a client is rerouted to another service. Marking a referral as complete or canceled doesn’t make sense.

When a client returns, or additional services are provided (beyond the initial referral), there should be a new referral to log this information.

MVP-first approach

The MVP consisted of a simple form where users can update the referral status or add a note. Having concise and clear instructions for users was key:

When users change the status, they’ll see examples of milestones that warrant an edit.
When users write a note, they’ll know who their audience is and what kind of information to include.

There are clear instructions for updating statuses and adding notes.

Users now get more guidance when updating the status.

Preparing for Phase 2

Since Phase 1 exposed product shortcomings that needed more investigation, the Product and Client Services teams joined up for a month-long project interviewing CBOs. We learned that financial constraints were often the #1 concern.

As a solution, Healthify would connect CBOs partners with payers and providers — CBOs would get reimbursed for providing social services as an additional revenue source. In return, CBOs need to track services they’ve provided.

Which details matter and when?

There’s plenty of details within a referral, so I did a card sorting activity to determine how information should be grouped in the UI.

What matters to each group? I compared user and stakeholder interests. For the in-app experiece, I prioritized referral receivers, because they’d use the feature most frequently. In contrast, reports would better serve stakeholders.

What’s the purpose? Is it contextual? Which details are users expected to supply? Is it dynamic or static?

Which information belongs to which section?

Take 1: A referral inbox to encourage collaboration

Inspired by email and messenger apps, I designed an inbox that treats referrals as a collaborative effort. Users could quickly find a specific referral and add updates for everyone else to see.

The layout facilities communication among the care team.

Users log client encounters with this form.

However, when I pitched the idea to internal stakeholders, the idea fell apart.

A 3-column layout was overwhelming. Too much information was shown at once, and it was hard to determine what the most important content was.
Client needs should be more prominent, since it's a high priority detail for any user who’d visit that page.

Take 2: A client-centric UX to track progress

The feature eventually became an ongoing progress report where users can monitor client needs. Users are encouraged to add updates and catch up on the client’s most recent milestones.

After finalizing the direction with stakeholders, I fleshed out the rest of the feature.