Subscription tracking made easy

Project planning

Time boxing work

In order to stick to the 90-hour timeline, I started with a project plan. This outlined the phases, deliverables, and design rationale throughout the project. After I completed each phase, I presented the deliverables at stakeholder meetings to show progress toward the final prototype. A lot of time was spent in the discovery phase. It was important to understand the industry and its consumers in order to translate Keeps’s business requirements to mobile in the most simple and effective way.

Discovery

Exploring the problem space

[Blank] as a service

At the time of writing, May 2021, the Software as a Service (SaaS) business model was already a dominant force. The subscription-business industry had been growing at 200 percent annually since 2011. This growth made sense; the recurring nature of subscriptions allowed SaaS to continually hone in on the customer experience, creating repeat customers who were loyal to the companies whose products they used.

However, there was a dark side to these recurring payments — automatic renewals. According to a survey of 100 consumers by fintech startup Hiatus, almost 62 percent were paying unwanted subscriptions because they forget about auto-renewal. And, over 50 percent didn’t know how many subscriptions they currently had.

Interviewing subscribers

These findings helped shape the discovery process, especially when it came to user interviews. I interviewed five people with at least five subscriptions. We discussed tracking expenses and managing subscriptions and did a contextual inquiry using an existing subscription tracking service called TrackMySubs. I then mapped the results:

The most common frustrations that participants shared when managing subscriptions were:

• Not being able to easily cancel a subscription
• Forgetting about which subscriptions they had because of automatic payments
• Having subscriptions scattered among different bank accounts and credit cards

But there was more. Participants were especially frustrated from being bombarded by marketing emails from their subscriptions and missing important notifications. Others lacked the time to decipher subscription charges within their expenses.

There were two types of users emerging: busy multitaskers lacking time to manage even a few subscriptions and an automator-type looking to simplify managing lots of subscriptions and reduce unnecessary communication. I created primary and secondary personas to reflect this.

Meet Jorge, the primary persona:

Jorge closely represented Keeps’s target user and aligned with all of the business requirements. I was now solving a user-centered problem: how might we help Jorge see all his subscriptions in one place with a comprehensive view of spending, directly unsubscribe from a subscription, and only get notified when a subscription was about to auto-renew.

I created user stories to model the red route flows that Jorge would take to accomplish his goals. I started with four user epics but decided to combine viewing all subscriptions and getting a comprehensive look at spending into a single flow, since they were related and it would ensure the desired simplicity of the interface.

Information architecture

Creating a blueprint

Now, I had to develop an architecture that would help Jorge accomplish his goals. After consolidating the user epics and determining the user stories needed to accomplish each of Jorge’s tasks, I created three user flows to model his paths through the interface:

The last step in putting together the architecture was to arrange the flows into simplified interface outline. The idea was to use Keeps’s core account-linking functionality as a hub-and-spoke structure that would allow users to easily import subscriptions from their payment sources and manage them in one place within the app. The account-linking also meant being able to directly cancel a subscription in-app.

I started with rough sketches and quickly moved into lo-fi wireframes. This helped move the project along within the short timeline and also provided an easier transition into the upcoming hi-fi designs. Since this was going to be an Android mobile app, I used an Android wireframe kit in Figma to expedite the building process.

Low-fidelity testing

Validating the initial structure

Using the wireframes, I created a lo-fi prototype to test the initial structure and flows. I then conducted guerrilla testing with five participants. The context was that the participant was already a Keeps desktop web app user, Jorge in this case, and was trying out the mobile version for the first time. He already had an account and subscriptions linked to a credit card within the app. The tasks were:

1. View all existing subscriptions
2. Get a comprehensive view of spending
3. Add new subscriptions to dashboard
4. Resolve alert about subscription auto-renewing
5. Set new alert for auto-renewal
6. Cancel a subscription that’s over budget

It was great to do usability testing this early in the project because there were several critical issues that emerged.

