Designing Trust in Automation
The Challenge
Dental billers spend hours each day preparing insurance claims for submission. Before a claim can be sent, they often need to attach x-rays, include clinical notes, write narratives, and ensure carrier-specific requirements are met.
Many claims are routine and repetitive, making them strong candidates for automation. Our team set out to build Autopilot, a feature that could automatically review and submit low-risk claims.
The business goal was straightforward: reduce manual work and improve throughput.
The UX challenge was not.
The Problem
Through prior research and existing workflow mapping, we already understood the end-to-end claim submission process and how long it could take to complete manually. We also knew we were designing for power users—experienced dental billers who deeply understand insurance carrier behavior.
These users weren’t resisting automation itself. They were resisting loss of control.
They knew:
- Which carriers are strict about specific procedure codes
- Which providers require extra review
- Which combinations of carrier + code often lead to downgrades or rejections
- When claims should never be automated
This meant the system couldn’t simply be “on or off.” It needed to respect nuanced, real-world expertise.
The core challenge became: How do we automate claims while preserving highly granular user control over when automation should and shouldn’t apply?
Designing the System (Iteration & Discovery)
We initially approached the problem with a straightforward model:
- Allow users to configure Autopilot rules by carrier
- Add support for procedure code exclusions
This made sense at first and aligned with existing mental models. However, as we mapped real-world scenarios with stakeholders, we discovered an additional layer of complexity:
👉 Users also needed to control behavior at the provider level
This introduced a much more complex relationship:
- A procedure code might be fine for Carrier A generally
- But not for Carrier A when performed by Provider X
- But acceptable again for Provider X when billed to Carrier B
This turned what initially felt like a simple rules system into a multi-dimensional decision matrix.
At this stage, I created several low-fidelity explorations to test different models:
- Separate configuration areas per entity (carrier / provider / code)
- A combined rule builder with layered conditions
- A segmented settings structure with nested logic
One concern I had during this phase was that the system could quickly become overwhelming as more rules were added. The risk wasn’t functionality—it was scalability and cognitive load.
The challenge shifted from “how do we let users configure everything” to:
How do we prevent configuration complexity from overwhelming the user over time?
The Breakthrough: Reframing the Problem
Through iteration and discussion with stakeholders, we reframed the system entirely.
Instead of asking users to define how Autopilot should behave everywhere, we changed the model:
Autopilot is enabled by default for recommended claims. Users only manage exceptions. This single shift simplified the entire experience.
It transformed the product from:
- A rules engine
into - An exception management system
This meant users no longer had to configure every possible condition—only the specific scenarios where automation should not apply.
The Solution
I designed a lightweight exception-based system that allowed users to exclude specific combinations of:
- Carriers
- Procedure codes
- Providers
from Autopilot automation.
1. Human-readable rules
Instead of exposing logic or technical condition builders, every rule was translated into plain language.
Users didn’t see configuration syntax—they saw clear statements like:
“Do not automate claims for Provider X when billed to Carrier Y for Code Z.”
This made the system immediately understandable, even at scale.
2. Scalable exceptions table
One of the biggest design challenges was ensuring the system remained usable as rules accumulated.
I designed a:
- searchable
- filterable
- structured exceptions table
This allowed users to quickly scan, locate, and manage rules without needing to mentally reconstruct system logic.
The key focus was readability—even when hundreds of rules existed.
3. Safe rule creation
To prevent configuration errors, rule creation was intentionally lightweight.
Users could:
- Select provider, carrier, and/or procedure code
- Preview the rule in real-time as plain language
- Confirm before saving
This live preview acted as a safety layer, reinforcing trust and reducing mistakes.
Outcome
The final experience successfully balanced automation with expert control.
By default, users benefited from automated claim submission for low-risk scenarios, while still maintaining precise control over exceptions based on their expertise.
The system:
- Scaled across carriers, providers, and procedure codes
- Avoided overwhelming users with configuration complexity
- Maintained clarity even as rule sets grew
- Respected deep domain expertise without requiring technical understanding
Most importantly, it transformed a potentially complex rules engine into something that felt predictable, transparent, and easy to manage.
Reflection
This project reinforced a key principle in designing enterprise automation tools:
Users don’t need control over everything. They need confidence that they can intervene in the right places.
The biggest breakthrough wasn’t the rule system itself—it was reframing the problem from configuration management to exception management.
That shift allowed us to preserve power-user flexibility while ensuring the experience stayed understandable, scalable, and trustworthy over time.
Reflection
This project reinforced a key principle in designing enterprise automation tools:
Users don’t need control over everything. They need confidence that they can intervene in the right places.
The biggest breakthrough wasn’t the rule system itself—it was reframing the problem from configuration management to exception management.
That shift allowed us to preserve power-user flexibility while ensuring the experience stayed understandable, scalable, and trustworthy over time.