Jopari — Smarter Claims & Payment Flows

The Problem

Providers were navigating by memory, not by design

The Remittance Gateway platform handled high-stakes operational work — EFT enrollments, ERA processing, bill corrections, payment reconciliation. The users responsible for this work were experienced, efficient, and operating at volume. The software was not keeping up with them.

Workflows were fragmented across disconnected screens. Status labels were inconsistent. Tables were dense without hierarchy. Users had no clear indication of what needed attention, what had changed, or what to do next. In a high-volume environment where a missed payment or misconfigured enrollment has real financial consequences, this ambiguity created real risk.

No clear signal for what requires attention — users scanned everything manually

Enrollment flows that didn't reflect the dynamic system logic behind them

Status labels so similar across contexts users couldn't distinguish payment state from enrollment state

Tracing a payment error required navigating across multiple disconnected views

Tribal knowledge was the de facto documentation — new users struggled significantly

No contextual guidance at decision points — users had to know the right answer before the UI would help

Research Foundation

The work started with listening

10 participants across both user groups — Remittance Gateway (provider-facing) and Adjustor (internal payer-facing). Remote 1:1, 1:2, and 1:3 sessions, 45–60 minutes each. Synthesis method: workflow mapping, pain point scoring, thematic analysis.

User Interview
Executive Summary

Jopari Platform Enhancements

Interview Period:February, 2026 Participants:10 total Method:Remote 1:1, 1:2, 1:3 (45–60 min) Analysis:Workflow mapping, pain scoring, thematic synthesis

Critical Insights

1

Lifecycle Visibility Breaks Trust

Users cannot trace bills and payments end-to-end without hunting across tabs.

2

Search Blocks Investigation

Overly strict validation and mandatory fields force users into workarounds.

3

Bulk Workflows Break at Volume

Bulk actions don't carry through — forcing one-by-one fixes at scale.

4

Missing Artifacts Drive Escalations

When proof is needed, the portal can't provide key identifiers — increasing rework.

Top 15 Tasks · Frequency × Pain Severity

Task	Freq	Pain
Trace payment lifecycle	Daily	Critical
Resolve missing attachments	Daily	Critical
Load exception list	Daily	Critical
Search by partial claim number	Daily	Critical
Process Bill Index exceptions	Daily	Critical
Download remittance files (bulk)	Daily	High
Filter work list by exception type	Daily	High
Bulk upload missing attachments	Daily	High
7 more tasks…	Daily–Wkly	Med

Scoring determined sequence of design priorities across both portals

Research ArtefactUser Interview Executive Summary — February 2026. Synthesised from 10 interviews, 6+ hours of sessions across Remittance Gateway and Adjustor portal user groups.

IA Artefact Proposed Information Architecture V1 — restructured navigation for both Remittance Gateway and Adjustor portals, reducing navigation steps for daily operational tasks.

Critical · Daily · Exception Management

"I click on Tasks and then I go get coffee. It takes that long to load."

— Operational user, Remittance Gateway portal

Critical · Daily · Search & Discovery

"If I'm off by one digit in a claim number, I get nothing. I have to know the exact answer to use the search."

— Adjustor portal user

High · Daily · Payment Management

"I download a PDF just to see if it's the right one. Then I download another. It's the only way to check."

— Provider billing specialist

High · Daily · ERA Management

"I need to reconcile 20 payments, so I download 20 files one at a time. There's no other way."

— Medical billing specialist

My Approach

Understand the system before redesigning the surface

The platform's complexity wasn't cosmetic. Many workflows had legacy operational logic tied to backend conditions that weren't visible in the UI. Redesigning the surface without understanding those constraints would have created new problems.

1

Map the real system, not the assumed one

Before touching wireframes, I walked through current-state workflows end-to-end — tracing how payees, folders, banks, enrollments, and payment states related to each other. Many of these relationships existed only in stakeholder knowledge, not in the interface. Making them explicit was prerequisite to designing anything.

2

Test with operational users early, not just SMEs

User testing with operational teams — people who used the platform daily at volume — gave us direct feedback on where the mental model broke down, which parts required help even for experienced users, and which problems felt most painful in practice.

3

Redesign for clarity, not just consistency

Every design decision was framed around one question: does this help users understand what's happening, what it means, and what to do next? Where the answer was no, we redesigned. Where legacy constraints prevented the ideal solution, we found the best available option and documented the gap.

Key Decisions

Three choices that shaped the outcome

01

