117 ways to pay, one set of patterns
Payments had grown method by method. The deposit redesign turned the whole ecosystem into a small set of reusable patterns, rolled out method by method across markets, and left a framework the team could extend without me.
- Hybrid
- Product Design Manager, Kaizen Gaming
- 2023, about 18 months
- 20+ regulated markets
My role
Hybrid · Product Design Manager, Kaizen Gaming. I initiated the redesign, created the mapping and defined the initial architecture with the designers on the team. As Payments matured, two dedicated designers continued evolving it under my direction. The resulting patterns and Figma architecture became a shared framework that reduced dependency on individual knowledge.
117
- withdrawal methods
- 75
- providers mapped
- 41
A product area still finding its shape
When I joined Kaizen, one of the broad asks was to "redesign My Account", often understood as a visual refresh. Payments sat next to Account and was still maturing as a product area, without a settled structure or ownership model. Design initiated the deposit redesign, and the first phase was implemented with the technical teams supporting My Account. By the time Payments matured and took full ownership, the direction had already been defined and presented to senior leadership.
Designing for methods nobody had listed
There was no single source showing which payment methods existed in which markets, how they behaved, or what limits and requirements applied. And the methods behaved very differently: redirects to external environments, approval inside another app, linked and unlinked accounts, saved payment details, asynchronous confirmation, QR codes and cash settlement, each with its own limits and validation. Designing each method on its own would never scale across 20+ markets with new methods arriving all the time.
Four decisions that shaped the redesign
- Map the ecosystem before designing anything
- Design behaviors, not methods
- Roll out by method, not by market
- Improve the experience inside the legacy architecture
Map the ecosystem before designing anything. I created a map of the payment landscape across countries: 117 deposit methods, 75 withdrawal methods and 41 providers, with availability, limits, requirements and behavior. It showed which methods had the broadest use and which behaviors kept repeating.
Design behaviors, not methods. The map made it possible to stop treating methods as dozens of unrelated designs and decompose them into reusable capabilities and flows. A new method became a combination of patterns the system already knew how to support.
Roll out by method, not by market. Redesigning one market completely would have given perfect consistency there and very little reach elsewhere. I proposed the opposite: redesign the most widely used methods first. We accepted a temporary inconsistency, where a market could show two redesigned methods next to three legacy ones, because every redesigned method improved several markets at once.
Improve the experience inside the legacy architecture. A full cashier rebuild was not realistic, technically or organizationally. The deposit flow kept roughly three steps; the gains came from what happened inside them: clearer hierarchy, reduced clutter, better contextual information, consistent method behaviors, better failure handling, and a system that could scale across markets.
Don't make customers understand the entire payments system in order to make a deposit.
- Before: everything at one level
- After: one question at a time
- A method step, built from shared patterns
- Failure handling, with a way forward
The second system: the Figma architecture
Payment methods were organized alphabetically, with a dedicated section documenting the reusable patterns behind them; each method referenced those patterns instead of standing alone. Deliberate choices set which screens, states and responsive variations were maintained, the minimum structure a designer needed to understand, extend and maintain the ecosystem. New designers could learn the patterns first, find the method, and work inside an established structure.
Validation
Before designing, we defined the qualities the deposit should communicate, among them clear, easy and trustworthy. At the end of usability sessions, participants chose words to describe the experience from a list that mixed those goals with other attributes, without knowing which were ours. The words they consistently chose matched the principles we had set. There was no reliable baseline for the legacy experience, so this is qualitative validation, not a measured improvement.
After the first redesigned methods went live, Customer Support reported that support requests for some of the highest-volume methods, including card payments, dropped noticeably.
What changed
The payments designers and teams kept working from the same patterns. Nobody had to re-justify why one method behaved differently from another, and the work no longer depended on one designer remembering every provider. Later payments initiatives built on this foundation; withdrawals and faster deposit experiences followed as separate work.
- 20+
- 2
Reflection
The meaningful part was not the redesigned deposit on its own. It was creating enough structure that the work could scale without continuing to depend on the person who first designed it.