Case study, SmartSubs, Freelance, 2024
SmartSubs: Making subscription chaos manageable
A freelance iOS design project. 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
Solo designer, client stakeholders, developers
Target satisfaction score
iOS
Dashboard, subscription list and recommendations screen
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.
Existing tools either over-indexed on full financial management or lacked any intelligence. Neither felt right for someone who just wants to stay on top of their monthly spend.
Problem
People aren't looking for a list. They want to feel in control.
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.
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?
"I know I'm wasting money on subscriptions I don't use. I just never sit down and actually do something about it."
Usability test participant, 2024
Prototype built in Figma. Covers subscription tracking, spending overview, and the recommendations flow on iOS.
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-on-one interviews with a subset. The goal wasn't to document the methods for their own sake. It was to build enough evidence to make decisions that could be defended.
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.
Themes grouped from survey and interview data: organisation, cost optimisation, privacy concerns, and alert preferences.
Mapping the emotional arc from discovering an unexpected charge through to feeling confident about monthly spend.
Analysis
Who we were designing for
Research synthesis pointed to four 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 Overwhelmed Organiser
Too many subscriptions, not enough visibility
Brian manages work and personal subscriptions across multiple devices. He wants automation and smart alerts, not another thing to manually maintain.
The Budget-Conscious Parent
Keeping the household spend under control
Sarah juggles streaming, meal kits, and kids' apps on a tight budget. She needs a simple overview that makes it obvious what to cut and what to keep.
The Forgetful Spender
Paying for things she's already forgotten about
Alexander knows he's overpaying but never gets round to doing anything about it. He wants reminders that prompt action before the next renewal hits.
The core flow covers adding subscriptions, viewing consolidated spend, and receiving a contextualised recommendation with a clear next action.
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.
The user types a natural-language prompt or selects a chip. On send, the AI enters a visible streaming state: a typing indicator appears and the response builds progressively. An instant result feels like a filter. A streaming response feels like someone thinking. The distinction is small technically and significant experientially.
Before returning outfit looks, Muse may ask a single follow-up question to narrow the brief, "Is this more of a restaurant dinner or something with a bar and dancing after?" The answer refines the recommendations and adds a preference signal to the style model. This is also Muse's cold start solution: a first-time user with no history can be guided toward something specific through one question. The conversation is the onboarding.
Two or three outfit cards appear, each with a look name, assembled pieces, total price, and a "Shop this look" CTA. A brief reasoning note sits beneath each name explaining why this combination fits the prompt. Every recommendation shows its work. This is the most important design decision in the entire flow and the clearest point of difference from every existing recommendation engine.
When an item in a recommended look is out of stock, Muse substitutes the look rather than surfacing an incomplete one. The next best complete and shoppable alternative is shown in its place. If Fit Finder has been completed, Muse filters by the user's size before surfacing any looks. On a first visit with no size data, looks are shown with a prompt to complete Fit Finder before adding to cart.
The fitting room leads with "Upload your photo" as the primary action. On upload, a loading indicator appears on the model frame alongside a live countdown timer. At approximately seven seconds the rendered image fades in. Making the generation time visible was a deliberate trust decision: it signals that something computationally real just happened, rather than a static image swap.
A single "Add all to cart" CTA replaces five separate add-to-cart interactions. For returning users with a size profile, their recommended size is pre-selected. For first-time users, clicking "Add all to cart" triggers the Fit Finder prompt inline. The user completes the short sizing flow and the item is added in the right size without leaving the page.
Muse doesn't rely on upfront profiling. It builds a style model from signals a user generates naturally as they interact: what they dwell on, what they skip, what they explicitly reject in a prompt. Session signals stay local to the conversation. Persistent ones, like adding to cart or completing Fit Finder, update a long-term profile across future sessions. After roughly three sessions the experience becomes meaningfully personalised. On a first visit, the conversational prompt and clarifying question stand in for history entirely.
Availability and sizing decision logic
Usability testing
What we learned from 12 participants
Moderated usability testing with 12 participants, recruited to reflect the three archetypes from research. Each was given the same scenario: find a complete outfit for a specific occasion using whichever tools the prototype offered. Sessions were conducted remotely using think-aloud protocol, with a second team member noting where participants hesitated or expressed uncertainty.
The most revealing moments weren't in the metrics. Several participants paused after seeing the outfit card reasoning note. Lines like 'Perfect for a sunset boat trip or cliffside dinner' landed exactly as intended. The reaction was consistent: 'oh, so it actually understood what I meant.' That confirmed the core research finding: unexplained recommendations are the trust problem, not inaccurate ones.
The feature engagement gap was the most meaningful number. Users who tested Muse were significantly more likely to try both the fitting room and Fit Finder, not because they were prompted to, but because the outfit-first flow made those surfaces feel like natural next steps.
It's worth being honest about the limits here. Participants responded to static outfit cards with pre-written reasoning notes, not live AI-generated recommendations. What the test validated was the interaction model: that outfit-level curation, visible reasoning, and a connected fitting room created a more confident and engaged shopper. Whether the algorithm produces recommendations good enough to sustain that trust at scale is a question only a live A/B test can answer, which is exactly what the next phase was designed to address.
Reflection
What I'd do differently
The clarifying exchange was added as a concept but not usability-tested in enough depth. I'd want to know how many users skip it, whether the question timing feels natural, and whether the visible effect on the outfit output is enough to make the exchange feel worthwhile.
Substitution was the right call, but the logic itself needed more testing than it got. How similar does a substitute need to be before it feels like a real alternative rather than a consolation? And should the swap be visible to the user or happen silently? Only live data can answer that.
Shifting to personal photo upload was the right direction. But the privacy and comfort implications, particularly GDPR biometric provisions in the EU and BIPA in Illinois, needed earlier legal alignment and more usability testing than the timeline allowed.
Signal collection happens silently. In retrospect I'd surface a lightweight "Here's what I've learned about your style" card after a few sessions. Personalisation that's visible gives users a sense of control over it, which closes the same trust gap identified in research.
Role and collaborators
What I owned and who I worked with
I was one of three designers who developed a competing proposal during the sprint. My responsibility covered the full end-to-end experience: research participation, ideation, wireframing, high-fidelity design across desktop and mobile, and prototype preparation for usability testing. The conversational discovery flow, the fitting room reframe from "View on Model" to personal photo upload, and the personalisation signal model were all decisions I owned and proposed. The privacy and consent architecture was developed collaboratively with Legal and Privacy in week eight.
Head of Product
Oversaw product strategy and ensured alignment with business goals across all three proposals.
Head of Design
Guided the overall design vision and facilitated bi-weekly critique sessions throughout the sprint.
User Researcher
Ran the interview programme, facilitated empathy mapping, and moderated the usability test sessions.
Data Scientists
Advised on signal weighting and provided the card sorting similarity matrix.
Engineers
Consulted throughout on feasibility, and scoped the MVP build estimate for the A/B test phase.
Legal and Privacy
Defined EU and North American consent requirements and reviewed the consent architecture.