ai-assisted development
Field Collector: a mobile and desktop platform for field debt collection
COMPANY
Loxon Solutions
ROLE
Senior Product Designer
EXPERTISE
Product Design
YEAR
February - April 2026
What is Field Collector?
What is Field Collector?
Proof of Concept approved by a client
Proof of Concept approved by a client
-70% Development effort vs. Estimated
Field Collector is Loxon's first business module with AI-assisted development. It supports collection agents who visit borrowers in person on-site. Agents get a daily visit list, a map of their assigned customers and a guided flow to confirm who they’re speaking to and record the outcome. A desktop operator portal lets supervisors assign cases, monitor agents and follow their routes. The proof of concept was shown to the client on site and approved.
Main challenge
Field agents work alone and on the move, with little help planning their day or capturing visits consistently. Sometimes with limited connectivity. Supervisors have no live view of what is happening in the field.
Field Collector is Loxon's first business module with AI-assisted development. It supports collection agents who visit borrowers in person on-site. Agents get a daily visit list, a map of their assigned customers and a guided flow to confirm who they’re speaking to and record the outcome. A desktop operator portal lets supervisors assign cases, monitor agents and follow their routes.
The proof of concept was shown to the client on site and approved.
Main challenge
Field agents work alone and on the move, with little help planning their day or capturing visits consistently. Sometimes with limited connectivity. Supervisors have no live view of what is happening in the field.
Main objective
Quickly build and test a greenfield solution with AI-assisted development: a native Android app and a desktop operator portal.
Quickly build and test a greenfield solution with AI-assisted development: a native Android app and a desktop operator portal.
My role
I worked closely with the collection experts, the CTO and a developer on a prototype that could later join the Loxon Collection product family. I started with a low-fi prototype to test the idea and built a small design system for the project. During development I reviewed every AI-generated iteration and guided the developer on design decisions on a daily basis.
I worked closely with the collection experts, the CTO and a developer on a prototype that could later join the Loxon Collection product family. I started with a low-fi prototype to test the idea and built a small design system for the project. During development I reviewed every AI-generated iteration and guided the developer on design decisions on a daily basis.
Snippet of Field Collector solution prototype, both on Android and web portal
Snippet of Field Collector solution prototype, both on Android and web portal
Context
Context
The business problem was clear. This project had a strict deadline: we had until mid-April to show a working product to a client, and the company decided to try AI-assisted development on a pilot. So the question became how to get something real and testable in front of the client, and how to keep the design aligned with Loxon’s other products.
I started working on it around mid-February. The CTO had begun preparing the development infrastructure much earlier. Together with the collection experts I built the context for the AI: first the core users, their personas and problems, then the platform and business requirements. I also made a quick low-fi prototype to test the idea and research the flows.
The business problem was clear. This project had a strict deadline: we had until mid-April to show a working product to a client, and the company decided to try AI-assisted development on a pilot. So the question became how to get something real and testable in front of the client, and how to keep the design aligned with Loxon’s other products.
I started working on it around mid-February. The CTO had begun preparing the development infrastructure much earlier. Together with the collection experts I built the context for the AI: first the core users, their personas and problems, then the platform and business requirements. I also made a quick low-fi prototype to test the idea and research the flows.
Field Agent
Platform: Mobile app (Android)
Goal: Complete the day's visits and record each outcome accurately
Context: Alone, on the move, short interactions, sensitive conversations
Needs: Clear daily plan, route on a map, a guided flow they can follow at the door
Key risk: Not being able to keep up with the daily target
Field Agent
Platform: Mobile app (Android)
Goal: Complete the day's visits and record each outcome accurately
Context: Alone, on the move, short interactions, sensitive conversations
Needs: Clear daily plan, route on a map, a guided flow they can follow at the door
Key risk: Not being able to keep up with the daily target
Supervisor/Collection Head
Platform: Desktop operator portal
Goal: Assign cases, monitor progress, keep the field team on track
Context: Managing many agents and cases at the same time
Needs: A live view of agents, visit status and performance
Key risk: Missing important decisions
Supervisor/Collection Head
Platform: Desktop operator portal
Goal: Assign cases, monitor progress, keep the field team on track
Context: Managing many agents and cases at the same time
Needs: A live view of agents, visit status and performance
Key risk: Missing important decisions
Wireframing screens for mobile application (dashboard, route planner and promise-to-pay registration)
Wireframing screens for mobile application (dashboard, route planner and promise-to-pay registration)
We faced technical, business and design constraints:
Live tracking had to run in the background, so privacy had to be designed in from the start.
The demo region in Southern Asia has poor connectivity, so the app had to keep the last known location and time.
Because of the complex AWS infrastructure, I wasn’t allowed to use AI-assisted development myself. I prototyped in my own environment to support the developer, who ran the AI iterations while I reviewed each result.
Live tracking had to run in the background, so privacy had to be designed in from the start.
The demo region in Southern Asia has poor connectivity, so the app had to keep the last known location and time.
Because of the complex AWS infrastructure, I wasn’t allowed to use AI-assisted development myself. I prototyped in my own environment to support the developer, who ran the AI iterations while I reviewed each result.
Process
Process
The first AI-generated screens came back quickly. The user flow was valid, but the look and the UX problems were there from the start, and some parts were missing completely.
The first AI-generated screens came back quickly. The user flow was valid, but the look and the UX problems were there from the start, and some parts were missing completely.
First raw AI-generated screens
First raw AI-generated screens
I reviewed the result and wrote down my thoughts on it. In parallel I built a small design system for this project, based on Loxon’s main one.
Every day we had a status call where we went through each screen and each problem it had. I shared my view there and guided the design decisions.
After that, a developer and I made the visual and UX changes, and we presented the result to the CTO and the collection experts to get feedback and align on the vision of the proof of concept. This loop happened daily during one month of active work.
I reviewed the result and wrote down my thoughts on it. In parallel I built a small design system for this project, based on Loxon’s main one.
Every day we had a status call where we went through each screen and each problem it had. I shared my view there and guided the design decisions.
After that, a developer and I made the visual and UX changes, and we presented the result to the CTO and the collection experts to get feedback and align on the vision of the proof of concept. This loop happened daily during one month of active work.
System notifications, before and after. The AI built a separate page (left); I redesigned it as a quick panel that opens from the "notification bell" on any screen (right)
System notifications, before and after. The AI built a separate page (left); I redesigned it as a quick panel that opens from the "notification bell" on any screen (right)
Design decisions
Design decisions
The AI was good at the basics. It built the simple flow of what we described, but only some of the screens. What it missed were the parts that needed design thinking: privacy, multi-step logic and the operator’s approval. Here are three decisions.
The AI was good at the basics. It built the simple flow of what we described, but only some of the screens. What it missed were the parts that needed design thinking: privacy, multi-step logic and the operator’s approval. Here are three decisions.
Privacy settings for Live activity
We chose Android because it allows full background use for GPS tracking. That raised security and privacy questions, both technical and from the design side. The AI left this part out completely, so my decision was to add an On duty / Off duty switch. Agents know when they are tracked and agree to it, and the operator portal can use that tracking.
The app also switches to Offline on its own when the connection is lost. The downside is one extra step: agents can’t use the app until duty mode is on, and the first time they also confirm GPS access.
We chose Android because it allows full background use for GPS tracking. That raised security and privacy questions, both technical and from the design side. The AI left this part out completely, so my decision was to add an On duty / Off duty switch. Agents know when they are tracked and agree to it, and the operator portal can use that tracking.
The app also switches to Offline on its own when the connection is lost. The downside is one extra step: agents can’t use the app until duty mode is on, and the first time they also confirm GPS access.
For Security and Privacy purposes we added a flow to get access to GPS tracking inside the mobile app
For Security and Privacy purposes we added a flow to get access to GPS tracking inside the mobile app
Live activities on Operator portal
From the business requirements, the operator needed to see all agents in one place. I proposed an interactive map next to the agent list, so the operator can see where agents are and how they’re performing in real time. Hover or click on an agent to see details or open the profile page. It works because of the duty mode: agents who are off duty or offline show up as that, and nobody is tracked without their consent.
Because connectivity in the demo region is poor, the map shows each agent’s last known location together with the time, so the operator can tell how fresh it is.
From the business requirements, the operator needed to see all agents in one place. I proposed an interactive map next to the agent list, so the operator can see where agents are and how they’re performing in real time. Hover or click on an agent to see details or open the profile page. It works because of the duty mode: agents who are off duty or offline show up as that, and nobody is tracked without their consent.
Because connectivity in the demo region is poor, the map shows each agent’s last known location together with the time, so the operator can tell how fresh it is.
Operator dashboard: agent status, performance and last known location in one view
Operator dashboard:
agent status, performance and last known location in one view
Multi-topic registration and operator's approval
With a single task type, AI could generate simple workflows. When it came to a multi-topic workflow, it struggled.
A visit can have one or several tasks, and a Collection task can have several activities (phone number change, cash collection, PTP and so on). We looked at two options, for both the agent and the operator who approves.
Option A: on the visit level. The visit starts with Right Party Contact verification as the first task, and the agent handles the rest. Usually one task is assigned per visit.
Option B: a separate general Collection task. It’s an umbrella for everything agents do on site, from a simple phone number change to PTP or cash collection, sometimes several at once. This way RPC is confirmed by default every time a visit starts.
We went through a few rounds of discussion and chose option B. It gave us a lot of flexibility from the technical side, and it made more sense for the UX too. The downside is that the operator doesn’t know in advance what the agent will end up doing on the spot. Still, the first concept worked.
With a single task type, AI could generate simple workflows. When it came to a multi-topic workflow, it struggled.
A visit can have one or several tasks, and a Collection task can have several activities (phone number change, cash collection, PTP and so on). We looked at two options, for both the agent and the operator who approves.
Option A: on the visit level. The visit starts with Right Party Contact verification as the first task, and the agent handles the rest. Usually one task is assigned per visit.
Option B: a separate general Collection task. It’s an umbrella for everything agents do on site, from a simple phone number change to PTP or cash collection, sometimes several at once. This way RPC is confirmed by default every time a visit starts.
We went through a few rounds of discussion and chose option B. It gave us a lot of flexibility from the technical side, and it made more sense for the UX too. The downside is that the operator doesn’t know in advance what the agent will end up doing on the spot. Still, the first concept worked.
Two ideas we considered: add a new activity from the visit (A) or from inside a task (B). Both open the same activity selection dialog.
Two ideas we considered: add a new activity from the visit (A) or from inside a task (B). Both open the same activity selection dialog.
On the other side is the operator, whose job is to approve or reject each task after it’s done. Executed tasks land in a separate menu and the operator decides one by one. That’s easy with a single task, but a visit can have several, and one of them can be a Collection task with multiple activities inside.
So I designed a Visit page that lists everything done during that visit, with a validation counter, so the operator can see what’s still waiting. And each Task page lists every activity that was registered under that visit. This flow was completely outside what the AI generated.
On the other side is the operator, whose job is to approve or reject each task after it’s done. Executed tasks land in a separate menu and the operator decides one by one. That’s easy with a single task, but a visit can have several, and one of them can be a Collection task with multiple activities inside.
So I designed a Visit page that lists everything done during that visit, with a validation counter, so the operator can see what’s still waiting. And each Task page lists every activity that was registered under that visit. This flow was completely outside what the AI generated.
Visit detail page - where the operator can see all executed tasks during a Visit and navigate into them in order to make a decision.
Task detail page - where operator can Approve or Reject a task. All information grouped under segmentation control. Activities are displayed in a masonry layout, in a most efficient way.
Summary dialog - before a visit is closed, the operator checks the result of each task. For a rejected task, the operator sees the reason and can reassign it to the same agent.
Visit detail page - where the operator can see all executed tasks during a Visit and navigate into them in order to make a decision.
Task detail page - where operator can Approve or Reject a task. All information grouped under segmentation control. Activities are displayed in a masonry layout, in a most efficient way.
Summary dialog - before a visit is closed, the operator checks the result of each task. For a rejected task, the operator sees the reason and can reassign it to the same agent.
Visit detail page - where the operator can see all executed tasks during a Visit and navigate into them in order to make a decision.
Task detail page - where operator can Approve or Reject a task. All information grouped under segmentation control. Activities are displayed in a masonry layout, in a most efficient way.
Summary dialog - before a visit is closed, the operator checks the result of each task. For a rejected task, the operator sees the reason and can reassign it to the same agent.
AI gave us a working starting point, but I still had to work through the parts it missed. After a few iterations the solution covered both the technical limits and the business requirements, and the client praised it at the demo. Next step: validating the flows with real field agents.
AI gave us a working starting point, but I still had to work through the parts it missed. After a few iterations the solution covered both the technical limits and the business requirements, and the client praised it at the demo. Next step: validating the flows with real field agents.
Results and Learnings
Results and Learnings
Approved by client
Proof of concept (based on on-site demo)
Less development effort vs. estimate (Loxon pilot)
~70%
Approved by client
Proof of concept (based on demo)
Less development effort vs. estimate
~70%
Approved by client
Proof of concept (based on on-site demo)
Less development effort vs. estimate (Loxon pilot)
~70%
Close collaboration and communication
Close collaboration and communication
Daily status updates and regular chats made a difference. It’s better to talk things through on time than to fix them later.
Daily status updates and regular chats made a difference. It’s better to talk things through on time than to fix them later.
Design decision in real time
Design decision in real time
AI is good with basics and volume, but complex interactions and flows need to be checked, and the decision usually has to be made right away.
AI is good with basics and volume, but complex interactions and flows need to be checked, and the decision usually has to be made right away.
Close collaboration and communication
Daily status updates and regular chats made a difference. It’s better to talk things through on time than to fix them later.
Design decision in real time
AI is good with basics and volume, but complex interactions and flows need to be checked, and the decision usually has to be made right away.
What I’d do differently
What I’d do differently
There was no time for proper planning. Each day brought a new problem and we solved it on the go. Next time, even a general plan would help.
The bottleneck was development, not design. If I had access to an AI tool myself, I could have solved some of the problems without waiting for a developer, and had more control over quality.
There was no time for proper planning. Each day brought a new problem and we solved it on the go. Next time, even a general plan would help.
The bottleneck was development, not design. If I had access to an AI tool myself, I could have solved some of the problems without waiting for a developer, and had more control over quality.
Case Study 1 - Collection next-gen platform built for banks, neobanks, and non-bank financial institutions
Case Study 1 - Collection next-gen platform built for banks, neobanks, and non-bank financial institutions
Useful links
Useful links
Useful links