Case Study 01 / 03
Exception Management
US Bank Singlepoint — Legacy Migration & GTM Integration
// 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.
6
Stakeholders managed
4 receivables PMs, a PM manager, and a support manager — each with different customer commitments and success metrics.
2
Product 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.
// What's in an experience brief
Problem statement, a structured hypothesis (For / Will / Because), research status, approach type, and a running debt register — tracking accepted risk across UX design, content, accessibility, agile, tech, and product/business. One document. One source of truth.
// Why it mattered here
Six PMs each owned different customer commitments. Without a shared artifact, every prioritization conversation started from scratch. The brief made our assumptions explicit, gave the team something concrete to disagree with, and meant we were all debating the same problem — not six different ones.
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?
⚡
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.
// Activity — exception created
// Client info & past exceptions
// Activity — full resolution history
// Alignment across three disciplines
Dev, product, and business all have different definitions of "done." Lofi sessions gave each group a shared artifact to react to — surfacing misalignments while they were cheap to fix, not after hifi work was already underway.
// What the conversations surfaced
The client info and activity tabs triggered immediate pushback: the legacy tool had no audit trail, and business stakeholders flagged that AR teams needed to see who did what and when to handle customer disputes. That gap — invisible in the brief — only emerged because the lofi made it real enough to react to.
01
Bring rough screens, not polished ones
Intentionally kept fidelity low — placeholder labels, no color, raw layout. This signaled that nothing was precious and every reaction was welcome.
02
Review with dev, product, and business together
Running cross-functional sessions — not separate ones — meant each group heard the other's constraints in real time, reducing back-channel misalignment.
03
Surface assumptions and gaps early
Rough screens provoked the reactions that polished ones suppress. Stakeholders were quicker to flag missing functionality and workflow gaps when the design still looked changeable.
04
Use feedback to direct the next iteration
Patterns across the three groups — what everyone flagged, not just one — became the design agenda. Shared concerns got prioritized; individual preferences didn't.
// 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.
20%
Reduction in Support Involvement Time for Issue Logging
2,000
Customers Migrated to the New Platform
10
Primary Complaints Logged Across 2,000 Ported Users
// 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.
