Cloud-native collection platform
Loxon next-generation collection platform built for banks, neobanks, and non-bank financial institutions
COMPANY
Loxon Solutions
ROLE
Senior Product Designer
EXPERTISE
Product Design
YEAR
2019–2026
COMPANY
Loxon Solutions
ROLE
Senior Product Designer
EXPERTISE
Product Design
YEAR
2019–2026
COMPANY
Loxon Solutions
ROLE
Senior Product Designer
EXPERTISE
Product Design
YEAR
2019–2026
What is Loxon Collection?
What is Loxon Collection?
~ 1 min Promise To Pay registration
~ 1 min Promise To Pay registration
~ 1 min Promise To Pay registration
33% Promise To Pay flow improvement
33% Promise To Pay flow improvement
33% Promise To Pay flow improvement
Avg. implementation period 30 days
Avg. implementation is 30 days
Avg. implementation period 30 days
7 project implementations
7 project implementations
7 project implementations
Loxon Collection (Collection-X internally) is an end-to-end debt collection platform used by banks and financial institutions. It covers the whole journey: from pre-collection to legal recovery, and has four types of user: call-center operators, supervisors, collection heads, and the bank's own customers.
How do you make one complex system give different users the right context and tools at each phase?
Loxon Collection (Collection-X internally) runs the delinquency cycle end to end: segmenting the portfolio, allocating the work, driving customer contact, and turning each outcome into the next step, from pre-collection to the legal phase. Collection-X is its next generation.
How do you make one system serve every phase of the cycle and give a user the right context at each one?
Loxon Collection (Collection-X internally) runs the delinquency cycle end to end: segmenting the portfolio, allocating the work, driving customer contact, and turning each outcome into the next step, from pre-collection to the legal phase. Collection-X is its next generation.
How do you make one system serve every phase of the cycle and give a user the right context at each one?
Main objective
Main objective
Main objective
Move from legacy data-heavy enterprise screens to workflows that guide each user's next decision.
Move from legacy data-heavy enterprise screens to workflows that guide each user's next decision.
Move from legacy data-heavy enterprise screens to workflows that guide each user's next decision.
How it all started, and my role in it
How it all started, and my role in it
I joined Loxon in 2019 as a product designer, shaping the vision and roadmap with a senior designer and in-house collection experts. Over seven years I became the senior product designer, responsible for the end-to-end experience of the platform, from research with domain experts to the product that shipped, and I led its design decisions.
I worked daily with business analysts, collection experts and developers, and regularly presented design decisions to stakeholders. After launch, I supported client implementations by helping configure the product for each bank’s requirements.
I joined Loxon in 2019 as a product designer, shaping the vision and roadmap with a senior designer and in-house collection experts. Over seven years I became the senior product designer, responsible for the end-to-end experience of the platform, from research with domain experts to the product that shipped, and I led its design decisions.
I worked daily with business analysts, collection experts and developers, and regularly presented design decisions to stakeholders. After launch, I supported client implementations by helping configure the product for each bank’s requirements.
I joined Loxon in 2019 as a product designer, shaping the vision and roadmap with a senior designer and in-house collection experts. Over seven years I became the senior product designer, responsible for the end-to-end experience of the platform, from research with domain experts to the product that shipped, and I led its design decisions.
I worked daily with business analysts, collection experts and developers, and regularly presented design decisions to stakeholders. After launch, I supported client implementations by helping configure the product for each bank’s requirements.
Users and their challenges
Users and their challenges
The call center operator is the role this case study focused on, so it's worth knowing who they are. This profile comes from one real client's project, drawn up after we tested our assumptions with real operators.
The call center operator is the role this case study focused on, so it's worth knowing who they are. This profile comes from one real client's project, drawn up after we tested our assumptions with real operators.
Call Center Operator
Call Center Operator
Call Center Operator
Typically young, working shift-based days under a supervisor
Handles 60–100 cases and 50–80 outbound calls a day
Moving between Loxon Collection system, its dialer, Outlook, Excel, and a paper notepad
Goal — complete the task list, hit recovery targets, finish wrap-up on time
Friction — prioritisation happens in Excel. Escalations have to go through a supervisor
Typically young, working shift-based days under a supervisor
Handles 60–100 cases and 50–80 outbound calls a day,
Moving between Loxon Collection system, a dialer, Outlook, Excel, and a paper notepad.
Goal — complete the task list, hit recovery targets, finish wrap-up on time.
Friction — prioritisation happens in Excel. Escalations have to go through a supervisor
Typically young, working shift-based days under a supervisor
Handles 60–100 cases and 50–80 outbound calls a day
Moving between Loxon Collection system, built-in dialer, Outlook, Excel, and a paper notepad
Goal — complete the task list, hit recovery targets, finish wrap-up on time
Friction — prioritisation happens in Excel. Escalations have to go through a supervisor
Early drafts and steps forward
Customer 360 page
Every role relies on Customer 360, the one place where all customer information is placed. For operators, though, it has to work in real time, with the customer on the line and seconds to act.
How might operators grasp a customer's situation in seconds, and know what to offer, while the call is running?
I designed its layout and information architecture, starting from research: every attribute an operator might need, mapped as a user story.
Every attribute mapped as a user story
Designing the core experience
Designing the core experience
Customer 360
Every role relies on Customer 360, the one place where all customer information is placed. For operators, though, it has to work in real time, with the customer on the line and seconds to act.
How might operators grasp a customer's situation in seconds, and know what to offer, while the call is running?
I designed its layout and information architecture, starting from research: every attribute an operator might need, mapped as a user story.
Every attribute mapped as a user story
The first draft and its assumptions
The first draft came from internal collection consultants, not yet from real operators. Since these were data-heavy pages and we already had pre-designed components, the quick path was a high-fidelity layout for testing.
Two assumptions followed:
1. A complete picture is the most useful picture. Consultants see a debtor holistically, we displayed every attributes that were important at that time.
2. The page belongs to the call. Scoped to one task and built around the process as it was described to us.
First hi-fi draft
The first draft and its assumptions
The first draft came from internal collection consultants, not yet from real operators. Since these were data-heavy pages and we already had pre-designed components, the quick path was a high-fidelity layout for testing.
Two assumptions followed:
1. A complete picture is the most useful picture. Consultants see a debtor holistically, we displayed every attributes that were important at that time.
2. The page belongs to the call. Scoped to one task and built around the process as it was described to us.
First hi-fi draft
What testing revealed
Testing with collection experts and a selection of the client's users sorted the assumptions quickly.
The data was right. Nothing on the page told user where to look. I ranked the page around the decision: a profile summary on top (status, days past due, total past due), then willingness, affordability, delay and risk. Everything else moved into the content navigator.
The page can be reopened by a different operator, often days later. The last communication placed in the profile, and contacts, calendar and workflows, so the next person picks up where the last stopped.
The solution:
Operators now see what matters first, find every detail they need, and pick up every customer's history from previous calls. The page became part of the standard implementation, configurable per client.
Testing with collection experts and a selection of the client's users sorted the assumptions quickly.
The data was right. Nothing on the page told user where to look. I ranked the page around the decision: a profile summary on top (status, days past due, total past due), then willingness, affordability, delay and risk. Everything else moved into the content navigator.
The page can be reopened by a different operator, often days later. The last communication placed in the profile, and contacts, calendar and workflows, so the next person picks up where the last stopped.
The solution:
Operators now see what matters first, find every detail they need, and pick up every customer's history from previous calls. The page became part of the standard implementation, configurable per client.
Testing with collection experts and a selection of the client's users sorted the assumptions quickly.
The data was right. Nothing on the page told user where to look. I ranked the page around the decision: a profile summary on top (status, days past due, total past due), then willingness, affordability, delay and risk. Everything else moved into the content navigator.
The page can be reopened by a different operator, often days later. The last communication placed in the profile, and contacts, calendar and workflows, so the next person picks up where the last stopped.
The solution:
Operators now see what matters first, find every detail they need, and pick up every customer's history from previous calls. The page became part of the standard implementation, configurable per client.
The building blocks
Alongside the product work, I extended and maintained the design system and its components, keeping every screen and client implementation consistent as the product grew.
I also led the product’s visual language: every illustration in the system, including one for each business status, and a custom icon font that gave developers full flexibility in size and colour. I also revised the existing components for WCAG accessibility, and designed every new one with it in mind.
Alongside the product work, I extended and maintained the design system and its components, keeping every screen and client implementation consistent as the product grew.
I also led the product’s visual language: every illustration in the system, including one for each business status, and a custom icon font that gave developers full flexibility in size and colour. I also revised the existing components for WCAG accessibility, and designed every new one with it in mind.
From call to Promise To Pay
Most calls end in the same place: a Promise to Pay, the customer's commitment to repay a set amount by a set date. It's the operator's core task, and it happens mid-conversation, with everything from Customer 360 still within reach.
How might we guide operators through a call so it stays fast and natural, yet every step is consistent and auditable?
Most calls end in the same place: a Promise to Pay, the customer's commitment to repay a set amount by a set date. It's the operator's core task, and it happens mid-conversation, with everything from Customer 360 still within reach.
How might we guide operators through a call so it stays fast and natural, yet every step is consistent and auditable?
The call flow, mapped with collection experts
Early drafts, corrected by real user needs
The first draft came from internal collection consultants, not yet from real operators. Since these were data-heavy pages and we already had pre-designed components, the quick path was a high-fidelity layout for testing.
Two assumptions followed:
1. A complete picture is the most useful picture. Consultants see a debtor holistically, we displayed every attributes that were important at that time.
2. The page belongs to the call. Scoped to one task and built around the process as it was described to us.
First high fidelity prototype
Prototyping phase
The flow was correct. Would it be usable?
Collection experts had confirmed the flow, but a logically sound sequence can still lose the person walking through it. Finding that out after build would have been expensive.
So I built a low-fidelity prototype, with no colour, no real data and no visual design, to test one thing: could an operator move through a call?
The result: they could, and the flow moved into hi-fi design.
Low-fi prototype of a flow
Prototyping phase
The flow was correct. Would it be usable?
Collection experts had confirmed the flow, but a logically sound sequence can still lose the person walking through it. Finding that out after build would have been expensive.
So I built a low-fidelity prototype, with no colour, no real data and no visual design, to test one thing: could an operator move through a call?
The result: they could, and the flow moved into hi-fi design.
Low-fi prototype of a flow
Prototyping phase
The flow was correct. Would it be usable?
Collection experts had confirmed the flow, but a logically sound sequence can still lose the person walking through it. Finding that out after build would have been expensive.
So I built a low-fidelity prototype, with no colour, no real data and no visual design, to test one thing: could an operator move through a call?
The result: they could, and the flow moved into hi-fi design.
Low-fi prototype of a flow
Dialer — every known number for the customer, with its status and contact-related comments
Built-in chat — several conversations in parallel, switched with keyboard shortcuts, inside the same call flow.
Dialer — every known number for the customer, with its status and contact-related comments
Built-in chat — several conversations in parallel, switched with keyboard shortcuts, inside the same call flow.
Dashboard. The start of a day: personal and team results at a glance, and one CTA button to begin.
Call in progress — identification one question at a time, with every deal and its Promise to Pay close by.
PTP registration. The promise built step by step, with every rule checked as you go; registration unlocks only when all conditions are met.
Dashboard. The start of a day: personal and team results at a glance, and one CTA button to begin.
Call in progress — identification one question at a time, with every deal and its Promise to Pay close by.
PTP registration. The promise built step by step, with every rule checked as you go; registration unlocks only when all conditions are met.
Dashboard. The start of a day: personal and team results at a glance, and one CTA button to begin.
Call in progress — identification one question at a time, with every deal and its Promise to Pay close by.
PTP registration. The promise built step by step, with every rule checked as you go; registration unlocks only when all conditions are met.
What testing revealed
Easy to learn
Operators found the flow consistent and close to what they expected.
Operators found the flow consistent and close to what they expected.
Baseline: 1 min 20 s
Average time to register a single Promise to Pay
Average time to register a single Promise to Pay
Too many clicks
Registering a single Promise to Pay took 15 clicks.
Registering a single Promise to Pay took 15 clicks.
Multi-topic calls
On calls covering several deals, operators sometimes lost track of which task to execute next
On calls covering several deals, operators sometimes lost track of which task to execute next
Testing with client operators on site
What testing revealed
Easy to learn
Operators found the flow consistent and close to what they expected.
Baseline: 1 min 20 s
Average time to register a single Promise to Pay
Too many clicks
Registering a single Promise to Pay took 15 clicks.
Multi-topic calls
On calls covering several deals, operators sometimes lost track of which task to execute next
Testing with client operators on site
What changed:
After several iterations and testing, I added shortcuts and redirects to reduce friction at each major step over the flow. It allowed to make seamless transition between a call task and a single PTP registration. That was a quick win, since the flow itself performed well. As a result cutting a single Promise to Pay registration from 15 clicks to 10, bringing it under a minute.
What changed:
After several iterations and testing, I added shortcuts and redirects to reduce friction at each major step over the flow. It allowed to make seamless transition between a call task and a single PTP registration. That was a quick win, since the flow itself performed well. As a result cutting a single Promise to Pay registration from 15 clicks to 10, bringing it under a minute.
What changed:
After several iterations and testing, I added shortcuts and redirects to reduce friction at each major step over the flow. It allowed to make seamless transition between a call task and a single PTP registration. That was a quick win, since the flow itself performed well. As a result cutting a single Promise to Pay registration from 15 clicks to 10, bringing it under a minute.
The result:
A guided call with every activity checked as you go, and a Promise to Pay registered in under a minute, down from 1 min 20 s. Multi-topic handling is in the backlog and requires deeper investigation.
The result:
A guided call with every activity checked as you go, and a Promise to Pay registered in under a minute, down from 1 min 20 s. Multi-topic handling is in the backlog and requires deeper investigation.
The result:
A guided call with every activity checked as you go, and a Promise to Pay registered in under a minute, down from 1 min 20 s. Multi-topic handling is in the backlog and requires deeper investigation.
Other features
Other features
The core flows are supported by tasks, history, documents and allocation.
The core flows are supported by tasks, history, documents and allocation.
Task list. What's assigned, what's available, and what's about to expire. Tasks group by urgency, each card carries its own deadline, and filters narrow by type and priority.
Calendar overview — what's been done and what's coming next for a customer in one view,
Incoming document sorting. Preview on the left, find the right customer or deal on the right, attach, move to the next one.
Debt selling is where the collection head builds packages, manually or automatically, and tracks them from draft to auction in one system.
Manual task allocation. Supervisors match urgent work to available people in one move, for one task or many.
Task list. Every task grouped by urgency and deadline, with filters for type and priority, so operators always know what to pick up next.
Calendar overview — what's been done and what's coming next for a customer in one view,
Incoming document sorting. Preview on the left, find the right customer or deal on the right, attach, move to the next one.
Debt selling is where the collection head builds packages, manually or automatically, and tracks them from draft to auction in one system.
Manual task allocation. Supervisors match urgent work to available people in one move, for one task or many.
Task list. Every task grouped by urgency and deadline, with filters for type and priority, so operators always know what to pick up next.
Calendar overview — what's been done and what's coming next for a customer in one view,
Incoming document sorting. Preview on the left, find the right customer or deal on the right, attach, move to the next one.
Debt selling is where the collection head builds packages, manually or automatically, and tracks them from draft to auction in one system.
Manual task allocation. Supervisors match urgent work to available people in one move, for one task or many.
Self-service application
Self-service application
Self-service application
How might customers resolve their debt themselves, in an app they trust as their bank's?
Not every case needs a call. The self-service app, built as a Progressive Web Application, gives the bank's customers their portfolio, payment promises and notifications, plus a direct channel to the bank, so cooperative customers can settle on their own terms.
Trust depends on recognition, so the app carries each bank's identity.
Sometimes we designed the UI kit, sometimes the bank supplied its own, and the app had to absorb either, across multiple languages and both reading directions.
The result:
Customers see what they owe, promise or pay in a few taps, and reach the bank without a call, in an app that looks like their bank's.
How might customers resolve their debt themselves, in an app they trust as their bank's?
Not every case needs a call. The self-service app, built as a Progressive Web Application, gives the bank's customers their portfolio, payment promises and notifications, plus a direct channel to the bank, so cooperative customers can settle on their own terms.
Trust depends on recognition, so the app carries each bank's identity.
Sometimes we designed the UI kit, sometimes the bank supplied its own, and the app had to absorb either, across multiple languages and both reading directions.
The result:
Customers see what they owe, promise or pay in a few taps, and reach the bank without a call, in an app that looks like their bank's.
Core screens: portfolio, payment promises, chat with the bank, notifications and profile
Core screens: portfolio, payment promises, chat with the bank, notifications and profile
Core screens: portfolio, payment promises, chat with the bank, notifications and profile
Arabic (right-to-left), Slovak and Hungarian
Arabic (right-to-left), Slovak and Hungarian
Case Study 2 - Advanced configurability tool for complex financial products
Results and Learnings
Results and Learnings
~ 1 min
Single-deal Promise to Pay registration is
Fewer clicks per Promise To Pay
33%
No. of implementations
7 projects
Avg. implementation period
30 days
~ 1 min
Single-deal Promise to pay registration is
No. of implementations
7 projects
Fewer clicks per Promise To Pay
33%
Avg. implementation period
30 days
~ 1 min
Single-deal Promise to pay registration is
Fewer clicks per Promise To Pay
33%
No. of implementations
7 projects
Avg. implementation period
30 days
Fidelity depends on the question
Fidelity depends on the question
For Customer 360, a polished draft was the fastest way to get honest reactions. For the call flow, the same polish would have got in the way. Choosing the fidelity for each question saved us from building the wrong thing twice.
Design happens in conversation
Some of the most important design work on this product never happened in Sketch or Figma. It happened when an analyst asked how to parametrise a panel, when a developer and I worked out how to extend a component, and when a collection expert explained how banks actually operate.
Fidelity depends on the question
For Customer 360, a polished draft was the fastest way to get honest reactions. For the call flow, the same polish would have got in the way. Choosing the fidelity for each question saved us from building the wrong thing twice.
Design happens in conversation
Some of the most important design work on this product never happened in Sketch or Figma. It happened when an analyst asked how to parametrise a panel, when a developer and I worked out how to extend a component, and when a collection expert explained how banks actually operate.
Case Study 2 - Advanced configurability tool for complex financial products
Case Study 2 - Advanced configurability tool for complex financial products
Useful links
Useful links
Useful links