the foundation
the users
user audit
Pacify's users are far from uniform. Most access the app through an employer or health plan, and contracts let each client customize the experience for their members, some add call buttons to service or nurse lines, for example. Across consumers, health plans, and public health programs, the app can look dramatically different client to client.
research
With a limited research budget, we relied on a mix of primary and secondary research, including a 2022 utilization survey from one partner that offered invaluable insight into user motivations, hesitations, fears, and opportunities for improvement.
We used these insights to build user stories for app users, prioritizing features, planning future launches, and anticipating roadblocks, a key step in shaping the product roadmap. We repeated the process for internal team members like admins, care coordinators, and Pacify providers, to get a full picture of what exists today and what's planned.
To round out the picture, we also ran empathy mapping to pin down a focused list of user interests and emotional triggers.
%20-%20Members.avif)
takeaways
This research made one thing clear: most users are navigating a vulnerable time in their lives, and their hesitations and fears can be a real barrier to getting help. As of 2023, the app offered exactly one way to get care, an on-demand video call, and users needed more options, more reassurance, and more information than that single path could offer.
the obstacles
core needs
Weighing business objectives, user needs, and client requests together surfaced three core needs for the new platform:
1. improve access to care
- Achieve parity with existing app & on-demand functionality
- Add features that allow users to choose how they receive care
- Audio calls
- Chat
- Scheduling
- In-person
2. implement new care model
- Design care plans that inlude multiple points of interaction over time
- Allow users to reconnect with same providers
- Implement EHR
- Build care pathways dependent on client coverage
- Provide direct-to-consumer avenues for self-paying individuals
3. replace previous tech stack
- Enhance hard-coded Pacify admin panel, streamline data storage, and replace patient app with a progressive web app to ensure sustainability
- Knit user-facing platform functionality with backend data analytics & tracking
- Fulfill and maintain all existing security and data standards
- Integrate health plan eligibility verification
journey mapping
Documenting needs across admins, patients, providers, and care coordinators made clear we needed an EHR, both to securely store patient information and support a more longitudinal model of care. With limited dev resources, it had to come with chat and scheduling built in, and Pacify's unusual on-demand model made a good fit hard to find without heavy customization.
After a round of sales calls, I wireframed the user journey for each top contender, outlining functionality, UX, extras, and trade-offs, then cross-referenced that against our user stories to narrow the field and bring a recommendation to product leadership.
selecting an EHR
Documenting needs across admins, patients, providers, and care coordinators made it clear we needed an EHR, both to securely store patient information and to support a more longitudinal model of care. With limited development resources, it had to come with chat and scheduling built in. Pacify's on-demand model is fairly unusual, which made it hard to find an EHR that fit without heavy customization.
After a round of sales calls, I wireframed the user journey for each top contender and outlined its functionality, UX, extras, and trade-offs. Cross-referencing that against our user stories let me narrow the field and bring a recommendation to product leadership.
the process
building the EHR environment
Product leadership moved forward with Healthie. None of the contenders fit our model of care perfectly, but Healthie's built-in chat, scheduling, and charting mattered given our limited dev resources and tight budget. I worked closely with the Clinical team to compile the charts and program implementations required.
maintaining data integrity
Another obstacle was maintaining data integrity during the transition. Adding an EHR and new integrations meant app data and functionality would now be spread across multiple platforms. The existing admin panel determined a user's available features based on their enrollment code, falling back to their associated organization if no code-based permissions were set, and more functionality only added complexity. So the team and I wireframed the enrollment pathway and how each platform needed to transmit data to trigger the right functionality for the user.
These exercises clarified not just how users would interact with the product, but how the platforms needed to interact with each other, and gave us a way to articulate that complexity to the dev team. Throughout the replatforming, we worked closely with them to document requirements, run technical assessments, and propose workflows.
brand application
With functionality settled, it was time to bring Pacify's brand into the new UI. Stakeholders wanted the rebuild to evolve the brand in a fresh direction, so I put together a set of brand application swatches for review. They responded immediately, unanimously aligning on one within a 30-minute meeting.
the product
prototype & iteration
Applying the Pacify brand to this project was a ton of fun. It opened up a ton of creative avenues for playing with color, typography, and layout.
The first iterations weren't perfect and there was a lot of trial and error balancing brand application and information architecture. I made some changes along the way to prioritze a clean interface, like swapping color-coded tags for uniform ones. Most users access the Library on their mobile device, so I scaled elements up to be more interactive and accessible on a smaller screen. I also moved and added elements for clarification purposes.
the features
Onboarding
Once the redesigned app launched, enrollment data revealed a problem: users were dropping off well before they finished signing up. Three barriers stood out as the main culprits.
Addressing these three barriers reshaped how onboarding collects information. Enrollment completion reached 80%, and eligibility failures dropped by 17% after launch.
the obstacles
Users were dropping off almost entirely at one screen: confirming eligibility. The original flow asked people to already know how they qualified, either entering a Pacify code or picking their plan from a list of more than 200 health plans, employers, and public programs. Most people didn't get past it.
1. entering basic information
- Approximately 6% of users dropped off on the "basic info" screen, which required manually typing personal details.
- Screens that didn't require typing saw little to no drop-off, users wanted a fast process and were hesitant to hand over personal info like date of birth and home address.
2. insurance eligibility
- 74.9% of users dropped off at the insurance eligibility screen.
- Eligibility errors came in daily, requiring manual follow-up from the team, and most of these users were actually eligible for Pacify.
3. purchasing a package
- Onboarding was built to support direct pay for users purchasing a lactation or doula package out of pocket.
- From launch in January 2025 through June 2025, Pacify had a 0% conversion rate on D2C package purchases, though a code-level bug was the primary driver rather than the screen itself.
the Process
The original entry screen asked users to sort themselves into one of three paths before they had enough information to choose correctly: enter a code, check coverage, or "I'd like to pay," language weak enough that even genuine payers hesitated on it. I replaced that upfront menu with one question everyone can answer, their state, which does the routing a confusing menu used to leave to the user.
Choosing the U.S. state narrows an unfiltered list of 200+ plans down to what's actually available to them, and it surfaces the self-pay option later, better labeled, only once the filtered list has confirmed someone isn't a match for covered care.
I also moved the sensitive parts, like their insurance member ID, to later in the flow, after they'd already seen their own plan or employer named back to them. Seeing that match confirmed they were in the right place and made handing over more personal information feel safer.
the outcome
Enrollment completion reached 80%, and eligibility failures dropped by 17% after launch.
Dashboard
Once chat and scheduling launched, important business metrics began to shift. The dashboard needed a redesign to re-align with business needs.
the obstacles
Adding chat and scheduling had an unintended side effect: on-demand calls to lactation consultants dropped, while doulas began fielding requests to be reachable over chat around the clock, a level of availability insurance wouldn't cover. The dashboard needed a redesign that put on-demand lactation support back in front of users and nudged them toward scheduling with their doula instead of defaulting to chat.
That business need was the catalyst, but the dashboard had real usability problems of its own. Addressing those became just as much a priority as the business goal behind the redesign.
1. buried actions
- Primary CTAs were nested inside bottom sheets, adding extra taps to reach core actions
- Poor accessibility
2. vague CTAs
- Inconsistent visual and interactive patterns
- Contrast & color were being under-utilized
3. cognitive overload
- Long, bloated layout increased cognitive load
- Pushed user's needs further down on the dashboard
the Process
Changing a selection of color tokens and components on the dashboard opened up the possibility for a more user-centric dashboard that simultaneously fulfilled business requirements.
On-demand care received its own space on the dashboard to separate it from scheduling and clarify the types of care available. The section features prominent actions specific to on-demand care. Lactation CTA cards also got a major makeover with real-time availability, ratings, and a wider range of content to entice users.
Doula cards became a distinct color so they weren't competing for the same attention.
I removed the chat option to encourage users to schedule with a provider instead and added soonest availability to the scheduling cards to reduce decision fatigue.
To fix buried actions, primary CTAs got their own compact card format instead of living in bottom sheets. For unclear CTAs, purpose-based language and color replaced generic labels, so each card said what tapping it would actually do. And to cut cognitive overload, care access collapsed from a multi-tap contact list into a single scannable carousel. The new cards also had to hold up across every existing eligibility state, doula only, lactation only, or both, and across every appointment stage, not just the one scenario shown in a typical before/after.
the outcome
Since the new dashboard launched, the following outcomes have been observed:
conclusion
challenges
- Balancing a business-driven priority shift toward on-demand care with real usability problems that had nothing to do with that business goal
- Establishing the difference between "design problems" and problems with internal operational workflows (a tricky but very necessary conversation)
- Fixing a flow that requires users providing information that they may or may not actually know
lessons learned
- The strongest fix for a business metric is often a real usability fix, not a more aggressive nudge
- Ask users questions they can already answer, rather than assuming prior knowledge
- Sometimes a single, big redesign doesn't solve all the problems! :)