Exception Management — US Bank Singlepoint

// 01 — The Brief

Pulling exception management out of legacy

US Bank's Singlepoint handles ACH payments, wire transfers, receivables, and treasury operations at scale. Exception Management was a critical feature living in an aging, siloed tool that was being sunset.

My job: lead the UX migration into Singlepoint's design system without losing the workflows finance teams depended on daily.

What made it hard was the organizational layer: six PMs with different roadmap priorities, a compressed timeline, and a team of three designers I was coordinating.

US Bank Singlepoint — Exception Management receivable detail screen

6

Stakeholders managed

4 receivables PMs, a PM manager, and a support manager — each with different customer commitments and success metrics.

2

UX Designers managed

A visual specialist and a content designer — coordinated across workstreams to maintain system consistency and voice.

4

Industry verticals

Four distinct industry workflows identified — each with unique exception handling rules, urgency thresholds, and data expectations.

1

Feature. Many owners.

Exception Management had to satisfy ACH returns, wire returns, RTP fund returns, entitlement rules, and remittance tracking — under one roof.

// 02 — Stakeholder Landscape

Managing up, across, and through

Before a single wireframe, I had to understand the room — four receivables PMs, a PM manager, and a support manager, each with different commitments and definitions of "done."

Exception Management design thinking workshop — assumptions exercise

// Design Team

Visual Specialist Component design, visual hierarchy, and design system alignment

Content Designer UX copy, error states, labels, and in-product guidance

// Lead UX

Douglas Hiller

Design strategy · PM alignment · Dev handoff · System consistency

Receivables PMQueue config & exception flows

Receivables PMACH & wire return handling

Receivables PMRemittance & RTP returns

Receivables PMIndustry-specific workflows

PM ManagerRoadmap alignment & escalation

Support ManagerCustomer feedback & issue triage

// Dev Team

Singlepoint Component Library Existing design system constraints we had to work within and extend

API / Data Team Production exception data pipelines, remittance lookup, RFRF/RTP feeds

QA & Release Compressed timeline, pressure to launch ahead of schedule

// The Coordination Problem

Each PM owned a different piece of the customer's day — DSO, return item rates, entitlement complexity. None had a shared picture of what the user actually needed to do in a single session.

// What I Did About It

I ran a cross-PM alignment workshop using a JTBD framework — mapping the user's actual job story instead of debating features. Getting six PMs to agree on a user story is harder than it sounds. It became the source of truth for every prioritization debate that followed.

// 03 — Research & Discovery

What the assumptions exercise surfaced

We ran a structured workshop: assumption spilling, JTBD mapping, and a "How might we?" ideation pass — to surface what we thought we knew and pressure-test it.

Exception Management — Jobs to Be Done and How Might We workshop

01

// Job to Be Done

Create exception management frameworks

"Every day brings new issues — missing invoices, payments I can't reconcile. I need the system to help me build rules, not chase items manually."

02

// Job to Be Done

Determine the state of accounts receivable

"I'm putting out fires all day. I need to break down our AR data and understand what it means — normal or not. Without that view, I'm just guessing."

03

// Job to Be Done

Post a receivable and find remittance

"Some receivables have missing remittance. Finding it means digging — US Bank, the payer website, a support ticket. It shouldn't take longer to find the context than to fix the problem."

// How might we?

Make it easier for customers to write their own queues and rules — without support involvement?

// How might we?

Surface the most relevant and actionable exception information in a way the user actually understands?

// How might we?

Minimize the time it takes users to find the remittance they need — without leaving the platform?

// 04 — Competing Priorities

The constraints we had to navigate

The assumptions exercise uncovered where the team's beliefs conflicted — and where those conflicts would become design problems if unaddressed.

⚡

Schedule pressure

Pressure to launch early risked shipping an MVP that didn't solve the core jobs — a bad first impression with enterprise clients.

⚡

Solutioning for all vs. top needs

Four industries had different workflows. We had to resist building for every edge case and define what was core vs. phase two.

⚡

Entitlement complexity

