Oluwatosin Kazeem

Our research was structured around five key questions:

Speed mattered, but it was not the primary issue. Most participants accepted that international payments might take a few days. Their greater frustration came from the uncertainty surrounding those payments, when funds would arrive, whether additional verification would be required, and whether their accounts might suddenly become restricted.

Existing providers had created a trust gap. Several participants described situations where funds had been temporarily held or accounts restricted without clear explanations. From their perspective, they had little visibility into what was happening and almost no control over resolving the issue.

The barrier to crypto was not technical complexity. Most participants had heard of Bitcoin, but very few understood the difference between Bitcoin and stablecoins. Cryptocurrency was often perceived as volatile, speculative, and unsuitable for receiving salaries or client payments. Even after explaining that stablecoins held a value equivalent to the US dollar, several remained concerned that the value of their funds could change overnight.

These conversations highlighted an important distinction. Users were not rejecting cryptocurrency because they disliked the technology. They were rejecting the uncertainty they associated with it.

Before beginning the research, I had assumed most users possessed at least a basic understanding of cryptocurrency. Having worked with cryptocurrency myself, I underestimated how unfamiliar stablecoins were to the average user.

The interviews challenged this almost immediately. Most participants recognised Bitcoin because of its media exposure but had little understanding of cryptocurrency beyond that. Stablecoins, blockchain networks, wallets, and digital assets were largely unfamiliar concepts.

Initially, I believed the interface needed to educate users about cryptocurrency. After the interviews, it became clear that education alone would not solve the problem. The product needed to minimise the amount of cryptocurrency knowledge required to complete everyday tasks. This shift in thinking became one of the defining principles of the project.

At the conclusion of the research phase, we reframed the problem. We were not designing a platform for experienced cryptocurrency users. We were designing a financial product for people who simply wanted to receive their money faster, spend it with confidence, and avoid the complexity traditionally associated with digital assets. Every interaction was then evaluated against a single question:

By the end of the discovery phase, several insights had become clear:

Rather than building every feature discussed during planning, we deliberately narrowed the scope of the first release around three core user journeys:

Every feature considered for the MVP had to strengthen one of these journeys. This meant intentionally delaying features such as Polymarket, investment products, and “Earn” functionality. While these aligned with the company’s long-term vision, they introduced complexity at a stage where our primary objective was to establish trust.

One of the most significant product decisions I influenced was reducing the number of supported stablecoins. Early explorations included multiple options such as USDC and USDT. From a technical perspective, supporting multiple assets offered greater flexibility. From a user experience perspective, it created an unnecessary decision before users had even completed their first transaction.

The research had already shown that many participants struggled to distinguish between cryptocurrencies. Asking them to choose between several stablecoins would have increased uncertainty rather than confidence, so I proposed supporting a single stablecoin during the initial release.

The decision to support only USDC was not driven by technical limitations. It was a deliberate product strategy intended to reduce cognitive load and improve adoption.

Financial products often overwhelm users by presenting every option simultaneously. During research, we repeatedly observed that users became less confident whenever they encountered unfamiliar terminology or excessive information.

Rather than displaying every option upfront, information was introduced only when it became relevant to the user’s current task. During transfers, users first selected the destination country before being asked for recipient details, so the interface displayed only what that specific transaction required. The same thinking influenced onboarding, wallet management, and transaction history, and it became one of the defining interaction patterns across the product.

By the end of the strategy phase, several principles had become embedded in the product:

My design process rarely begins in Figma. I start by writing, using pen and paper to organise ideas, break down user journeys, and understand how the parts of the product relate before thinking about layouts. In an early-stage startup this lets me explore multiple directions quickly without becoming attached to a particular interface. Once I understood the structure, I translated the ideas into low-fidelity wireframes focused on hierarchy and flow, and then into interactive Figma prototypes so the team could evaluate complete journeys before development began.

Four principles guided my decisions throughout the project:

