I design complex products that don’t feel complicated

Moneff’s mobile app serves business and personal clients across the UK and EU. Its most-used flow is the card transfer to Uzbekistan, which is also what the marketing campaign brings new users in for. In mid-2026 product came to me with a one-line brief. The UK App Store rating was 3.7, and they wanted it higher.

There were only 21 UK ratings in total, and most of the written reviews were about support speed. Nobody who had just had a good experience was ever asked to rate the app. In practice the score measured who got angry enough to write. Changing the product itself would do very little for a number like that.

• Ask for a rating right after a job well done
• Ask once, and never after a failure
• Give unhappy users a direct route to the team
• Move the rating while leaving the core product untouched

I reframed the task from “raise the rating” to “ask the right people at the right moment”. The right moment turned out to be the success screen of the Uzbekistan transfer, since that is where a completed job happens most often. The right people are defined by an eligibility rule: the account is at least 7 days old, there are two or more successful transactions, no recent errors, and the user has never been asked before. The ask itself is a light in-app question. A “yes” opens the native store prompt, and “could be better” opens a short feedback form that goes straight to the team. All of it sits as a thin layer on top of an existing screen, and nothing else in the product changed.

Danish business clients on Moneff receive money into a pooled account in the company’s name. Named IBANs for Denmark depend on a banking partner and are still on the way. Until then, matching an incoming payment to the right client relies on the sender typing a reference.

Senders forget the reference. The money sits unassigned, the client sees nothing on their balance, support gets the complaint and operations matches payments by hand. The operations team brought this to product, and product handed it to me in full. There was no brief and no spec, and the backlog of stuck payments grew every day.

• Unblock operations within days
• Leave the payment backend untouched
• Design for the one party we can reach, the recipient
• Keep room to grow once real usage shows where

I started with what I could change. The sender uses their own bank’s app, and named IBANs had a timeline nobody could promise, so neither of those was an option. Our client was the one party I could design for, and the client always knows a payment is coming. That turned the task around. Instead of making senders remember a reference, we could let the recipient tell us what to expect. Before deciding, I looked at how neighbouring fintechs handle incoming payments and talked to a small-business owner in Sweden about how she invoices. She does it from her accounting tool, and a bank app was never going to replace that. Then I ran a working session with the head of operations and our backend architect. His ideal was a proper invoicing flow, and we agreed it was the right design for the long term and the wrong next step. It meant months of backend work, it would do nothing for the payments already stuck, and it would lose most of its value once named IBANs arrived. So we planned two phases. First the smallest thing that unblocks operations this week. Then analytics on how clients use it. Then build on whatever the data shows.

Moneff is a fintech product offering multi-currency accounts and payments for businesses and individuals. The web platform had grown without a design system or shared documentation, which made it harder to maintain and slower to evolve. Internal analytics show the web is mainly a business surface: around 54% of active corporate clients used it over the past year, rising to nearly 60% recently, versus roughly 5% of individuals — so the redesign was aimed at the people who live in the product. Over the same period the platform kept growing, from roughly 1,700 to a peak of around 3,100 monthly active users.

Scaling without a design system slowed development and made releases unpredictable. The product had also moved from B2B-only to serving individuals, but the interface was still built for business users and felt complex for personal ones, driving navigation-related support tickets.

• Make the platform easier for both business and individual users
• Build a design system developers could use day to day
• Reduce support tickets caused by UI issues
• Speed up feature development without touching the backend

I started with the design system, talking to developers up front so it was realistic to implement: components, states, spacing, layout rules and usage guidelines. Before redesigning screens I reviewed flows and IA, analysed recurring support issues, ran a competitive analysis and collected technical constraints, separating UX problems from system limits. I ran usability tests on payment and card flows before implementation.

Spike is a mobile-only fintech app for traders worldwide, enabling instant transfers between crypto exchanges and fiat bank accounts in a single app. Onboarding is where users first decide whether they trust the service enough to continue.

There were no direct market equivalents, so no established patterns to lean on. The onboarding logic was complex due to multiple integrations, KYC and technical constraints, and it felt long and unclear, with a high risk of losing trust early.

• Guide users step by step through a complex process
• Reduce cognitive load during KYC, exchange linking and setup
• Build trust from the very first interaction
• Make a technically complex process feel simple and predictable

I understood the domain firsthand: I opened a crypto account myself and spoke directly with traders about their expectations and trust triggers. We defined personas and a customer journey map to locate confusion and drop-off, producing hypotheses validated later with product data. We split onboarding into progressive steps with clear guidance, prototyped in high fidelity, ran usability testing, and designed a demo tour so users could see value before committing.

Moneff wanted to test appetite for a Banking-as-a-Service offering, licensed UK and EU infrastructure for neobanks, marketplaces and embedded-finance brands, before committing engineering time.

The real question was demand. Building the product first would be slow and expensive, so we needed a real-world signal of interest quickly.

• Product and business thinking, not just screens
• Comfort moving from hypothesis to live test
• Fluency with AI tools to ship fast
• End-to-end ownership of a 0→1 experiment

I defined the value proposition and target segments, structured the full narrative (products, integration steps, architecture, why-us and FAQ), and designed and shipped a fully branded, live landing page in a single day, without developers, using AI tooling, with “Book a demo” as the conversion goal.

A mobile medical-assistant concept that helps people understand symptoms and manage care from their phone. Included to show structured product thinking outside fintech.

• User research and target-audience analysis
• Personas and customer journey mapping
• Information architecture and user flows
• Wireframes, high-fidelity UI and an interactive prototype

Figma for design and prototyping, Miro for research synthesis and mapping, and ChatGPT to pressure-test scenarios.