What needs attention.
Keep the case together.
At NCRI, I designed an operating platform to move a debt collection case from intake to recovery without losing its calls, evidence, payments, ownership, or next action between tools.
View the design work
The interface was only part of the problem.
Progress stays with the case.
Collections can be traced.
- Product design, research, UX/UI, design system, prototype
- Cross-functional work with collection teams and stakeholders
- Debt collection operating platform
- 2020–2021
The workflow was spread across four tools.
My first brief at NCRI was wonderfully direct: the desktop app sometimes worked and sometimes did not. Collectors used spreadsheets, calls sat in a separate VoIP tool, and managers relied on reports that arrived after the work.
The challenge was bigger than replacing one screen. We needed an in-house system that could import cases, assign work, keep follow-ups together, connect call evidence, and give managers a current view without losing the detail behind it.
I started by following a case through the existing workflow. That made the handoffs, repeated work, and missing context much easier to see than a feature list would have.
Desktop app
Collectors worked the case here, but it did not show the whole operation.
VoIP
Calls happened beside the case, which made the outcome easy to lose.
CSV files
Teams used files to keep work moving when the product could not.
Power BI
Managers could see reports, but not always the live case behind them.
The same case moved differently in each team.
I followed the workflow with teams in Bahrain, Canada, and Pakistan. Each had adapted around the same gaps, so I carried one question through every review: what does the next person need to continue this case?
Collection operations
How does a collector decide what to do next?
Collection team
What has already happened on this case?
Collection team
Where should the call evidence live?
The operating picture arrived through exports and reports, which made it hard to see an issue while it was still unfolding.
The account needed to explain what was due, what had already been paid, and which action was available next.
Case details, earlier contact, promises, and the next call were spread across too many places.
Stalled cases and uneven workloads were difficult to notice early enough to help.
Reviewing an interaction meant rebuilding the story from call recordings, case details, and separate notes.
Imports became fragile when client files changed or fields no longer matched the expected structure.
Across roles, the same need kept returning: show me what is happening now, what happened before, and what I need to do next.
The same record had to answer three different questions.
I reviewed the model from three sides: the person collecting, the person paying, and the people responsible for the wider operation.
Can I pick up the case and know what to do next?
The case keeps activity, evidence, commitments, and the next call together so another agent can continue the work.
Can I understand the account and make the next payment?
The portal gives the debtor a clear place to sign in, recover access, and continue with the account instead of leaving the payment path ambiguous.
Can I see where the operation needs attention?
The dashboard turns live case movement into a view for deciding what needs attention, without losing the detail behind the numbers.
The useful details came from watching the work.
Watching people move through the work exposed practical problems. Actions disappeared below long forms, logs hid the case story, completed cards became noise, and status was too easy to miss. I changed each one in the next iteration.
I sketched the responsibilities before the screens.
I sketched the main responsibilities first, then mapped the information architecture and debtor journey. The rough work helped the team discuss the system before polished screens made any decision feel fixed.
Account overview.
Expanded case detail.
Payment and recovery.
Map the system before polishing it.
Plan for payment and recovery.
Four parts of the work. One case running through all of them.
The screens differ because the work differs. The model stays consistent: ownership, next action, evidence, and money travel with the case.
Start with today's work.
I put assigned work, urgency, and the next commitment ahead of the wider metrics. A collector should be able to open the product and know where to begin.
Keep the case history together.
Calls, promises, payments, evidence, and follow-up all belong to the same story. I kept them in one timeline so another collector could continue the case without rebuilding its history from separate tools.
Make long intake easier to recover.
Long intake was easy to interrupt and hard to restart. I grouped the details, kept actions close, saved progress, and surfaced possible duplicates before a new record could create more cleanup.
Keep the money beside the case.
Balance, payments, recovery, and commission were part of the case, not a separate story for later. I brought them together so the team could see what changed and how the work was credited.
Roles and status needed rules, too.
Connecting the screens was not enough. I also had to define how access, status, and ownership behaved as work moved between collectors, managers, and administrators.
I built the system as the product grew.
New requirements arrived while design and development were moving in parallel. The system gave us a shared set of type, color, states, actions, and interaction patterns instead of solving the same decision on every screen.
The model had to hold across the product.
These surfaces show how the same model carried into case work, debtor self-service, intake, evidence, statuses, and team setup.
Keep the case in view.
Account context, next action, activity, and balance stay together.
Make the account understandable.
The person paying can see what is due, what has happened, and what comes next.
Make long work safer.
Defaults, grouped details, and saved progress keep a complex case moving.
Trace the work to the money.
Payment evidence stays connected to the case and its verification state.
Give the system a shared language.
Status groups make progress legible across teams, portfolios, and case states.
Make ownership explicit.
Teams, branches, portfolios, and coverage can be managed before work is routed.
The work was unfinished. The direction was clear.
I joined at the first meeting and stayed close as design and development moved together. Requirements sometimes changed overnight. I learned to keep the product model steady while letting the screens move.
I left NCRI for another opportunity before the platform was finished. I handed the flows, screens, and design system forward. I would rather say that plainly than turn unfinished work into a launch story.
NCRI was my first corporate role. It taught me to look for the messy handoff, repeated workaround, or question people have stopped asking. That is often where the real product begins.
Following the work was more useful than starting with a feature list.
A case history only helps when calls, promises, ownership, and payments stay together.
The design system had to carry operational meaning, not just visual consistency.
If I continued the project, I would record task outcomes for the debtor and manager flows.