The product relied on multiple third-party providers for identity verification, virtual cards, payment processing, and compliance. Rather than exposing the boundaries between them, I designed around user goals instead of technical architecture. From the user’s perspective they were not using several independent services, they were using SpendFigo, which required consistent navigation, unified interaction patterns, and a shared visual language across features powered by completely different backend systems.

The home screen became one of the most iterated parts of the product. Early explorations supported multiple stablecoins, with dropdowns, balance selectors, and extra navigation. After the decision to support only USDC, I revisited it entirely and focused on four things:

Everything else became secondary. Removing unnecessary options created a calmer interface and let users understand the product almost immediately, a clear example of a strategic product decision directly improving the experience.

Initially I designed the transfer flow so users entered the amount before recipient information, reflecting how people naturally think about payments. During implementation, engineers identified that changing the destination country after entering an amount triggered repeated exchange-rate requests. Rather than defending the original design, we restructured the flow so users first selected the destination and recipient, letting the system calculate rates once. The final solution differed from my proposal but created a smoother experience, reinforcing that engineering is a design partner, not just an implementation team.

Very few screens remained unchanged from their first version. I explored multiple alternatives for navigation, onboarding, wallet management, and transfers, refined through internal reviews, engineering discussions, and prototype testing. I treated iteration not as correcting mistakes but as a natural part of development, each version representing a better understanding of the problem than the one before.

After months of research, definition, and engineering collaboration, we released the first version of SpendFigo. The objective was not a complete financial ecosystem but validating whether users could complete the three journeys that had shaped the product: onboarding, funding their wallet, and sending or receiving money.

Within the first months, the platform processed more than $1 million USD in transactions and attracted more than 1,000 users, demonstrating genuine demand for a product that simplified international payments using stablecoins. The launch also exposed weaknesses, which I treated as the beginning of a new cycle of learning rather than the end of the design process.

The most significant issue appeared during onboarding. Although interest was strong, a large percentage of users abandoned account setup, with initial data suggesting a drop-off rate of approximately 80%.

Rather than assuming the flow was simply too long, I combined analytics with customer support conversations and our earlier research. A consistent pattern emerged: users were not unwilling to complete verification, they questioned why so much information was required before they had experienced any value. The problem was not compliance itself. It was timing.

Rather than removing compliance, I distributed parts of the process throughout the product journey. Users could create an account, explore the interface, and complete additional verification only when it became necessary for specific activities. This aligned with progressive disclosure and respected how trust develops: people are more willing to share sensitive information after experiencing value than before. Following implementation, onboarding drop-off fell from over 80% to under 52%, one of the clearest examples of design improving business outcomes by addressing user psychology rather than simply reducing the number of screens.

In a small team, support conversations became ongoing research. I treated tickets as indicators of where the product failed to communicate clearly. Users struggled with certain verification steps and were confused when separate wallets were introduced for card functionality. Rather than exposing more technical detail, I improved communication within the interface, instructional copy, empty states, contextual guidance, and clearer transaction statuses. In financial products, every confirmation message can increase or reduce confidence.

By this stage, success was measured through product metrics, user behaviour, and operational outcomes rather than visual quality alone:

The most influential decision I contributed to was reducing the number of supported stablecoins. Early discussions considered USDC and USDT, but research showed most participants struggled to distinguish between cryptocurrencies. Rather than asking users to compare assets they did not understand, I recommended a single stablecoin for the MVP. We moved forward with USDC, which removed unnecessary choices, simplified the interface, reduced support complexity, and reinforced our goal of making stablecoins feel as familiar as traditional money.

Financial products cannot avoid identity verification, but they can decide when and how it is introduced. Our initial onboarding requested extensive verification before users could meaningfully interact with the platform. Rather than reducing requirements, I changed their placement, introducing verification progressively as users reached activities that needed it. The redesign significantly reduced onboarding drop-off and reinforced that compliance is an experience-design challenge, not only a regulatory one.

One responsibility I valued most was helping decide what should not be in the first release. As the roadmap expanded to include Polymarket and other earning features, I was concerned that introducing speculative products before establishing trust would reinforce exactly the volatility concerns users already had. I recommended focusing first on the fundamentals, receiving, transferring, and spending, and introducing advanced products later, once users trusted the platform. A successful MVP is defined by what it deliberately excludes.

