ANDA Driver Performance Model + Management Dashboard
Anda is transforming transportation in Angola by helping drivers own their vehicles through asset financing, alongside ride-hailing and delivery services. I led the development of a platform that centralized their internal operations, taking Odoo, manual spreadsheets, and disconnected GPS and Yango data and turning them into one transparent system for admins and Customer Success Managers to track how active drivers are day to day, whether payments are coming in on time, and who actually needs support.
SHORT ON TIME?
TIMELINE
Feb 2026 - May 2026
TOOLS
Figma
ROLE
Product Manager
SKILLS
Product Management
Requirements + Roadmapping
Cross-Functional Collaboration
Problem
Anda helps people in Angola work, earn, and build a better future by combining ride-hailing and delivery work with a path to owning their own vehicle. But behind the scenes, admins and Customer Success Managers had no easy way to see how a driver was actually doing, were they driving regularly, going offline for long stretches, keeping up with payments, or falling behind. That data lived across Odoo, manual spreadsheets, and GPS and Yango APIs that didn't talk to each other, so admins couldn't tell whether a quiet driver was underperforming, dealing with a broken bike, or unwilling to pay. My goal was to guide the team to develop one systemthat pulled daily activity and payment data into a single, trustworthy view, so admins and CSMs could act fast and fairly.
Understanding the Users
PERSONA
Afonso Ndalu
ABOUT
Customer Success manager
Struggles to know which drivers need help most, since the data he needs is scattered across Odoo, GPS, and Yango
"I don't want to guess whether someone's struggling or just having a bad week, I need to know before I reach out."
PAIN POINTS
Has to check multiple disconnected systems just to see how active a driver has been or whether their payments are current
Can't easily tell the difference between poor performance, vehicle downtime, or a driver who simply can't pay
Has no clear way to prioritize which drivers need help most urgently
Wants to support drivers fairly, without decisions feeling arbitrary or biased
NEEDS:
Afonso needs a ranked view of her drivers, built on real signals like daily activity and payment status, that shows who needs help most urgently and why, backed by reasoning that's explainable enough for her to trust it and repeat it back to a driver if they ask.
Defining the Roadmap
I wrote the PRD for this project and framed the P0, P1, and P2 priorities, deciding what needed to ship first and help align the team around those priorities.
P0
Prioritized authentication and the core Driver Performance Overview System first, since nothing else on the platform mattered if admins couldn't trust the underlying data
Made sure explainability and fairness, like showing why a driver got flagged and checking for bias, implemented from the beginning instead of adding it later, to ensure the data was trustworthy
Focused the Admin and CSM dashboards on the same two things: how active a driver actually is (km driven, offline time, last active) and whether they're keeping up on payments, to keep everyone on the same page
P1
Scoped in the Priority Queue View and risk scoring once the core data was solid, giving CSMs a clear way to see who to check on first
Held off on predictive risk scoring until the system could actually explain itself, since flagging a driver as "at risk" without a reason wasn't good enough
P2
Pushed the driver-facing mobile dashboard and reward system further down the roadmap, since the priority was giving admins and CSMs visibility first, before building tools for drivers
Deferred CSM messaging and CSM performance scoring, to make sure CSMs had the tools to support drivers before adding ways to message them directly
Project Considerations
This project was about the data, not just what showed up on screen. Getting the data model right mattered, since admins and CSMs were going to base real decisions about someone's livelihood on what the platform said about their activity and payment history.
Explainability had to be built in from the start, not added on later. Admins and drivers needed to see the actual reasoning behind a risk score, like which specific activity or payment pattern drove it, so internal decisions could hold up if a driver pushed back.
We were working under a tight timeline, which meant prioritization couldn't just be about what mattered most, it also had to account for what we could realistically design, build, and test in the time we had.
We were relying on Anda to provide real driver data, and delays on their end became a recurring setback. When data didn't arrive on schedule, it held up testing and validation on our side, so I had to build that risk into the roadmap instead of assuming data would show up when we needed it. We created synthetic data ourselves, generating realistic driver activity and payment patterns to train and test the model, so we weren't held back waiting on data to test from Anda.
Solution
The platform gives Anda's admins and Customer Success Managers one transparent system to track driver activity and payments, prioritize who needs support, and act on data they can trust and explain.
Designed by our product designers Tiffany Liu and Isabella Raffo
Driver Performance Overview - Score
This came out of a P0 requirement I wrote for a fully explainable performance model, admins needed to see exactly which factors made up a driver's score, not just the number itself.
Score breakdown shows the weight behind each factor: payment timeliness, hours worked, collection rate, and portfolio risk
Collection Rate and % Portfolio at Risk are shown as simple ratios (received vs. expected), so the math is never a mystery
Driver Performance Overview — Vehicle
This ties directly to the activity data requirement, giving admins a way to tell an inactive driver from one whose bike is simply parked mid-shift.
Real-time speed and engine status show what's happening right now, not just historical averages
Driving History timestamps each location, so admins can trace exactly where and when a driver was active
Designed by our product designers Tiffany Liu and Isabella Raffo
Designed by our product designers Tiffany Liu and Isabella Raffo
Driver Performance Overview — Revenue
This covers the payment side of the requirement, tracking revenue and default rate over time instead of just a current balance.
Revenue Summary and Default Rate charts make patterns visible at a glance instead of buried in a spreadsheet
Revenue Per Trip breaks earnings down trip by trip, so a balance issue can be traced back to its source
Customer Success Manager Dashboard
This is the Priority Queue view I scoped as P1, giving CSMs a ranked list of their drivers instead of digging through separate systems.
Tabs for All, Active, New, and Churn let a CSM focus on the group that matters right now
Score column surfaces risk immediately, without needing to open each driver individually
Designed by our product designers Tiffany Liu and Isabella Raffo
Designed by our product designers Tiffany Liu and Isabella Raffo
Admin Dashboard
This expands on the CSM dashboard with the full filter set I wrote into the P0 requirements, so admins can slice the whole driver base by exactly the signals that matter.
Filters for payment status, offline duration, vehicle type, and location narrow the list down in seconds
A wider column set (Payment Status, Last Active, Offline Duration) gives admins more context than a CSM needs day to day
Manage Users
This covers the user verification and role assignment requirement, letting admins control who has access and to what.
Role tags (Admin, CSM) make each user's access level clear at a glance
Drivers Assigned column shows CSM workload, so admins can rebalance if one person is overloaded
Designed by our product designers Tiffany Liu and Isabella Raffo
Takeaways
Managing a project that was development-driven, not design-driven
The UI only worked if we could actually get the data and build a model that reflected it accurately, so managing this meant staying closely tied to whether the technical side was on track, since a design without a working model behind it wouldn't function at all.
Working with a tech lead despite my own technical gaps
Working alongside a tech lead taught me how to make up for what I didn't know technically by communicating clearly and leaning on him for what I couldn't answer myself. I learned to ask better questions instead of trying to have all the answers.
Owning a project instead of just executing on one
As a designer, I'm usually the one following direction, not setting it. Being responsible for the decisions and actually owning this project was a new experience, and honestly a little scary at first, but it taught me a lot about how to guide and support the rest of the team instead of just contributing to someone else's plan.
Learning to stay flexible when things didn't go as planned
Relying on Anda for real data taught me not to just move forward assuming it would show up on time. It pushed me to get better at brainstorming backup plans early, like generating synthetic data ourselves, so the team always had somewhere to go instead of stalling every time we hit a setback.
