Edu Fintech
Designing a role-based education-financing platform for parents, schools, investors and operations.
At a glance
Parents, schools, investors and operations
User interviews, plus 12 stakeholder sessions
One journey from admission to tracking
The problem
The core issue was uncertainty, not the loan. Early dashboards mirrored the database, so every user dug through fields for answers. Parents, schools, investors and operations each asked different questions across a seven-step journey.
What I changed
With 24 interviews, 12 stakeholder sessions, 8 competitive reviews and a service blueprint, I designed each role around its first question. Parents get status and next action first, schools get dense filterable lists with exceptions surfaced, and investors get schedules and fund allocation by scheme.
The detail
Complexity is hidden, not information: detail stays one tap away. Failure flows cover blurry documents, verification mismatches, API timeouts, failed underwriting and failed payments, and each one says what happened, what the user can do and whether progress is saved.
What I learned. Designing each role around its first question turned one complex system into four simpler experiences.
What happened
Four role-based experiences on one data layer, four information hierarchies and a token-based shared design system. The North Star is on-time repayment rate, with completion, approval time and first-pass verification to validate after launch.
Full case study
The complete story
Overview
One platform, four jobs
Education financing works only when everyone trusts it. Investors supply capital, schools enrol students into financing schemes, parents repay in instalments, and operations keep it safe. I led product design for one shared data layer with a dedicated experience for each role.
Problem
The core issue was uncertainty, not the loan
| Role | What they ask |
|---|---|
| Parents | How much do I pay, what's next, am I approved, when does money move? |
| Schools | Which students are financed, what's paid, what needs attention? |
| Investors | Where is my capital, and what are the returns? |
| Operations | Is everything working? |
Early dashboards mirrored the database, so every role had to dig for answers.
Goals
What success looks like
- More families complete financing
- Faster approval and fewer document failures
- On-time repayment (the North Star)
- Less support load and faster school operations
- More self-serve investor reporting
Discovery
24 interviews, 12 stakeholder sessions, 8 platforms
- Parents needed reassurance: anxiety peaked around approval, disbursement and the next payment.
- Schools needed speed: admins handle many students at once and need status and exceptions, not detail.
- Complexity couldn't be removed: loan structures, schedules and risk rules are real, so the product must carry them.
I also mapped people, systems and handoffs in a service blueprint.
Strategy
Three principles behind every screen
- Hide complexity, not information. Detail stays one tap away.
- Start with the user's question, not the available data.
- Shared data, role-specific hierarchy. No single dashboard for everyone.
| Area | Chose | Over |
|---|---|---|
| Dashboards | Four role-specific views | One configurable dashboard |
| Parent home | Status and next action first | Full loan detail |
| School view | Dense, filterable lists with exceptions surfaced | Card summaries |
| Consistency | Shared patterns and components | Independent designs per role |
Experiences
Four role-based experiences
| Role | First question | Highlights |
|---|---|---|
| Parent | Where do I stand? | Repayment timeline, loan summary, transactions, agreement access, one-tap actions |
| School | What needs my attention? | Disbursement status, student and fee management, requests, class filters |
| Investor | Where is my capital? | Repayment schedule, fund allocation by scheme, reports |
| Operations | Is everything working? | Monitoring of users, transactions and exceptions |
Edge cases
Failure states are core flows
| Failure | Response |
|---|---|
| Blurry document | Explain, show an example, re-upload in place |
| Verification mismatch | Show the failing field and how to fix it |
| API timeout | Auto-retry, save progress, notify the user |
| Network failure | Keep entered data and resume |
| Failed underwriting | Clear reason and next steps |
| Failed payment | Status for parent and school, with retry |
Every failure answers three questions: what happened, what can I do now, and is my progress saved?
Leadership
How I led
- Experience direction across four roles and the key journeys
- Product strategy: decisions, not database fields
- Design system: shared, token-based patterns and components
- Team: directed and reviewed two designers
- Stakeholders: aligned business, risk and operations
Impact & next steps
Confirmed scope, measured after launch
- 4 role-based experiences on one platform
- 2 months, 3 designers
- A 7-stage financing journey
- Shared token-based design system
Next: test whether repayment, APR and fees are understood on first read, test failure recovery and accessibility under pressure, and instrument drop-off at each step.
Have a problem like this?
Tell me what is slowing your team down and I will reply within a day.
Next case study
SaleMate
Connecting property buyers and sellers directly, with services, auctions and paperwork in one place and no brokers in the middle.