As the product grew, I developed and maintained a design system that standardised components, interaction patterns, spacing, typography, colour, and feedback states, reducing inconsistencies and improving communication with engineering. When additional designers joined, I introduced them to the component library and the reasoning behind it, helping them contribute effectively and maintain consistency as the product evolved.

Before SpendFigo, I thought of product design as creating interfaces that solved user problems. The project broadened that view. Designers influence outcomes long before pixels appear on a screen; every conversation about priorities, scope, constraints, and user psychology shapes the experience. Now I begin not with “how should this feature look?” but “should this feature exist, and if so, how can we make it as understandable as possible?”

In many applications, users recover easily from mistakes. Financial products are different: users make decisions with their own money, and every interaction carries more responsibility. This changed the questions I asked of each design:

Before SpendFigo, I often thought of research as confirming whether an idea was good. The purpose of research is not to prove we are right; it is to discover where we are wrong before users do. My assumption that most users understood cryptocurrency was overturned almost immediately, and had we designed around it, we would have introduced unnecessary complexity.

Several of the strongest decisions emerged because technical constraints forced us to rethink initial ideas. The transfer flow is the clearest example: engineering identified performance implications, and redesigning together improved both system performance and user experience. I now view engineering constraints as opportunities rather than limitations.

Onboarding was one of the first, and most critical, interactions users had with SpendFigo. Unlike social or productivity apps, financial onboarding must satisfy regulatory requirements while earning trust, and those objectives often conflict: compliance requires collecting personal information, but users are reluctant to share it before understanding a product’s value.

The initial flow followed a common structure: users created an account and were immediately asked to complete several verification steps before accessing the platform. It was clean and compliant, but after launch a large proportion of users abandoned onboarding, and support began receiving questions about why so much information was required upfront. We had behavioural data confirming onboarding had become a barrier rather than an introduction.

Rather than assuming the fix was a shorter flow, I reviewed analytics alongside support conversations and the earlier interviews. Users did not object to verification itself, the issue was its timing. They had not yet seen enough of the product to justify providing extensive personal information, and many read the number of fields as a signal the process would only get more complicated.

The solution followed progressive disclosure. Instead of concentrating every requirement at the beginning, I distributed verification across the product. Users could create an account, familiarise themselves with the interface, and complete additional verification only when it became necessary for higher-risk activities. Restructuring onboarding required close work with compliance, who ensured obligations were met, and engineering, who determined how verification could be triggered dynamically based on activity. After implementation, drop-off fell from over 80% to under 52%, and the pattern later influenced transfers, card management, and AI interactions.

The home screen is the most visited screen in any financial product, and it became one of the most iterated in SpendFigo. Early explorations reflected a multi-stablecoin vision, with asset selectors, additional balances, and more navigation. These layouts worked functionally but demanded too many decisions before users could perform their primary tasks, conflicting with everything research had told us.

Whenever a design became too complicated, I returned to a simple question: why is the user opening the app? The answer was consistent, most users wanted to do one of four things:

Everything else was secondary. I treated the home screen as a workspace centred on users’ most frequent actions rather than a navigation hub for every feature.

Once we supported only a single stablecoin, the dashboard became far easier to simplify. The asset selector disappeared, the balance could occupy a single prominent position, and Send and Receive became the strongest elements beneath it. Recent transactions sat immediately below, so users could verify activity without navigating elsewhere. The hierarchy let users understand the app within seconds of opening it.

One unconventional decision was exploring a version without a traditional bottom navigation bar. Our scope was deliberately narrow, most activity revolved around receiving, sending, and reviewing transactions, so persistent navigation risked adding visual complexity without proportional value. Navigation should reflect user behaviour, not future ambitions; we designed for the product users actually had rather than the one we hoped to build later.

I treated confidence as more valuable than information density. A user should never have to pause and ask where to send money, which balance they are viewing, or what to do next, so every element was arranged by user priority rather than business priority. At the same time, I built the dashboard from modular sections that could be expanded, replaced, or reordered as cards, AI banking, and other services matured, balancing immediate simplicity with long-term scalability.

