Case study, SmartSubs, Freelance, 2024
SmartSubs: Making subscription chaos manageable
A freelance iOS design project. I was brought in as the sole designer on a ten-week brief, working alongside the client's PM and development team. Most people have no clear idea what they're spending on subscriptions each month until something unexpected hits their account. SmartSubs was built to fix that, with a focused interface, intelligent cost-saving recommendations, and nothing in the way.
Task completion rate
Faster task completion vs feature-rich nav
User satisfaction
My role
Product Designer
Timeline
Ten weeks, 2024
Team
Me (product design), PM, engineering lead, client stakeholders
Context
A problem that sneaks up on everyone
By 2024, the average person was paying for somewhere between four and twelve recurring services simultaneously. Streaming, software, fitness apps, cloud storage, news. Each charge small enough to ignore individually, collectively adding up to something nobody planned for.
Competitors like Rocket Money and Mint had both grown into full financial management products. The subscription tracking was buried inside a broader tool that most people didn't need. Bobby was cleaner and more focused, but offered no intelligence. It tracked things, but it never told you what to do about them. There was a clear gap for something that did one job properly: helping people understand what they were paying for and whether it was worth keeping.
Light mode - The default experience. Clean and open, with a purple accent that keeps the interface feeling intentional without being heavy.
Dark mode - The same five screens in dark mode, showing how the design system holds up across both themes without any loss of hierarchy or clarity.
Problem
Visibility without action isn't enough
The stakeholder sessions early on helped frame what this product actually needed to do. Tracking subscriptions was the obvious brief, but the research pointed to something more specific: people didn't just want to know what they were paying. They wanted to understand whether it was worth it, and they wanted to know what to do next.
That shaped the entire product direction. Rather than building another tracker, the focus shifted to what came after the list: surfacing which subscriptions weren't pulling their weight, and making it easy to do something about it.
Core problem statement
How might we create an intuitive, centralised platform that helps users track and optimise their recurring payments, empowering them to save money and avoid unnecessary charges?
Research & Analysis
What the research actually told us
Two weeks of research before touching a design file. I ran a survey across 60 participants and followed up with one-to-one interviews with a subset. The key question wasn't how to design a tracker. It was whether visibility was even the real problem, or whether people needed help deciding what to do once they could see everything.
70%
were managing five or more recurring payments simultaneously
60%
cited tracking multiple subscriptions as their biggest frustration
65%
wanted automatic reminders and a single consolidated view
"I know I'm wasting money on subscriptions I don't use. I just never sit down and actually do something about it."
Interview participant, 2024
Interviews surfaced a consistent theme around trust. People were reluctant to hand sensitive financial information to apps they'd never heard of. That shaped a core design principle early: be transparent about what data you're using and why, and make it straightforward to leave.
Affinity diagram
Five themes emerged from surveys, one-to-one interviews, and competitive analysis. Organisation and cost were the obvious ones. Trust turned out to matter just as much.
User journey map
The journey made clear that trust needed to be earned before any action could be asked of the user. Each stage was designed to reduce hesitation, not just move people forward.
Analysis
Who we were designing for
Research synthesis pointed to three distinct user archetypes. Different incomes, different relationships with money, but all caught out by the same blind spot: not knowing what they were actually paying for each month.
The Automation Seeker
Wants control, hates admin
Brian wants automation, not manual tracking across a fragmented list of subscriptions.
The Household Manager
Clarity over complexity
Sarah manages a shared family budget and prefers simple, visual interfaces on her phone.
The Conscious Spender
Stung by small print
Alessandro tries new apps freely but hates surprise charges and wants help deciding what to cut.
Design
From blocks to a finished product
The process moved through clear stages in close collaboration with the PM and developers. The visual direction leaned into clarity: dark background, high contrast, one accent colour, typography that gets out of the way. Every element on screen is either giving information or enabling an action.
Establishing layout logic and key interface areas before any visual decisions were made. Getting the structure right before worrying about how it looks.
Low and mid-fidelity exploration of the dashboard, subscription list, spending overview, and recommendations surface. Validated with the PM and engineering lead before moving to high fidelity.
Taking the initial structure further with more specific content placement, clearer navigation patterns, and closer attention to interaction states. Surfaced a few navigation patterns worth questioning before anything was locked in.
Colour and typography introduced for the first time, giving an early read on visual direction without the distraction of full detail. Still loose enough to change course quickly.
Final screens with precise colour, typography, iconography, and all interactive states. Designed with developer handoff in mind throughout.
A full system covering foundations, components, and patterns. Design tokens built in Figma using variables and exported via Tokens Studio. A three-layer token structure meant changes at brand level propagated automatically.
Components - Buttons, cards, inputs, tags and navigation elements, all built as reusable Figma components with light and dark mode variables.
Patterns - How the components come together across the core flows: dashboard, subscription list, spending insights and recommendations.
The SmartSubs mark was designed to feel financial but not corporate. A rounded S form that nods to the subscription loop without being literal about it. Four explorations, one direction.
Usability testing
Ten users, one stubborn problem
Moderated sessions with 10 participants, asked to complete three core tasks: adding a subscription, checking their total monthly spend, and acting on a recommendation.
90% got through without significant friction, which validated the navigation structure and the overall information hierarchy. But one problem kept coming up.
Task completion rate
Faster task completion vs feature-rich nav
User satisfaction
The fix that mattered most
40% of participants could see the recommendation but not the reasoning behind it. They knew SmartSubs was suggesting they cancel something, but had no idea why. Without that context, most hesitated or skipped it entirely.
The fix was straightforward: add a plain-English explanation before the suggested action, not after. One sentence covering why the app flagged the subscription. How long since it was last used, what it costs per year, which category it sits in. That was enough. Participants who had previously skipped the recommendation started acting on it.
A/B testing
Two tests, two clear answers
Before finalising the launch configuration, two A/B tests were run in collaboration with the PM and data team.
Test 01
Light mode vs dark mode
Light mode: 15% higher interaction rate, better readability scores. Dark mode: 20% higher comfort rating for longer sessions. The answer was user-configurable at onboarding, with light mode as default.
Test 02
Simplified vs feature-rich navigation
Simplified nav saw tasks completed 25% faster with 18% fewer errors and 30% higher satisfaction. The feature-rich version caused more frustration than feature discovery. Simplified navigation won, with advanced options in a secondary menu.
My role and the team
Areas of ownership and key collaborators
I ran the full project as a solo designer, from defining the research approach and running stakeholder sessions through to high-fidelity design, design system build, and developer handoff. The project reached full handoff stage. Development was handled by the client's engineering team after sign-off. The trust concerns from interviews shaped the privacy transparency features. The confusion around recommendations led to the plain-English rationale cards. The data led somewhere useful rather than just confirming decisions that had already been made.
Client and stakeholders
Defined the product scope and objectives, aligned on KPIs, and reviewed progress throughout the design process.
Developers
Collaborated on technical feasibility during design, received the full handoff package including annotated Figma files, tokens, and exported assets.
Product Manager
Oversaw project scoping, stakeholder alignment, and worked alongside me on the A/B test planning and analysis.