Overlapping entitlement options inherited from legacy — every PM had a different answer. Simplifying required looping in legal and compliance.

⚡

Feature vs. maintenance balance

The more configurable the rules engine, the higher the maintenance burden — a cost we had to weigh against every design decision.

⚡

Customer feedback timing

Enterprise clients have long cycles. Getting enough feedback before the launch window closed required a structured beta cohort.

⚡

Automatic payment assumptions

Several PMs assumed users wanted automation. Research showed the opposite — users needed control, not surprises.

// 05 — Design & Integration

Working within Singlepoint's system

The hardest constraint wasn't visual — it was behavioral. We couldn't change how payers behaved. We could only build a better tool to react.

01

Audit legacy tool

Catalogued every screen and workflow in the retiring system — what was used, abandoned, and missing entirely.

02

PM alignment sessions

Facilitated working sessions with all six PMs using JTBD as a shared reference — prioritizing against one user story, not six competing feature lists.

03

Design system mapping

Mapped workflows against Singlepoint's component library. Extended patterns — queues, rules builders, detail drawers — with dev sign-off.

04

Parallel designer coordination

Divided ownership across three designers by area. Weekly syncs maintained visual and interaction consistency across workstreams.

05

Iterate & validate

Ran structured beta cohort reviews. Filtered feedback through the PM layer to avoid scope creep.

// Legacy Tool — Before

Siloed from Singlepoint — required separate login
Rules and queue configuration required bank support
No remittance lookup — users left the platform to search
No industry-specific views — one layout for all verticals
ACH, wire, and RTP exceptions spread across separate screens
Days Open / DSO not surfaced — required manual calculation
Entitlement options overlapping and poorly labeled

// Singlepoint Integration — After

Unified within Singlepoint — single session, no context switch
Self-service queue and rules builder with guided configuration
Inline remittance lookup surfaced within exception detail
Industry-aware views adapted to workflow priority differences
Unified exception queue: ACH, wire, RTP in one consolidated view
Days Since Open and DSO displayed at queue and item level
Simplified entitlement model — reduced to essential role distinctions

// 06 — Iterating to Decisions

Weekly reviews that drove the design forward

Decisions on a project this complex come from showing up every week with a working prototype and updating it in response to what broke down in the room.

Exception Management — mid-fidelity prototype iteration rounds

// The weekly cadence

Every week: a clickable prototype to the full stakeholder group — PMs, dev leads, support manager. A working flow, not slides. That format forced real reactions instead of hypothetical feedback.

// Why it worked

A prototype in motion made disagreements concrete. PMs had to point at something specific — that specificity turned opinion into a decision we could act on the next week.

01

Present the prototype

Walk the group through the current flow — from queue entry to resolution, every edge case visible.

02

Capture live feedback

Documented reactions in real time. Disagreements became the agenda for the next iteration.

03

Update before next week

Every session ended with a change list. Prototype updated before the next review — no floating decisions.

04

Mark ready for dev

Screens stayed "not ready for dev" until every stakeholder signed off. Dev only started on screens that had cleared the full review cycle.

// What the iteration record showed

The queue view took four rounds to mark dev-ready. The rules builder took six. The entitlement flow — most PM disagreement — took eight weeks. That's not failure. That's the process working: hard decisions surfaced early, not buried in engineering rework.

// 07 — Outcomes & Reflection

What stakeholder management actually looks like

// What shipped

Exception Management launched with a unified queue, self-service rules config, inline remittance lookup, and industry-adaptive views — replacing the legacy tool without data loss, on schedule.

// What I learned about managing up

Six PMs don't align by attending the same meeting. Alignment happens when you give people a shared user story to argue about — not competing roadmaps to argue from. Rigorous decision logging eliminated revisiting settled debates and gave the team one source of truth.

// What I'd do differently

I'd build a "design decision log" earlier — tracking every non-obvious call and which stakeholder aligned to it. Dozens of tradeoff decisions lived only in meeting notes; centralizing them would have shortened re-litigation. I'd also push for beta customer access at the research phase, not just validation — their signal is higher quality than internal proxies.