PiggyBank – (UX Design)

The Problem – Stop unwanted subscription fees

It’s hard to keep track of all the products and services that we have subscribed to every month. All we see is money deducting from our accounts, sometimes from services that we don’t need anymore. The challenge is to design a product which helps manage these subscriptions.

My approach – 10 day sprint

Day 01Miro Whiteboard Ideation

With a 2-week deadline, I needed to work fast and efficiently. I’m a visual thinker and I dream big, which means that my ideas come thick and fast. Tell me a problem and my mind will light up with a flurry of solutions. I need a tool to get all my thoughts down and laser-focus my thinking.

Restrictions act as compost for creative ideas, so I spent one hour with give of my fellow UX designers to scope out ideas, gaps in knowledge and determine an approach with context.

Summary of Miro ideation session
  • Early ideas that bubbled up during our co-creation session:
    1. Offer the app free for 6 months
    2. Start new subscription i.e. Netflix > Get confirmation email > Send email to Sub-app > Sub-app adds a new entry with reminder
    3. Users are asked to rate a subscription to determine whether it’s value for money

Competitor Analysis

The results of my competitor analysis and S.W.O.T. analysis are shown below with major insights highlighted in pink.

S.W.O.T. Analysis

  • Summary of Competitor Analysis / S.W.O.T. Analysis:
    • All subscription apps on the market can be split into two categories:
      1. Connect to a bank account:
        • App automatically determines regular payments
        • Sophisticated data analysis
        • A.I. transaction management
      2. Stand-alone app:
        • Input subscriptions manually
        • Basic data reporting (basic info in / basic info out)
        • Low security issues
  • I identified a gap in the market:
    • An app that lies in-between both categories
    • Independent of a bank account
    • Asks the user questions to collect data
    • Provides deeper data analysis
    • Knows “why” a subscription should be cancelled

Problem Statement

“My user needs a way to track the usefulness of a subscription, so that they can make a decision whether it’s value for money.”

Day 02Research Goals

  • Understand which products / apps are being used and by whom.
  • Learn how these apps are being used and which pain points exist.
  • Identify what’s missing from existing apps and highlight opportunities.


  • I created a survey using Google Forms with these goals:
    • Define a target audience.
    • Gather data about subscription use and mental models used in managing finances.
    • Gain some understanding how, when and why subscriptions are cancelled  

(Click images to enlarge)

  • Summary of the survey:
    • Average age 25
    • 10-15 subscriptions
    • 81% manage their subscriptions manually
    • 59% manage their subscriptions in their head
    • 85% “I cancel a subscription when I realise that I no longer need this.”
      • Which means there has to be a period where the subscription is no longer used, but is still being paid for
      • This raises the question, at what point is the subscription no longer useful?
      • And can this be pin-pointed?

User interviews

  • I wrote a script for the user interviews with these goals:
    • Understand what unique methods people use to manage their subscriptions
    • Understand why users are managing subscriptions in their head
    • Hear some real life stories that reveal the user’s thought process when cancelling a subscription. 

Day 03Affinity maps

I conducted the interviews and created an affinity map of the key quotes.

  • Summary points of the user interviews / affinity map:
    • “I manage my subscriptions in my head.”
    • “I cancel when I realise that I’m not using it anymore.”
    • “I expect the app to track my progress.”

Key findings

  • My key findings from the research:
    • I know that users are managing subscriptions in their head
    • I know that users are relying on the apps to track their progress
    • I know that users will decide to cancel once they realise that they are no longer using it
  • With these insights, I began to think about a perceived cycle from the user that was not working for them:
    • Apps use reminders, gamification and hooks to push the user to make progress
    • The user becomes more addicted
    • The app praises the user when they’re doing well
    • Which pushes the user to use the app more
    • However…
      • It will never tell you that you don’t need the app anymore
      • Even though the user is relying on the app to track progress

In order to understand this better, I came up with this analogy about storing a block of cheese.

  • We buy cheese and store it in our fridge.
  • We keep it in our head how long it has been there for.
  • If nobody uses the cheese, it will eventually go bad, but it will take time for the cheese to show signs of mould.
  • Once we see the mould, we know to throw the cheese away.
  • However if there was a hack that told you the exact moment when your cheese was starting to go bad, we would manage the cheese in our fridge better.