Dashboard Strategy

Reframe the dashboard around action, not data

The existing dashboard surfaced large amounts of passive data — historical records, full tables, status counts. Users had to interpret this data themselves to determine what needed attention.

We redesigned the dashboard to lead with what requires attention, what has changed, and where to act next. Data didn't disappear — it was still accessible — but it was no longer the entry point.

The tension: surfacing fewer things by default meant some users initially felt like information was missing. We validated in testing that prioritised action items were more useful than comprehensive data views for daily operational work.

Redesigned Dashboard · Home Priority-first layout — 4 summary cards (Missing Attachments, ERA, Bills in Error, Rejected Batches), "Needs attention" queue with severity tags, and Recent Activity feed. Shown at reduced fidelity.

02

Enrollment Experience

Make the flow reflect the system, not fight it

The original enrollment flow was built as a linear step-by-step form. But the actual system logic was dynamic — steps changed depending on folder context, bank assignment, and entry point. The form didn't communicate this, so users encountered unexpected states with no explanation.

We redesigned enrollment as a context-aware workflow — steps surface conditionally, persistent summaries show where the user is in the overall process, and conditional steps are explained rather than appearing silently.

The tension: exposing conditional logic means surfacing complexity that was previously hidden. We had to determine what to show, what to explain, and what to abstract — a balance between transparency and cognitive load.

03

Status Communication

Separate status contexts that were being conflated

Across the platform, enrollment status, payee status, and payment status were represented using similar terminology. In testing, users regularly misread one type of status as another — leading to incorrect actions and frustration.

We introduced clearer, context-specific status terminology, contextual tooltips explaining what each status meant in context, and visual separation between different status types.

The tension: introducing more terminology risked increasing cognitive load. We kept the vocabulary minimal and prioritised plain language over system terminology wherever the system allowed.

Bills in Error · Status Redesign Contextual error codes (A7:187, T-08, T-22) surfaced inline on hover — users see exactly what failed without navigating away. Colour-coded status badges (Error / Processing) replace ambiguous shared labels. Shown at reduced fidelity.

Before → After · Status clarity

Before

Pending

Active

Same label, 3 different meanings across contexts

After

Awaiting bank confirmation

Payment processing

Enrollment active

Context-specific labels, no ambiguity

Illustrative concept — actual terminology and visual system not shown in full.

Payees & Banks Workflow

Redesigning enrollment end-to-end

The Payees & Banks section was one of the most fragmented areas of the platform — users managed folders, bank assignments, payment methods, and enrollment rules across disconnected screens. The redesign unified these into a single, card-based workspace.

Payees · Card View Folder-based payee management — payment methods, enrollment status, and bank assignment visible at a glance. Inline actions (Assign Bank, Enroll Payees, Add Enroll Rule) replace buried navigation.

Enroll Payees · Step 1 of 4 Context-aware enrollment flow — search filters on the left, selectable payee table on the right. Progress indicator (1 of 4) surfaces the overall workflow. Shown at reduced fidelity.

Wireframe · Payees & Banks Early structural exploration — tabbed navigation (Payees / Banks / Payer Info) and grid-based folder layout. This blockframe established the layout before visual design, aligning with stakeholders on information hierarchy.

Outcome

Workflows that guided users instead of testing them

Validated through user testing with operational teams. The results were qualitative — this was not a before/after A/B test — but the signal was consistent and directional across multiple sessions.

Navigation

Participants navigated workflows with significantly less guidance than in the original platform — fewer dead ends, fewer requests for help.

Comprehension

Users understood next actions more quickly. The redesigned dashboard reduced time spent scanning to determine where to start.

Error Tracing

Participants traced payment and bill errors more confidently — status separation and contextual tooltips reduced misinterpretation.

Scalability

Redesigned workflow patterns were built to support future operational scenarios — the system is more extensible than the original point-solution screens.

Reflection

What I'd do differently

"Map the system relationships first — before the first wireframe."

Looking back, the highest-leverage thing I could have done earlier was a complete map of the relationships between payees, folders, banks, enrollments, and payment states. Many of the workflows we redesigned were shaped by backend constraints and operational logic that weren't surfaced in the UI — and we discovered them incrementally throughout the project.

Understanding those relationships upfront would have reduced design iterations and helped us make better architectural decisions earlier. I'd also advocate harder for cross-role user testing earlier — feedback varied significantly between payment-focused users and enrollment-focused users, and we didn't surface that divergence until later than was ideal.