Designing a Contact System Healthcare Teams Can Navigate
Reducing search friction and communication errors across departments
My Role
Product Design Intern
Timeline
June - July 2025 (2-week design sprint)
Tools
Figma, Bolt.New
01
The Problem
During high-stakes healthcare inspections, employees struggled to find the right contacts. Information was scattered across client pages, difficult to find, and defined differently across teams.
How might we help employees find the right contact quickly without adding complexity to an already busy workflow?
Example Client Account Page: All contacts except the primary contact were hidden in view linked applicants under each tab.
02
Uncovering Key Pain Points
I analyzed prior stakeholder interviews across account management, billing, marketing, inspections, and business development that revealed 4 key pain points:
1. Scattered Information
Contacts were buried across programs and required navigating multiple sections.
No Search or Filtering
Employees needed to already know where a contact lived in the system.
Too many steps to communicate
No clear path from "find contact" to "reach contact."
The Deeper Issue: No shared definition of a contact
The existing system assumed one main contact per account, but teams often worked with several people and roles and thought about contacts differently:
"A contact is a role— whoever holds the seat at a hospital facility."
— Billing Team
"A contact is a person— someone we've built a relationship with over the years."
— Account Management Team
This shifted the challenge from designing a better contact list to designing a contact model that could work across teams.
03
Important Design Decisions
One Shared Location for Contacts
Centralizing Contacts Within Each Account
Previously, contacts were spread across different tabs. I centralized them into one shared Contacts space on each account page, making them easier to find and manage.
Preserving the “Primary Contact” Workflow
Teams defined and used contacts differently, but some relied heavily on the existing Primary Contact designation. Rather than removing a familiar workflow, I incorporated it into the new system.
When creating or editing a contact, users can designate them as the account’s Primary Contact and assign multiple contact types.
This preserves existing workflows while giving teams the flexibility to organize contacts around their own use cases.
Filter Pattern: Stacked Layout vs. Visible Pills
Filter Exploration #1
I originally designed dropdown filters, but in testing, users found them hidden and clunky to navigate.
Filter Exploration #2
I iterated toward an Airbnb-style filter pill pattern with removable chips. This increased visual complexity slightly but Improved discoverability and clarity.
The Final Result: users found a target contact in an average of 4 seconds using filters alone.
Prioritizing Scanning Over Density
I explored both card and list views. Because the primary use case was quickly identifying a contact, I prioritized cards for easier scanning.
Engineering could only implement one view during the sprint, so the card view became the MVP.
04
Testing & Iteration With Real Users
I tested the design with the Account Management team using interactive prototypes:
User Testing Metrics:
~4 seconds — average time to find a contact using filters
~45 seconds — average time to create a new contact
Minimal friction observed across core flows
Performing live user testing with the Account Management team
Testing also led me to:
Move bulk email into a persistent toolbar
Clarify “All Programs” with inline helper text
05
Final Solution
A Centralized, Role-Aware Contact System with:
Global search and filtering
Card-based contact browsing
Multi-select and bulk email
Quick-view contact details
Scalable contact logic
“All Programs” contacts apply across programs
Person-based updates propagate across accounts
Role-based contacts remain scoped
Before
Contacts were scattered across individual sections of each client account, requiring employees to manually search multiple locations.
Impact & Outcomes
30+
contacts centralized per account
4 MVPs
scoped for engineering
Replaced multi-step navigation with a single searchable system
06
Reflection
This project reinforced that the hardest design problems aren't always visual. Before designing the interface, I needed to understand what a “contact” actually meant across teams.
With more time, I would test with all five user groups and measure the feature after launch to see how the contact model and filters perform at scale.