User persona

(Click image to enlarge)

User journey

I mapped out the user’s journey when I realised why users were managing subscription in their head.

(Click image to enlarge)

  • Summary of the user’s journey:
    • Users manage their subscriptions in their head
    • Users are not setting a reminder in order to re-affirm that their goal for that app will be a success
      • “I will use this app to reach my goal.”
      • “It will be successful.”
      • “It will be value for money.”
    • By setting a reminder the user would be saying:
      • “I need to set a reminder to check whether I have failed.”
      • “Failure is not an option.”
      • “If I were to set a reminder, it might mean that I will fail.”

I amended the problem statement to the final version:

“Alex needs a way to track the usefulness of an app over time, so they know the right time to cancel based on insights. This will be confirmed when Alex saves money after cancelling a subscription recommended by the app.”

Task analysis

The following task analysis showed the core feature of my unique app:

(Click image to enlarge)

Day 04Ideation

Day 05Mid-fidelity wireframing

Day 06User testing

  • I wrote a test script with these goals in mind:
    • Set the scene about managing subscriptions
    • Create a hypothetical scenario where the user would like to track a subscription
    • Ask the user to set up a subscription tracker for a gym membership
    • Ask the user to track the subscription’s usefulness over time
    • Ask the user about these key features

Day 07User testing – what needs fixing

“On the first screen I’ve set a payment threshold of €40, but in relation to what?”

– User Tester
  • My original idea that I sketched was designed to help lighten the burden for users who previously managed subscriptions in their head, wanted to migrate to a digital solution, but did not want a lot of time setting their subscription trackers up.
    • Suggested Change – HIGH PRIORITY
      • After further consideration, I began to question the usefulness of this screen
      • If our goal is to save the user money, then there does not need to be any threshold
      • Recommendation is to remove this screen completely
    • Evidence
      • My first tester highlighted this and after including an additional question in the script, all other testers agreed to remove this superfluous screen.

“The payment input field is so small I cannot see it properly.”

– User Tester
  • A design error that was easily fixed. The payment was big enough on my original sketches, but during the mid-fidelity screens the font was not sized correctly.
    • Suggested Change – HIGH PRIORITY
      • Increase font
      • Consider changing the payment input field to the same style as all other fields
    • Evidence
      • Again my first tester highlighted this oversight which clearly needed fixing.

“I think the Frequency input field is confusing. I’m not sure if this is a single or regular reminder. I would also put this at the beginning.”

– User Tester
  • I think a part of this problem was an error in the testing script. I had primed the user with too much information about how the app would remind the user in the future about tracking the usefulness of their subscription. This caused confusion when similar wording appeared in the prototype.
    • Suggested Change – MEDIUM PRIORITY
      • I decided to add a Calendar icon to allow the user to choose their own reminder date
      • I also changed the wording to simply read, Reminder
    • Evidence
      • After this was highlighted in the user testing, I went back to my research
      • I looked through the screenshots that I had taken from competitor apps
      • I made slight changes, but decided not to change the order
      • I would like to look into this option further and conduct some further research with other testers to fully understand user’s perception of this.

Day 08Hi-fidelity screens

The process flow of my final screens.

Day 09Hi-fidelity prototype

Day 10Project summary

  • What opportunities remain for future improvement?
    • I am looking at patenting this idea or approaching the existing companies who offer similar apps whether they would be interested in my research or integrating the idea into one of their app’s features
  • Key learnings:
    • My UX methodology can be adapted to be a 1-week, 2-week, 3-week or 4-week process
    • It’s really hard not to run away with all the big ideas that comes into my head at the start of the process. My UX methodology is there to prove it right or wrong.
    • It initially felt demotivating to work on a project that had been done to death. However it was a great challenge and it reiterated that there are always great opportunities to be had for designers willing to deep dive into user behaviour

Next: Talk2Me – (UX Design)

One thought on “PiggyBank – (UX Design)

Comments are closed.