Most people begin with a simple intention, “I want to send €100 to someone,” and rarely think about exchange rates, settlement providers, or blockchain networks. Those are implementation details that belong to the system, not the user. I wanted the transfer flow to feel like a conversation rather than a form, with each step answering one question before introducing the next.

My initial design asked how much users wanted to send before recipient details, which felt natural. But live exchange-rate calculations depended on the destination, so changing countries after entering an amount forced repeated backend requests. Rather than defending the design, I wanted to understand the constraint, and that conversation led to a better solution.

We reordered the experience so users selected the destination country and entered recipient information before specifying the amount. The application could then calculate exchange rates once, users experienced fewer delays, and the review screen reflected the correct destination from the beginning. Though it differed from my original proposal, it created a smoother experience while reducing technical complexity, and remains one of my favourite examples of design and engineering improving a product together.

International transfers require different information depending on the receiving country, so I applied progressive disclosure: users selected the destination first, and the interface displayed only the fields required for that destination. Because research showed users feared hidden fees more than fees themselves, the review screen made everything visible before confirmation:

Rather than relying on validation after submission, I designed the flow to prevent mistakes before they occurred, through country-specific fields, contextual helper text, real-time validation, confirmation screens, and clear recipient summaries. Instead of designing error messages, I focused on experiences that made errors less likely in the first place.

Traditional banking apps require users to learn where features are located before completing a task. The assistant explored a different model, instead of asking users to learn the product, the product would understand the user. A request such as “Send $200 to John” could become the starting point of a transaction. The challenge was designing a conversation that remained both efficient and trustworthy.

One principle shaped everything: the assistant should never make assumptions when money is involved. Unlike a general chatbot, a financial assistant must verify before acting. Rather than executing requests immediately, it summarised each transaction before asking the user to approve it:

Only after users reviewed and confirmed these details would the transaction proceed, increasing confidence without making the interaction feel slow.

The assistant needed to feel faster than the traditional interface, but financial products cannot sacrifice clarity for speed; whenever these conflicted, I chose trust. I also prioritised transparency, if the assistant requested extra information, for example because a destination required additional recipient details, it explained why before asking. This kept the experience conversational and let the assistant act as a guide rather than redirecting users to unrelated screens.

Although conversation was primary, visual design remained important: system responses had to be distinguishable from user input, financial summaries needed stronger hierarchy than conversational text, and quick actions reduced typing. This was one of the most iterative parts of the project, and it introduced me to conversation design as a discipline in its own right.

In a startup, features are designed and developed simultaneously and priorities change quickly. Without a shared system, every new feature risked introducing different button styles, inconsistent spacing, or conflicting patterns, small issues that accumulate into design and development debt. A design system let the team solve these problems before they became technical debt.

Rather than starting with complex components, I began with the foundations every interface depended on:

Because the product handled sensitive financial information, I paid particular attention to readability and accessibility, relying on typography and spacing rather than decoration so users could scan financial information quickly and accurately.

On top of the foundations, I built reusable components, buttons, inputs, dropdowns, bottom sheets, cards, navigation, toasts, empty states, loading indicators, success and error states, and confirmation modals, each with variants defined early so engineering could implement them consistently. I also established consistent interaction patterns: primary actions in predictable locations, distinct destructive actions, uniform success and loading states, and confirmation screens that always summarised important financial information before an action completed.

A design system is only valuable if others can use it. I organised the Figma files so components, flows, and explorations were clearly separated, and accompanied major flows with interactive prototypes to communicate behaviour static screens could not. When additional designers joined, I walked them through the component library and its reasoning, reducing onboarding time and maintaining consistency as more contributors became involved.

Before release, we established indicators to evaluate whether the product was moving in the right direction. Beyond adoption, transaction volume, and user growth, we focused on behavioural signals:

