Healthcare · Internal admin
Healthcare admins relied on developers to build every provider search field. This is how that dependency was removed through a flexible, self-serve form builder.
Team
Product Designer, FE & BE developer & PM
Timeline
4 weeks
Domain
Healthcare
Platform
Web
What is DYP?
DyP® (Discover your Provider) is an AI-powered, CMS-compliant Medicaid provider management platform built for US state agencies, MCOs and commercial healthcare payers. It transforms provider enrollment, historically a months-long, paper-heavy process into a streamlined digital experience, handling everything from credentialing and verification to onboarding automation.
Who I designed for
Primary User
Healthcare Admin
Non-technical administrators at US state Medicaid agencies
Responsible for configuring and managing the provider enrollment application
Need to make form changes quickly without depending on engineering
Secondary User
Healthcare Providers
Hospitals, clinics, home health agencies and individual physicians
Filling out the enrollment application to get credentialed into Medicaid
Need a clear, guided experience across a complex multi-section form
What were the pain points
Admins waited on a dev ticket for even the smallest form change
Healthcare admins had no way to configure them independently
The people who knew the enrollment requirements best had no way to act on them
As Medicaid rules shifted, the backlog only grew
What was the problem
In DyP's provider enrollment system, every search field had to be hand-coded by a developer. Healthcare admins — who understood the enrollment requirements best — had no way to add or change searches themselves, leaving even small updates dependent on engineering availability. The challenge was to put that control in their hands: letting non-technical admins configure complex, multi-source searches on their own, without writing code or raising a dev ticket.
What was the research
Primary Research : Interviews with Admins & Stakeholders
I interviewed 4–6 participants which were a mix of healthcare admins who configure the enrollment forms and internal stakeholders (PM, engineering, and business/domain experts) to understand the problem from both the user and system side.
What I set out to learn:
How admins worked today, and where their workflow broke down
Which form changes they needed most often, and why they depended on developers for them
Whether early design directions matched how they thought about the problem
Secondary Research : Competitive Analysis
I looked at how leading form builders expose complex logic to non-technical users.
Google Forms — keeps conditional logic deliberately simple, suited to internal, low-stakes forms. No multi-source data linking.
Typeform — its Logic Jumps offer a visual flow-chart view that makes complex branching approachable, but the engine still relies on fixed rules tied to the literal value of a field.
Webflow / Framer forms — strong on visual design, shallow on logic; not built for data-driven, multi-source relationships.
What went wrong at the first place?
The initial level of iterations was around a single search which was global. But, later on I figured out that even for the smallest search, the search will happen at the global level which is cost burning for the business for my team also to fetch data through the whole database which is not necessarily required at the first place.
Hence, with further discussions with the stakeholders, we came out with the fix that might solve the two major problems and let admins give the choice of deciding the kind of search it can be.
Fix: Own Form vs Global Search
Defining where the search looks
The two search types differ by scope where the search actually pulls data from.
Own Form searches within the enrollment form itself. A toggle extends that reach: off, it stays within the current form; on, it also pulls from the provider's previously filled enrollment forms, if they've submitted any before.
Global searches the widest scope across all data available in the database, not tied to any single form or provider.
This gave admins precise control over how far a search reaches, from a single form to a provider's enrollment history to the entire dataset without configuring separate search tools for each level.
Field Mapping & Display Conditions
Because Global fields are typed in rather than chosen from a known list, the system has no way to recognise them on its own. Each named field has to be explicitly mapped before the search can use it — and Screen 3 is where admins do that, connecting every field through the relation controls in Display Conditions. Naming a field tells the system what you want; mapping it tells the system where to find it.
Combination Logic
Combination lets admins decide whether search fields return on their own or as a bundle. Off by default keeps the simple case simple ; admins who just need a basic search never face bundling logic at all. Turning it on anchors the result on one field, like License, so every related field returns together automatically. The key decision: the Result Configuration interface stays identical either way same layout, same controls, only the logic underneath changes. Complexity appears only when it's asked for, and never as a separate mode to learn
60% faster work process
Non-technical admins could navigate the full configuration flow independently confirmed through walkthroughs
0 dev tickets
Dev dependency for form search configuration