Perhaps the most existential of these was that it was not clear where to add new subscriptions to track or where existing ones came from on the Overview page. The core mechanism for viewing subscriptions appeared not to be user friendly. Part of this confusion might’ve resulted from the wording of the task, asking to import subscriptions from a new account when the goal was essentially just to link the new account to the app. Still, this issue, along with the others, prevented Jorge from completing his goals. This meant Keeps was not meeting its business requirements.

High-fidelity design

Foundations for a prototype

In addition to addressing the prioritized recommendations for the low-fidelity testing, I had to move forward and create a light-weight style guide for the mobile design. This included a baseline color theme, typography, and core UI components. Keeps already had a brand platform, which I extended with logo design. I felt the castle imparted a sense of trustworthiness and care. To ensure that the design followed Material Guidelines, I used the official Material Baseline Design Kit in Figma.

I understood that the wireframes were just a structural outline and that there was a lot of useful feedback to incorporate into the next round of designs. I focused in particular on the first of the critical issues, making sure that the dashboard screen — the heart of the prototype — had clear affordances indicating how to manage and view subscriptions.

I created hi-fi mockups for each red route with all of the feedback in mind:

Prototype testing

The prototype: a draft

It was important to do another round of usability testing after revising the four critical issues. I wanted to validate the placement of the floating action button (FAB) on the Overview page and ensure that the modal bottom sheet it opened simplified the interface for Jorge. I also wanted to address the new icon for opening the comprehensive spending page, the copy for a canceled subscription, and the ease of setting a reminder. I followed essentially the same testing script since the scope of the business requirements hadn’t changed and only added one task — to set price change notifications.

There were two critical issues this time around: it was not clear where to access notifications nor was it clear where to set reminders. Participants didn’t expect to go to Settings to change their notification preferences. They felt it would be easier if notifications and reminders were grouped together, since reminders were a type of notification. The same applied to setting the reminders themselves. Participants expected to find reminders on the Calendar page since reminders since both were time-related.

Final designs

The prototype: revised

I time-boxed the remainder of the project for revisions of the hi-fi prototype. Using the findings from the second usability test, I iterated on 9 of the screens:

I made the following revisions:

• 3: I added an account label for each subscription to indicate that it was imported from and tied to that payment source. I also added a “monthly” label under the grand total for clarity.
• 5, 6: I changed the FAB’s expanding modal bottom sheet to include setting a reminder, removing the “organize spending” option. This made sense from an interaction design standpoint in relation to the “add” icon on the FAB and also made setting reminders much more prominent in the UI.
• 17: I made the Calendar top nav more uniform with the rest of the pages and reduced cognitive load by just having one trailing icon for setting reminders.
• 26, 27: I moved reminders out of the Profile page and combined them with Notifications under Settings to reduce cognitive load.

Outcomes and lessons

Project Completion

After making all of the revisions from the two usability tests, I wired together the final prototype, below. You can try it out yourself here. People enjoyed using the prototype and, above all, praised it for its simplicity. While this mobile version of the Keeps app met all of the company’s business requirements, there were still some challenges to address going forward.

Lessons learned

Aside from operating within a tight timeframe, there were two important lessons learned:

• Adhering to Material Guidelines: An extensive design system is a double-edged sword, on one side taking a lot of guesswork out of UI component specs but on the other side requiring granular perfection from the entire UI. Despite using Material’s design kit, it was still challenging to QA all of the designs with time limitations. It was nonetheless a great learning experience, strengthening one’s understanding of design patterns, interactions, animations and, well, the list goes on.
• User scenario and context: In order to avoid scope creep and stick to the project deadline, I chose to design for a return user. This made sense since Keeps already had an established user base. However, this created issues of clarity when inevitably testing with new users. There was no onboarding flow, so I frequently had to explain parts of the UI and reword usability test questions. Parts of the design, like linking a new account, understandably felt disconnected.

Next Steps

I would start by creating an onboarding flow. This would help orient new users and avoid confusion while testing. I would also expand on the “setting a reminder” use case since time constraints left this functionality to be pretty limited in the final prototype. I would do the same with UI on the Calendar page.