End-to-End Payments at tilli
[1]
I designed both the QuickPay experience and the post-login dashboard to support the full lifecycle of paying and managing invoices—from fast, one-time payments to ongoing account management—without making users think harder than they need to.
Role
UX Designer
Skills
Systems design, Payments & dashboards, Interaction & hierarchy
Timeline
Sept 2024 - Feb 2025
Tools
Figma, Linear, FigJam, Datadog
How can we design one payment system that works for both urgency and long-term management?
Users interact with tilli at different moments: some just want to pay a bill quickly, others need visibility and control over invoices and payments over time.
Without existing patterns to lean on, the challenge was deciding what needed to exist at all.
By mapping QuickPay and post-login flows end-to-end, I identified consistent hesitation points around identity verification, payment timing, status clarity, and fear of making irreversible changes.
Key insights
Needed a scalable foundation
The dashboard structure couldn’t support product growth or future flexibility.
Visual language sets expectations early
A modern system UI was critical to signal momentum and credibility.
Momentum had to be designed
Users hesitated to trust on-screen confirmations.
Users needed direction after login
The dashboard had to clearly surface what matters most, not everything at once.
I spoke with client teams, reviewed support logs, and mapped user behaviors across the payment flow.
Patterns emerged:
1
Users hesitated to trust on-screen confirmations.
2
Dashboards overwhelmed more than they guided.
3
Payment flows demanded too many steps → opposite to current online checkout portals
How do we design one payment system that supports urgency and control without forcing users to relearn behaviors or prior familiarity?
QuickPay users need speed and reassurance, while post-login users need visibility and predictability.
I designed the system from first principles, starting with user intent, not screens.
QuickPay and post-login were treated as two modes of the same system, sharing language, hierarchy, and behavior so users could build trust quickly.
This experience was designed around a single question: can a user confidently complete a payment without second-guessing themselves?
To answer that, I consolidated the entire payment flow into one primary screen—so users can review invoices, verify identity, choose a payment method, and confirm totals without losing context.
Single-screen payment flow
Invoices, totals, verification, OTP verification and payment stay in one view to prevent hesitation and loss of context.
Clear payment choice
Payment methods are shown as scannable cards so users can choose quickly and confidently.
I designed the dashboard to surface what matters now instead of everything at once.
Invoices, totals, due dates, and status are prioritized through hierarchy so users can act immediately without scanning.
Wallet
I introduced a dedicated wallet space so users can resolve payment issues ahead of checkout.
Separating payment management from payment moments reduces friction.
Expanded Invoice View
Invoice details, payment, and conversation live in one view to keep decisions focused.
Clear status at a glance
Totals, due dates, and payment status are prioritized so users know what needs action immediately.
Working with figma
This was my first project out of college, and it forced me to grow fast. Early on, I leaned too much on grouping elements in Figma instead of building clean structure with frames and components, but this project pushed me to design with intention, scalability, and systems in mind.
QuickPay and post-login needed different mindsets
One of the hardest parts was clearly separating QuickPay and post-login. I had to be intentional about why they felt different—QuickPay needed speed and reassurance, while post-login needed control, without making the product feel inconsistent.\
considering the security aspect
Security was also a real challenge. Designing a space where users can see multiple payment methods at once meant trust had to be felt, not assumed. We chose OTP as the best balance between usability and protection, but it pushed me to think more critically about how security is communicated in the UI, especially when real money is involved.