Making the Automation Unavoidable
Challenge
GETPAID is FIS's credit-to-cash platform — machine learning applied across collections, cash application, and credit, in a process many companies still run on spreadsheets and phone calls. The technology was well ahead of the interface: a desktop-era interface running in a browser window, inconsistent screen to screen, and a liability in sales demos as much as a daily frustration for the people using it.
A replatform onto a modern framework opened the window to fix it. Stakeholders scoped the work as look-and-feel: apply the corporate UI framework, ship it. I pushed to interview users first.
Red marked overdue amounts, past-due dates, action codes, and the recommended action itself.
Approach
Stakeholder walkthroughs taught me the product — how credit-to-cash works, what each module does, where the models operate — but they surfaced complaints rather than causes, and nothing that told me where design effort would pay off. Two things ran in parallel to answer that: user interviews, and a heuristic review I conducted of the application — an ad hoc version of a review process I later standardized for use across FIS product teams. They found different problems.
Nearly everyone I interviewed worked in Collections; several also used cash application and credit, and a couple were managers overseeing the work. That distribution turned out to be the scoping answer, and it matched the business one: Collections was the most-used module across FIS's client base, and the entry-point problem the interviews surfaced lived there.
What the interviews found: the automation was optional by accident. GETPAID's models ranked customer contact queues — deciding who a collector should call first — but only inside the Who To Contact flow. Several data views offered their own routes to contacting a customer, and each one dropped the ranking silently. Staff working from those views handled accounts off dashboard lists, and the prioritization simply didn't reach them there.
The problem wasn't distrust.
Most users never reliably encountered the AI — the product's core differentiator applied on one route through the work, and the routes people actually took bypassed it. Several customer teams had written their own training materials to get new hires through daily tasks, which told me the interface wasn't teaching anything on its own.
What the heuristic review found: compounding structural debt. Evaluated against usability heuristics, the application showed inconsistent page hierarchy and visual patterns that varied screen to screen. The customer detail page was the clearest case. The recommended action sat at the top of the page beside the customer name and was set in red — but red also marked overdue amounts, past-due dates, action codes, and every entry in the invoice-level Next Action column. The cue meant too many things to single anything out, and the customer-level recommendation was rendered identically to the eight invoice-level ones beneath it. Different problems from the interview findings, found a different way, and they pointed at the same page: the one place the system surfaced a recommendation was also the page where hierarchy was doing the least work.
Together the two tracks defined the work. The interviews said the prioritization had to stop depending on which door a user happened to come through; the review said the pages carrying a recommendation needed clearer hierarchy to hold it.
Scoping: the application was far too large to redesign at depth everywhere, so I split the effort along the two tracks. The review's findings applied product-wide, so they were addressed broadly: general implementation guidance let the corporate UI framework bring consistency to hierarchy and visual patterns across the application. The interview finding was specific to collections, so that's where concentrated UX work went — the queues and the customer detail page.
Depth where the value was, breadth everywhere else.
discovery: mapping the existing application
Design
I worked with a product manager and tech lead, and directed three design contractors. I owned the research, the usability plan and testing, and the core interaction concepts; the contractors carried detailed design and production, with me supplying style guidance, fielding standards questions, and running the design reviews.
Steering the path, not blocking it. Rather than removing the alternate entry points, I demoted them. Quick queues surfaced the AI-ranked routes — the day's assigned work, prioritized — and role-based dashboard defaults put them front and center for agents, while the unranked data-view routes stayed available but stopped being the obvious choice. The workflow itself was rebuilt around the automation instead of beside it, with system status and progress visible at each step, since a step you can't see the state of is one you won't trust.
The defaults carried the weight. Custom dashboards were supported, but the people building them are team leads and managers, not the agents working the queues — so the out-of-box view I designed is what most agents at most clients actually work in. Interviewing both groups meant the defaults were built from what the work required rather than what a configuration screen made possible.
Configurability was the escape hatch; the default was the product.
Making the recommendation visible. The page already told collectors what to do next; the screen just buried it. I took the customer detail page to high-level design myself, restructuring it around information hierarchy and working out which actions surfaced, where they sat, and how they behaved — pairing the recommendation with the single most emphatic control on the page, and demoting the invoice-level actions to plain text so the customer-level one reads as the top of the hierarchy rather than one of thirty.
Outcome
Testing with the original interview participants confirmed the direction and kept sharpening it. That was the point of returning to them: the people who'd identified the bypass problem were the ones best positioned to say whether the fix actually removed it. One collector, looking at a redesigned queue, told us the flow shouldn't let her edit the message at all — it was a standard outreach email.
The engagement closed at design delivery; development continued from there. No post-launch usage data came back to me, so the strongest evidence I have is that the users who found the problem validated the solution.
What I handed off:
- A redesigned application and navigation, modernized and consistent with FIS's brand, with the AI capabilities in the path of daily work rather than adjacent to it
- A component library extending the corporate framework where it fell short for a dense enterprise data application — progress indicators for the quick queue workflow, and table components supporting selection, expansion, and inline interaction the corporate system didn't cover
- A style guide of page templates and example screens
The last two mattered because of the handoff. Both existed so the team could keep building consistently on a direction I wouldn't be there to defend.
