Rethinking how complex provider inventory appears in searchRolled-up availability
Project overview
When a roadmap shift opened up capacity on the Search team, I proposed a focused design sprint to explore the team’s broader Improve search inventory initiative while still delivering a near term testable set of experiences.
I helped structure and co-lead the sprint, with my focus centered specifically on how provider inventory should appear in Search, how much complexity patients should manage there, and what role Search should play in the path to booking.
From there, I became the primary designer for Rolled-Up Availability MVP feature, carrying the experience through detailed interaction design, implementation, and experimentation.
Date
2024-2025
Role
Senior Product Designer
Team
Product Manager (x1), Engineering Man (x1 Manager, x4 Developers, User Researcher (x1), , Product Design
Scope
Desktop/mobile web, Inventory in search exploration, search Results Organization, Rolled-Up Availability, implementation and experimentation
Outcome
A follow-up experiment measured a statistically significant +1.3% overall conversion lift and was recommended for launch.
Duplicate results were only the visible symptom
Search was organized around individual provider locations, so the same provider could appear multiple times across locations or visit types. That made results harder to compare and fragmented a provider’s available appointments across the page.
But duplicate cards were only one symptom of a broader problem. The roadmap work also raised questions around multiple locations, virtual care, practices, cross-listed providers, and how increasingly complex inventory should be represented in Search.
A single provider could occupy multiple results, with each card showing only one slice of their available inventory.
Because these issues were interconnected, solving them one at a time risked shifting complexity around rather than reducing it. That made the work a good candidate for a focused design sprint: explore the system together while still narrowing toward tangible improvements for the near-term MVP.
Considering the system as a whole
A four-week sprint with two jobs
I helped structure and co-lead a four-week sprint that included 14+ stakeholders across Product, Design, Research, Engineering, Leadership, and adjacent teams and audiences.
We had to do two things at once: explore the broader Inventory in Search problem while still producing tangible improvements for the near-term MVP. We started by mapping the wider problem space and generating directions, then used research to narrow the strongest questions. As the work became more focused, a smaller team carried those questions into targeted design-and-test cycles.
We brought together pain points from across the organization, then grouped them into a smaller set of questions to explore through design and research
The sprint started with broad cross-functional exploration, then narrowed through successive design-and-test cycles over four weeks.
Clarifying with research
I partnered with UXR throughout testing, moderating sessions and helping synthesize what we were learning as the prototypes evolved. Across the research, a few themes kept resurfacing: proximity and insurance were fundamental to comparison, In-person vs. Video needed to be immediately clear, and patients wanted access to a provider’s full availability rather than a partial slice.
At the same time, exposing more information and controls directly in Search could make an already dense page harder to compare. That tension became the focus of my next exploration: what needed to stay visible in Search, and what could move deeper into the booking journey?
Research across the sprint helped distinguish the information patients needed for comparison from complexity that could be handled deeper in the journey.
Something we could build and test
The sprint produced several smaller ideas we could test incrementally, but we also needed a more substantial near-term opportunity we could turn into an MVP and validate through experimentation.
Rolled-Up Availability emerged as the clearest near-term direction. Other areas, from cross-listing and practice representation to more exploratory future-state concepts, still needed deeper investigation before they were ready to become product work.
We tested the experience as one connected system: information gathered upstream changed what patients encountered in Search. My work focused on translating those signals into a results experience that felt more relevant without becoming harder to understand.
Three problems to solve in results
As the sprint moved from the broader Search system into the results experience, I explored three concrete inventory problems through design: making cross-listed providers understandable, consolidating fragmented availability, and defining how practices and facilities might appear alongside individual providers.
Cross-listed providers
I explored ways to make cross-listed providers easier to understand by explaining why they appeared in a patient’s results, especially when the connection to their search was not immediately obvious.
Rolled-up availability
I explored how to combine multiple locations and Video availability into a single provider result without hiding the options patients needed to compare and book.
Practice and facility results
I explored how practices and facilities could appear alongside individual providers as distinct result types, and what information patients would need to understand what they were looking at.
Connecting inputs to results
The inventory problem started before patients reached the results page. What Zocdoc knew about a patient’s needs shaped which inventory could be most useful to them, so the sprint explored both sides of the system: collecting better signals upstream and deciding how Search should respond to them.
Another designer went deeper on the upstream experience, while my work focused on making Search responsive to those inputs: deciding what inventory to surface, how results and filters should adapt, and how to make that added relevance clear without increasing complexity.
Defining the role of search
From control to comparison
As the sprint narrowed toward Rolled-Up Availability, the MVP direction was clear, but the interaction model wasn’t. My results work focused on one question: how much of a provider’s location, visit-type, and availability complexity should patients manage in Search, and what should wait until they went deeper?
Where should this complexity be managed?
While the full booking complexity of the availability modal remained the place for full appointment selection in every concept, I was curious as to how much of that complexity should be handled before patients got there.
Result-level editing: Patients could switch location and visit type directly within each provider result, giving them the most control in Search.
Search and availability already formed a two-step flow: patients compared providers in results, then opened the existing availability modal for more detailed appointment choices.
Page-level editing: In-person and Video controls moved out of individual provider cards and into the broader Search page, reducing card-level complexity while keeping that choice available before patients opened availability.
The three approaches tested how much appointment management belonged directly in Search versus deeper in the booking path. Testing showed that more control was not necessarily better control: richer interactions could be understood, but they added density and asked patients to make detailed appointment decisions while they were still comparing providers.
That raised a broader question for the next round: should Search function primarily as a control surface, or as a comparison layer?
No editing: Search surfaced enough information to signal the provider’s options, while location and visit-type selection happened after opening availability.
How much control actually belongs in search?
The first round helped narrow where detailed editing belonged. Next, I stepped back from individual controls and explored two broader roles for Search: a richer control surface or a lighter comparison layer.
Direction 1: Full autonomy
This version pushed more decision-making into the result itself. Patients could see and manipulate location, visit type, insurance, and availability without going deeper. It made the provider’s options explicit, but also made each card busier and harder to compare at a glance.
If Search is for comparison, how much inventory should it reveal?
The lighter model was promising, but our research exposed an important limit to simplification: In-person vs. Video still needed to be clear, patients wanted access to full availability, and additional locations couldn’t simply disappear.
So I narrowed the question again: if Search was primarily for comparison, how much of a provider’s underlying inventory still needed to be visible there?
Direction 2: ‘A bird’s eye view’
Here, I pulled back. Search focused on the few signals patients needed to judge whether a provider was worth exploring, with more detailed appointment choices deferred to availability. The open question became whether that cleaner view was hiding information that could still matter to the decision.
More of the provider’s inventory was summarized, making the result easier to scan but increasing the risk that useful options would be overlooked.
Additional locations, visit types, and availability stayed more explicit, giving patients a fuller picture at the cost of greater density.
This round let us pressure-test more specific questions: how visible did additional locations need to be, how much availability detail mattered during comparison, and where did added control begin to work against clarity?
The direction that emerged was not to hide complexity, but to stage it: keep the inventory signals that mattered for comparison visible in Search, then expose the fuller set of choices once a patient opened availability.
Direction 1: High-level
I reduced the amount of location, visit-type, and availability detail shown upfront, prioritizing a cleaner scan of providers. The tradeoff was that useful inventory could become too abstract or easy to miss.
Direction 2: High-control
I brought more of the provider’s options into the result, making additional locations, visit types, availability, and other relevant signals easier to discover. It gave patients a fuller picture, but pushed the card back toward the density we were trying to avoid.
What the sprint clarified
By the end of the sprint, the research and design exploration had helped separate what we could act on now from what still needed deeper investigation.
We synthesized the work into a final prototype and leadership readout, connecting the near-term inventory opportunity to the broader Search questions we had uncovered.
The final readout brought the research, design directions, and unresolved questions together into a shared view of what we could pursue now and where Inventory in Search could go next.
Rolling up into a real system
The sprint had clarified much of the interaction model. Rolled-Up Availability was where I had to turn that direction into a complete, production-ready MVP, defining the exact behavior, hierarchy, states, and edge cases needed to make it work in the existing system.
The underlying system was still provider-location based
Behind the experience, availability still belonged to separate provider-location records, with Video modeled as another location. Rolling inventory up changed what patients saw, not the underlying architecture. Every appointment still had to resolve to a specific location and visit type.
The system still contained multiple provider-location records. The patient-facing experience presented them as one provider.
Organizing more inventory without making the card heavier
Bringing multiple locations, visit types, and availability into one result created a new hierarchy problem. I worked through what needed persistent space on the card, what could be summarized, and what should only appear once a patient went deeper.
That meant refining the relationship between provider identity, insurance, location, visit type, and availability while keeping the result easy to scan alongside other providers. Card hierarchy and information organization were part of my core RUA ownership.
Carrying the model into availability
The availability experience became the second half of the model. Search could summarize a provider’s options without exposing every appointment state at once, while the existing modal gave patients access to the fuller set of choices when they were ready to select a time.
I reused the existing availability modal rather than redesigning it from scratch, defining how the rolled-up result connected into it and how location, visit type, and availability context stayed coherent across the flow. The modal itself predated RUA.
Making the model hold up across real inventory
The ideal card was only one state. The system also had to work for providers with different combinations of locations, modalities, availability, content lengths, and screen sizes.
I worked through details including location logic, modality states, availability behavior, long names, overflow, responsive layouts, and card edge cases, while preserving the same underlying hierarchy
Carrying it through implementation
I maintained the RUA design source of truth and worked with Engineering as implementation surfaced additional constraints and edge cases. I refined states and compromises as they emerged and carried the experience through web and native design QA, including adaptation for Android.
The same interaction model had to survive very different combinations of provider inventory without becoming a collection of one-off solutions.
The final structure brought multiple locations, visit types, and availability into one provider result without giving every piece of inventory equal visual weight.
Search supported comparison; availability handled the fuller set of location, visit-type, and appointment choices.
I refined the hierarchy so the information patients needed for comparison stayed prominent while secondary inventory could progressively disclose.
The same interaction model had to survive very different combinations of provider inventory without becoming a collection of one-off solutions.
What happened
The first A/B test was mixed: topline conversion was flat, while downstream appointment quality improved and a Sponsored regression emerged. A revised treatment later showed a statistically significant +1.3% lift in overall conversion, resolved the Sponsored conversion regression, and was recommended for launch.
I was on sabbatical while the follow-up treatment was prepared, so I view that result as an outcome of the broader RUA direction rather than an iteration I personally drove.
What this changed
Rolled-Up Availability was the part of the broader sprint vision we were able to carry into a real product experience. Other directions, including cross-listing, practice and facility concepts, and more future-state Search ideas, remained exploratory as priorities shifted.
The work moved from a broad question about how inventory should work across Search to a concrete model for how complex provider inventory could be made easier to compare without hiding the choices patients needed to book.