Redesigning Root by Sudo

Root by Sudo had reached an inflection point. The business was ready to scale but the product was not built to support that ambition. What had been acceptable friction at small scale had become a serious liability. The problems were not isolated; they were systemic, cutting across usability, product architecture, performance, and trust.

Working with Customer Support and Technical Support teams, I conducted a structured analysis of the accumulated backlog of user complaints. Complaints were categorised by type (usability confusion, feature discoverability, transactional errors, and trust concerns) and mapped to specific product surfaces to identify where the product was failing most severely.

I recruited a focused group of active Root users for in-depth interviews, selecting participants who used the application regularly and had direct experience with its most friction-heavy flows. Sessions were structured around three areas: the onboarding and first-use experience, core transactional flows, and overall perception of product trustworthiness.

I conducted structured interviews with the CEO, COO, Head of Business, and a Technical Support representative to understand the business's strategic direction, internal pain points, and the constraints that would shape the design approach. Stakeholders provided a confidential product brief outlining scaling ambitions and commercial priorities.

I conducted a full end-to-end heuristic evaluation of the existing Root application across four primary surfaces: Onboarding, Card Home Page, Card Creation, and Card Management.

The broken post-onboarding experience was the highest-priority problem. Users were completing a multi-step compliance journey, arriving at the home screen, and having no idea what to do. The product offered no reward for completion, no direction, and no momentum.

The decision to invest in custom illustration was a deliberate one. Users interacting with a financial product are, at various points, anxious, uncertain, or simply looking for reassurance that the system has understood them. A well-crafted illustration at the right moment does something a status message cannot: it signals care.

Funding a card and withdrawing money were two of the most complained-about features, both overcomplicated and confusing to use. Both app store reviews and the complaint backlog confirmed it. The redesign introduces clarity when funding and withdrawing with all fees spelt out clearly.

A major source of user confusion was the inability to distinguish between Card Account transactions and Settlement Account transactions. Both appeared in a single undifferentiated list: no labels, no hierarchy, no filters. The redesign introduced a clear structural separation between account types, with distinct views, labelling, and transaction categorisation. Filters by date, type, and status were added for power users.

One of the most significant new features introduced was an in-app transaction dispute mechanism. Previously, users experiencing an incorrect charge or suspected fraud had no structured in-app recourse. They had to call support, often without resolution. I led the initiative to design a dispute flow allowing users to flag transactions, select a category, provide evidence, and submit a structured request, reducing unstructured support contacts significantly.

One of the clearest symptoms of a broken information architecture is when users cannot find features they know exist. Before the redesign, core card management capabilities were buried, inconsistently placed, or entirely absent from the surfaces where users expected to find them. The Freeze Card toggle, card channel controls, PIN management, and account statement access all lived in locations that did not reflect how users think about managing a card.

Before the redesign, account-level settings were scattered with no logical grouping and no clear owner. Users who wanted to manage their bank accounts, update notification preferences, or track a physical card order had no reliable place to look. The profile page was an afterthought, not a destination. A well-structured profile page reduces misdirected support contacts and gives users a sense of control over their account.

With four senior stakeholders involved, alignment required deliberate effort. Disagreements arose around pace of change (simultaneous vs. phased launch), the default card strategy (requiring commercial commitment), and scope of the dispute flow. My approach to every disagreement was the same: return to the evidence. Every design decision presented to stakeholders was anchored in specific complaint data, user research findings, or drop-off analytics. Evidence, not opinion, was the currency of every alignment conversation.

The app performance issues were fundamentally technical, but a designer who ignores performance is designing in a vacuum. I worked closely with engineering to ensure redesigned flows were architected to avoid new performance burdens, flagging optimised asset sizes, lazy-loading patterns for transaction histories, and streamlined screen transitions at handoff.

The redesign launched to the full user base and the results were swift, measurable, and cross-functional. Outcomes below represent directional figures based on post-launch monitoring, confirmed by Customer Support, analytics review, and app store data.

Customer support staff reported an immediate change in the nature of inbound contacts. Users were no longer calling to ask how to fund a card or link an account. App store reviews shifted in both tone and content, with users specifically citing improved onboarding clarity, ease of card creation, and a cleaner transaction view. For several reviewers, the redesigned product felt like "a completely different app", which, architecturally and experientially, it was.

Timeline pressure made it tempting to move quickly from research to implementation. In hindsight, at least one structured usability testing round on mid-fidelity prototypes, especially for the post-onboarding flow, would have surfaced edge cases before they reached engineering.