Metrics become far more valuable when paired with conversations. Analytics can identify where users leave but rarely explain why, so I regularly combined behavioural data with support conversations and direct feedback. When a metric changed unexpectedly, I tried to understand what users were experiencing at that moment rather than jumping straight to a design fix, which helped us address underlying problems instead of symptoms.

Users were willing to complete compliance when they understood its value, the challenge was introducing it at the right moment. Transparency significantly influenced confidence, whenever fees, rates, or progress were clearly communicated, users trusted the platform more, while uncertainty generated support requests even when the system worked correctly. Above all, users cared more about predictability than complexity.

Within the first months, the platform attracted more than 1,000 users and processed over $1 million USD, alongside multiple releases expanding beyond the initial MVP. Not everything matched expectations: the first onboarding performed worse than anticipated, some investment features were delayed by regulatory and technical complexity, and the card experience introduced complexity because the provider required a separate wallet. I treated each of these as research for future decisions rather than failures.

In an early-stage startup, I had direct access to the founder, discussing product decisions almost daily through stand-ups, Slack, and design reviews. Our conversations rarely focused on visual design alone, instead asking whether we were solving the right problem, whether something increased or reduced trust, and whether it was the right feature to build now. The decision to support a single stablecoin came directly from these discussions, extending beyond interface design into product strategy.

My relationship with engineering was based on conversation rather than handoff; engineers reviewed prototypes before writing code, and I reviewed implemented features. The transfer-flow redesign is the strongest example. Compliance introduced a different perspective, focused on regulation and legal obligation, and rather than framing design against compliance, we identified moments where verification could occur without compromising requirements, producing a significantly better onboarding experience.

Customer support became one of my most valuable research partners after launch, revealing where the product failed to communicate clearly, often before users reached out for help. As the product matured, part of my responsibility shifted to helping others understand how it had been designed, introducing new designers to the system and, importantly, the shared decisions behind it. Design systems are not only collections of components, they are collections of shared decisions.

Before opening Figma, I spend time understanding the problem, usually starting with writing. Pen and paper let me organise ideas, identify assumptions, and break complex systems into smaller parts, slowing my thinking just enough to challenge my assumptions before I become attached to a solution. Several of SpendFigo’s strongest decisions came from understanding behaviour rather than designing more screens.

People often associate simplicity with visual minimalism. I see it differently, it begins with deciding what should not exist: one stablecoin instead of several, delaying investment features, removing unnecessary navigation, showing only what is required at each moment. These were product decisions, not visual ones. The interface became simpler because the product became simpler.

Trust is rarely created by branding alone. It is created through hundreds of small interactions, showing the exchange rate before confirming a payment, explaining why verification is required, providing immediate feedback, using clear language, and confirming financial actions before executing them. Since SpendFigo, I ask of every product: what information does the user need to feel confident making this decision?

Restructuring compliance reduced drop-off significantly, but I would now design onboarding around progressive milestones rather than compliance stages. Instead of presenting verification as a requirement, I would frame it as unlocking capabilities, each step explaining why it exists and what it enables, with a stronger sense of progress so users feel they are activating their account rather than completing regulatory tasks.

Motion played a small role during the project, since our focus was on reliable, understandable journeys. Today I would use purposeful motion to improve communication, not just polish:

Many users understood Bitcoin but little about stablecoins; at the time we addressed this mainly through newsletters. Today I would integrate education directly into the product, explaining a stablecoin the first time a user receives one, clarifying exchange rates during transfers, and introducing concepts progressively. I would also evolve the AI assistant from a conversational interface into a proactive financial companion, explaining spending patterns, summarising activity, and answering questions about transactions, while always keeping explicit confirmation before any financial action.

Before SpendFigo, I measured success largely by the quality of the interface. Today I evaluate the quality of the decisions behind it, did we solve the right problem, remove unnecessary complexity, understand our users before designing for them, collaborate effectively, and improve the product after launch? The interface is only one expression of a larger system involving strategy, behaviour, engineering, regulation, communication, and trust.

During my time at SpendFigo I:

The most valuable outcome was not the numbers, but learning how to build products that balance user needs, business objectives, and technical realities without losing sight of the people using them.