Subscription Manager App

I created the Subscription Manager as an early UX challenge in 2025. The idea was to explore how recurring payments and subscriptions could be brought into one dashboard so that users could see what they were paying for, when payments were due and where they could go if they wanted to stop a subscription.

At the time, I treated the cancellation journey more simply than I would now. Looking back, there is an important difference between stopping a recurring payment and ending the underlying subscription contract, so I would not now present the concept as being able to cancel every service directly from one app.

Original Goals

• •
  Bring recurring costs together: Give users one place to review subscriptions instead of finding them across different services and statements.
• •
  Make upcoming payments more visible: Show renewal or payment information before money leaves the account.
• •
  Provide a clearer exit route: Help users understand where to go when they no longer want a subscription.
• •
  Keep financial information readable: Use a simple dashboard rather than making the interface feel like a full banking application.

Because this was an early challenge, the original case study used broad market claims that did not add much to the design. I have since revisited the idea and replaced those figures with reliable UK sources that give better context to the actual problem.

This research strengthens the portfolio write-up, but I do not treat it as proof that the original prototype was validated with users.

What This Means for the Concept

• •
  Visibility still matters: There is genuine evidence that people can lose track of subscriptions and auto-renewals, so a clear overview is a reasonable problem to explore.
• •
  Reminders are more realistic than assumptions: Upcoming renewal and payment information can help users make a decision without claiming the app can control every subscription provider.
• •
  Cancellation needs different routes: The interface should explain whether the user needs to contact the provider, their bank or another service.
• •
  Trust would be central to a real product: Financial account access would require explicit consent, clear data-use information and an appropriate regulated provider or integration.

The original challenge used three personas to help me think through different subscription-management situations. Looking back, I would treat these as provisional design scenarios rather than evidence that I had identified three validated audience segments.

I used the challenge to practise moving from a problem idea into a user journey, wireframes and a higher-fidelity prototype. The dashboard became the main part of the concept because it gave the user a single place to see recurring costs before deciding what action to take.

The final prototype uses a dashboard-led approach. The aim was to make the user's recurring costs easy to scan and then let them move into the details of a subscription when they needed more information.

Core Prototype Ideas

• •
  Subscription overview: Bring recurring services together in one interface.
• •
  Payment visibility: Show costs and upcoming payments so the user can see what is due.
• •
  Subscription details: Give each service a clearer space for payment and renewal information.
• •
  Cancellation journey: Explore how the user could move from identifying an unwanted subscription towards the appropriate route for ending it.

I Would Approach the Design Differently

Looking back at the project now, I would change quite a lot about both the design and the way I approached it. At the time I made the process harder for myself than it needed to be, partly because I was still getting used to Figma.

Adobe XD was the design software I was most comfortable using at university and I continued using it after graduating. I had used Figma in smaller ways before this project, but the Subscription Manager and AcclimatizeMeNow challenges were some of the first times I tried using it for a more complete UX process.

I use Figma much more regularly now and I am far more comfortable with the way it works. If I started this project again, I would organise the file differently, simplify parts of the interface and spend more time thinking through the structure before moving into higher-fidelity screens.

Treat Cancellation More Realistically

I would also change how the cancellation part of the concept works. The original design treated cancelling a subscription as though the app could handle the whole process directly.

I now understand that different subscriptions and payment methods can require different cancellation routes. A better version would help the user understand whether they need to contact the provider, manage the payment through their bank or follow another cancellation process.

Do More Research Before Designing

I would also spend more time validating the problem before moving into the interface. The personas used in the original project were design scenarios rather than people I had interviewed, so I would now want to speak to real users and understand how they currently keep track of subscriptions.

That research would help me decide what information should appear on the dashboard, what people would actually find useful and where the cancellation process becomes confusing.

The final outcome was a high-fidelity Figma prototype exploring a subscription dashboard and cancellation journey. It demonstrates the direction of the interface, but it is not a working financial application and I did not run formal usability testing to prove that the flow solved the problem.