Transaction limits simplified

Project overview

I joined Zopa Bank to help launch their first current account, a zero-to-one project with high visibility across the company. Among the features I designed for launch, transaction limits turned out to be way more interesting than it sounds - showing how you can turn strict regulatory requirements into something users actually love.

Role

I owned transaction limits from research to delivery - testing with users, negotiating with compliance, and convincing the design system team we needed new components.

Key achievements

  • Created self-service solution that prevented support calls: Users could find their limit information on their app.

  • 100% of users found the final design easy to understand: Including those with characteristics of vulnerability.

  • Contributed to foundational design system patterns: Bottom sheets and card layouts that other teams now use.

  • Led without authority: Turned compliance officers from blockers into advocates.

The challenge

How might we present complex transaction limit information that prevents support calls, meets compliance requirements, and is easily understood by all users? All in time for launch 👀

The constraints made this tricky…

  • Compliance wanted technical banking language that users wouldn't understand.

  • I had to work with an outdated design system - no new components allowed.

  • Every design needed approval from compliance, copy, and brand teams who often had conflicting perspectives.

  • 20% of test participants had to have characteristics of vulnerabilities.

  • Fixed launch deadline with the whole company watching.

My Process

Documentation as a strategic tool

I created a central Miro board as a single source of truth. This proved crucial for maintaining momentum - anyone could track design evolution, rationale, and decisions without restarting conversations.

Understanding the landscape

I looked at how Zopa's credit card team handled similar flows, checked out competitor apps, and mapped all the compliance requirements and design system constraints.

Version 1

Working within constraints

The existing design components weren't great for presenting limits info. I knew the design wasn't ideal, but I needed evidence to prove it - so I tested it.

Simple text-based presentation without clear visual groupings / Small headings that made it hard to distinguish between sections / Limited contextual information about what each limit meant

Hypothesis

Users will struggle to understand limits easily, find them difficult to scan, and those with characteristics of vulnerability will find tasks overwhelming.

To validate this hypothesis, I designed a testing protocol examining:

  • Comprehension of different limit types and terminology.

  • Ease of scanning and finding specific information.

  • Understanding of complex banking concepts like "rolling limits".

Testing confirmed my concerns

Users understood the concept but struggled with the presentation. Lack of visual hierarchy made scanning difficult, banking terminology confused people, especially those with characteristics of vulnerability, and users preferred seeing remaining balances rather than total limit.

The breakthrough

Evidence-based redesign

Armed with compelling user feedback, showing real confusion, I got other designers on side and convinced the design system team we needed new components.

Card-based layout creating clear visual hierarchy / "Amount left" indicators showing remaining balances / "Learn more" links triggering bottom sheets for progressive disclosure / Clear typography hierarchy for improved scannability

  • Improved comprehension: 100% of users in the second round of testing found the design easy to understand.

  • Enhanced efficiency: Users could quickly find specific information.

  • Inclusive design wins: Users with characteristics of vulnerability showed the most significant improvements, with comprehension scores increasing from 2/5 to 5/5.

  • The "amount left" indicators became unexpected delighters: users hadn't seen this in other banking apps.

Qualitative feedback consistently praised the "clean," "simple," and "easy to digest" design.

Design system contribution

Rather than just pointing out problems, I showed how specific changes would solve real user issues.

What we added:

  • Card layouts for clearer visual separation

  • Bottom sheet for progressive disclosure

  • Clearer typography hierarchy for improved scannability

  • Grey info boxes for standard banking term descriptions

The bottom sheet component quickly became a foundational pattern that teams started using heavily.

Impact

Led without authority

Without formal authority as a contractor, I focused on winning people over through collaboration. The breakthrough was bringing compliance officers along on the whole journey - sharing specific user quotes in our sessions and showing them exactly where people got confused. Once they saw real users struggling with banking terminology, they became advocates for clearer design instead of blockers.

Business impact

  • Created self-service that prevented support calls - 100% of users could understand their limits

  • Met compliance requirements so launch could happen on time

  • Future-proofed the design so new features can build on what's there

Key learnings

Show, don't tell with stakeholders

User testing footage beats abstract arguments every time - when compliance officers saw real users struggling, debates turned into problem-solving. Good documentation kept everyone aligned and building coalitions worked way better than trying to push changes alone.

Progressive disclosure works

Layering complex information dramatically improved comprehension, especially when I used concrete examples instead of definitions. Even compliance features can have delightful moments that surprise users.

Let's create together?

amyposthilldesign@gmail.com