31% → 49% after the allocation redesign.
Redesigning
NAVIT’s mobility platform
NAVIT helps companies offer mobility benefits like public transport, mobility budgets, reimbursements, Deutschlandticket, and bike leasing.
When I joined, the platform had a clarity problem on both sides: employees struggled to understand what they had and how to use it, while HR and operations teams had to manage complex policies, reimbursements, payments, and benefit rules behind the scenes.
Over 2.5 years, I worked across the employee app, HR/admin dashboard, and design foundations to make the platform easier to understand, operate, and extend.
Impact
- 31% → 49%
multi-product activation
- −50%
support tickets for allocation & purchase history
- 30–50%
faster design-dev iteration
- +90%
user adoption by 2025
Support tickets related to the reimbursement modal dropped by roughly 50% over time.
Shared Figma/MUI foundations reduced design-dev iteration time by 30–50%.
Adoption rose to about 90% by 2025, measured by users signing up within 1–2 months of employer implementation and making at least one purchase.
Context
NAVIT’s product was powerful, but difficult to understand. Each employer could configure mobility benefits differently: public transport, shared mobility, reimbursements, bike leasing, mobility cards, and later Deutschlandticket.
The employee app needed to explain what each user had, how their budget could be used, and when changes would take effect. The dashboard needed to help HR and operations teams configure and manage those same rules. When either side was unclear, Support had to explain basic product logic the interface should have made visible.
One issue was especially important: the app presented different benefits as if they behaved like prepaid cards. That created false expectations. Users assumed every product worked the same way, even when the underlying rules, timing, and operational handling were different.
The challenge
How do you make complex employer-provided mobility benefits feel understandable from the first interaction?
Users needed to answer practical questions:
- What benefits do I have?
- What can I use my budget for?
- What happens if I change my allocation?
- What balance is available, used, or changing next month?
- Why does one product behave differently from another?
The work had to solve this without simplifying away the real business logic: employer policies, tax rules, product limitations, reimbursement states, monthly budget cycles, payroll-related workflows, and operational constraints.
My role
I led UX and product design across core app flows, dashboard workflows, and shared design foundations focusing on:
- Evaluating the existing app, onboarding, and allocation flows.
- Running lightweight usability tests and using Support/CS feedback to identify recurring confusion.
- Redesigning onboarding, budget allocation, transaction history, reimbursement states, and balance logic.
- Designing major product launches such as Deutschlandticket and Bike Leasing.
- Improving HR/admin dashboard workflows for benefit configuration, reimbursements, payments, payroll-related tasks, and reporting.
- Building shared design foundations with a junior designer and Engineering, including Figma/MUI alignment.
- Creating a lightweight feedback loop between Product, Support, Customer Success, and users.
Key decision 1
Onboarding: show the benefit before configuration
The old onboarding mixed education, setup, and product selection too early. Users were asked to make choices before they understood what their employer provided or which product rules applied.
I reworked the activation flow so users first saw their available mobility budget and what it could be used for. Then they were guided into allocation.
Key decision 2
Remove the credit card metaphor
The app used a credit card metaphor across different benefits. This made products feel equal, even when they worked differently.
That created the wrong mental model. A user might assume that public transport, reimbursements, bike leasing, and mobility cards all behaved like a prepaid card. In reality, each product had different rules, timing, reimbursement states, and operational constraints.
I moved the experience away from one generic card metaphor and toward product-specific logic.
Key decision 3
Make budget changes predictable
Users did not understand what happened when they changed their budget allocation. They were unsure what was active now, what would change next month, and why the numbers looked different across the app.
I redesigned allocation around state logic: what is active now, what changes next month, and how those changes should be confirmed.
The new flow separated current and upcoming states, and added confirmation screens and inline policy reminders so users understood when changes took effect.
Key decision 4
Clarify balances and transaction history
Users told Support they did not understand whether a number showed what they had left, what they had received, or what they had already used.
I restructured balance and transaction history around clearer financial states: available, used, added, spent, reimbursed, and upcoming changes.
Key decision 5
Build design systems foundations
As NAVIT expanded, one-off UI patterns became harder to maintain. New products like Deutschlandticket, eBike subscriptions, and Bike Leasing added more rules, more states, and more edge cases.
Together with Product Designer Afra Saneinejad and Engineering, I helped create NAVIT’s first shared Figma library and align components with MUI implementation. The goal was not only visual consistency, but reusable patterns for repeated states, product rules, and handoff.
Extending the logic into HR/admin workflows
The same complexity existed on the admin side. HR and operations teams needed to configure policies, manage benefit tiers, review reimbursements, handle payment and payroll-related workflows, and understand reporting.
I improved dashboard workflows that made those operational tasks clearer and more consistent with the employee experience.
This mattered because every employee-facing benefit had an admin-side counterpart: policy setup, budget rules, reimbursement handling, payment logic, reporting, and support resolution.
What we could not solve
Some limitations were outside design control.
Users could not add post-tax money to their NAVIT card because of legal and tax constraints. That meant some budgets still went unused, even when the interface was clearer.
The team also lacked reliable in-app behavioral tracking for much of the work. Validation relied more heavily on interviews, usability testing, NPS, Support data, Customer Success feedback, and design QA.
What I would improve next
If I were continuing the work, I would focus on:
- Better in-app behavioral tracking for onboarding, allocation, and transaction history.
- More granular visibility into where users drop off before first purchase or second product activation.
- Stronger product-specific education for complex benefits like bike leasing and reimbursements.
- Continued dashboard simplification for HR admins managing policies and exceptions.
- More structured experimentation around language, policy reminders, and budget explanations.