Modular policy tool for faster eligibility matching
Upland Advocacy
Speed and clarity for policy input, when every second counts on a call
Patient advocates often scrambled to find eligibility rules during support calls. I designed a modular input system that breaks down complex policy logic into clear step-by-step actions for faster processing with fewer errors.
*Partial UI shown due to NDA. These illustrate structural decisions behind faster rule entry and easier validation.
The Team
Me (Lead Product Designer)
Ibadat Shaney (Product Owner)
Suhail Amhed (Lead Business Analyst)
Aswhin Kumaar (Business Analyst)
Sana Ru (Lead Frontend Developer)
Shardha Sapra (Senior Frontend Developer)
Timeline
2023 Feb - June (4 months)
Challenges
Eligibility rules were hard to find, verify, and trust—all during live calls
Fragmented Workflow
Advocates jumped between tabs and spreadsheets mid-call, slowing them down when patients needed a faster answer
Mismatched Rules
Inconsistent rule formats and vague criteria often lead to wrong matches and missed financial aid
No Single Source of Truth
Policy details were scattered across files, versions, and notes, making it hard to verify anything
Goals
I aimed to turn scattered, inconsistent policy data into a modular system, so advocates could search, edit, and apply rules mid-call and scale the setup as policies evolved
01
Make Policies Searchable
Structure policy data into searchable fields to speed up rule matching
02
Define Eligibility Clearly
Break vague criteria into reviewable logic to reduce uncertainty
03
Prevent Errors at Scale
User validation to catch mistakes and onboard new rules faster
Understanding the Context
To streamline matching, I needed to understand the real-life constraints advocates faced on calls.
Designing in lockstep with real-world call chaos
To design for messy, mid-call workflows, I held daily syncs with two client leads and checked in regularly with their internal support team. This tight feedback loop surfaced fuzzy edge cases, shifting policy rules, and pain points we hadn't anticipate, all while operating fully remotely.
Daily Syncs, Remote First
Kept alignment despite shifting priorities and no in-person context
Live Feedback from Clients
Helped flag gaps and break unclear assumptions in real time
Support Team Insights
Uncovered messy edge cases and call-specific blockers
Critical care moments are slowed down by undefined rules and scattered systems
I interviewed 10 active users to uncover where policy lookup and decision-making broke down. Their stories revealed recurring breakdowns in clarity, speed, and reliability.
Confusing or Missing Rules
"Requirements keep changing. Sometimes I'm not even sure what counts anymore."
Application windows and eligibility criteria varied widely—some provided 30 days, others 90. Many policies didn't define any rule at all, forcing advocates to guess or cross-check with others.
Lost in Tabs
"I'm busy flipping tabs instead of helping."
Mid-call, advocates scrambled between multiple Excel files to verify coverage details. This slowed responses, introduced stress, and increased the risk of errors.
Frequent Mismatches & Delays
"I once gave someone the wrong info. Now I double-check every single time."
Unclear formats and fuzzy logic often caused missed matches. One advocates misreading an income rule that said "usually qualifies under 60% FPL", which the system couldn't apply.
System-level Solutions to Reduce Advocate Friction
I transformed recurring user pain points, such as disjointed inputs, loosely defined rules, and policy mismatches, into a modular system designed for speed and accuracy during live support calls.
Solutions focus
Guided Rule Builder
Combined eligibility rules into one structured form to prevent jumping between tabs or interpreting vague logic manually
Smart Policy Filter
Let advocates instantly filter applicable policies using defined criteria, instead of combing through fragmented spreadsheets
Live Validation Alerts
Flagged incomplete or non-standard rule entries, like open-ended dates or loosely written income thresholds, as the user typed
Designing for frictionless matching
I mapped out key flows and experimented with form structure and logic to turn ideas into actionable solutions.
Guided rule builder
To address frequent mismatches and confusion, I replaced the fragmented rule entry with a structured form that groups logics by type—like income, residency, and insurance. Using checkboxes, logic prompts, and drop-downs, the tool encourages clarity i how each rule is applied, not just where it's written. This format enables advocates to move faster and avoid interpretation errors that can be buried in spreadsheets.
One advocate misread a policy that said "usually qualifies if under 60% FPL"—a rule too ambiguous for the system to process. I addressed this by requiring clear cutoff values and validation inputs as they're entered.
Early Concept
Final Design
*Want to see the full eligibility form? Expand full view
Eligibility logic variation (step-based breakdown + real-world framing)
To support real-world policy registration, I designed a flexible input form for administrators to add policies with varying eligibility conditions. Instead of creating rules in a vacuum, I grounded each step in real eligibility data from hospital requirements to state program formats.
The final structure balances complexity and clarity. Each step shown below mirrors a real-world rule pattern from single cutoffs to multi-factor combinations.
Early Concept
Final Design
Eligibility Logic Variation 1- Qualifying Buckets
Step 1 - Set a basic eligibility threshold
Use case: Programs that offer general aid under a fixed income cap (e.g. FPL ≤ 200%)
Start with a basic income condition like "FPL ≤ 200%." This step ensures even simple aid programs can be configured in seconds.
Step 2 - Create additional income brackets
Use case: You want to set up different coverage tiers based on income bands (e.g. FPL ≤ 200% gets 100% discount, FPL ≤ 300% gets 75%).
Add additional income bands to map different discount levels. (e.g. FPL ≤ 200% → 100%, FPL ≤ 300% → 75%.)
Step 3 - Combine different condition types
Use case: Programs that require multiple eligibility factors beyond income (e.g. FPL > 200% AND Age ≥ 65)
Mix income with other qualifiers like age or residency using AND / OR logic—flexible yet structured.
Key benefit: Adds flexibility when income alone isn't enough to determine eligibility
Step 4 - Finalize complex qualifier group
Use case: Programs with particular eligibility needs (e.g. Income > 200% AND Age ≥ 65 in same group AND Residency = NY)
This step lets advocates group multiple conditions into a single, structured logic block, ideal for layered rules based on income, age, and region.
Key benefit: Reduces duplication and supports high-impact programs with narrow eligibility criteria
Following this, I also structured how layered discounts can be defined using the same logic framework ↓
Eligibility Logic Variation 2 - Discount Rules
Layered logic with contextual automation
Why this discount setup works
This logic auto-applies discounts and scales with complexity without adding extra steps
This setup lets advocates define both general and scoped discount rules with optional clarity.
Discounts are applied automatically based on input fields (e.g. service type, visit date), reducing manual work and minimizing errors, even in complex edge cases. When needed, advocates can layer additional rules without adding clutter, making the system flexible enough for even the most complex programs.
Preventing errors with real-time validation
Early mistakes, like mismatched brackets or unlinked systems, often went unnoticed. I tackled this by embedding validation directly into the workflow, guiding advocates to resolve issues as they build, rather than after they submit.
Income Range validation - Eligibility Requirements
Inline prompt catches income range gaps before submission, helping users define clean brackets.
If a 100% discount looks off, the UI suggests checking it to avoid mistakes.
System Linkage Check - Add Policy Form
If no linked health system is detected, users are prompted to create one directly, avoiding downstream policy errors.
Outcome
Structured validation cut errors by 18% and sped up patient matching
Real-time validations and rule structuring helped reduce policy errors and speed up patient matching
18%
Fewer policy errors
25%
Faster match setup
52%
Fewer downstream fixes
1.4x
More policies supported
Takeaway
What this project taught me about designing for complex systems:
Guidance Beats Flexibility
People moved faster when I offered just enough structure, not too much, not too little
Scale Starts with Patterns
Reusable logic wasn't just for dev. It helped me design with consistency and adaptability.
Outliers Expose Gaps
Outliers weren't noise. They showed me where my system logic needed to stretch