Project Background

The Problem

The (fictional) company I worked with for this project has an established online platform for tracking subscriptions, and is looking to expand into the mobile market. I was provided with three business goals that would help guide my development of the mobile application experience:

• As a current user, I want to see all of my subscriptions in one place so that I can get a comprehensive view of my spending on subscriptions. 

• As a returning user, I want to unsubscribe from a subscription so that I can reduce needless spending. 

• As a consumer, I want to be notified if any of my subscriptions are about to be auto-renewed so that I can make a decision about if I want to renew the subscription and continue spending money.

The company’s target user is — over 30 years of age, uses phone and desktop equally, middle class, and trying to be more budget conscious.

I was also provided with information regarding the brand to help guide my decision-making:

• Brand personality — a trusted friend who is helping you save money 

• Brand attributes — trustworthy, caring, friendly, casual

 The Solution

In order to achieve these three goals, I had to first establish a baseline that included: 

• Other products currently existing in this space and how they serve the needs of users

• What kind of features are essential for an app of this nature targeting this set of users

• What the app would look like and be named that aligns with the personality and attributes of the brand. 

I then had to test different iterations of prototypes with different potential users to gather feedback that would validate or negate my decisions about the app’s design and function.

 My Role

I was the sole person working on bringing this app to life, from the initial ideation process to high-fidelity prototypes. I began with research, where I examined different existing products of a similar nature, then synthesized my findings to extract the most useful information. I created a company name, SubsHelper, and visual style that would help lead me to a consistent appearance throughout use of the app. I envisioned the flows that potential users would take to achieve their goals within the app, used paper and pencil to sketch out these different flows, then transformed the paper sketches into low-fidelity wireframes. I tested this prototype with users, gathered feedback, and created a high-fidelity prototype incorporating feedback based on the first round of testing. I performed a second round of testing with the high-fidelity prototype, again iterating afterwards based on feedback received.

 Research

 Study Industry Leaders

I began by identifying and studying these three products in the subscription management space: the web-based service TrackMySubs, and the two iOS based mobile applications Rescribe and Subscription Manager. In this primary evaluation, I noted each service’s positives and negatives, and imagined how users in these apps could achieve the stated business goals that I was looking to solve with the SubsHelper mobile app.

In all three of these platforms, users are able to see all of their subscriptions in an overview screen. Subscription Manager and TrackMySubs offer users more customization in sorting, and allow users to filter subscriptions by different categories. Rescribe was more limited, only providing users with three different sorting methods.

All three services provided users the option to be notified before the payment date, though these notifications seemed more functional in the two mobile apps as opposed to TrackMySubs. As it is a web-based service, TrackMySubs’ method of sending notifications to the users felt like a workaround - notifications are sent either by email or through a third-party service that sends a notification on other platforms, such as Slack.

Of the three services, only TrackMySubs facilitated the process of canceling a subscription, by providing a link to launch the subscription company’s website. I wanted to emphasize this feature in particular for my own app. If I could streamline the process of unsubscribing, that could provide a significant benefit for the budget-conscious user.

 Competitive Analysis

To better understand the problems I wanted to solve, I performed a competitive research analysis and came away with a number of useful insights. 

First, it appears that the subscription management platform space is fragmented without any one dominant service. There is little in the way of cross-platform services that will sync between a user’s different devices. Most services seemed to be for mobile or desktop only, which could lead to a more restricted experience for users. Also, there are two main types of services offering subscription management - ones on the more basic end with few features and others designed for overall financial management that include many unrelated features that may overwhelm users who are only interested in subscription tracking.

Second, all of the services I looked at for this analysis have definite room for improvement in their UI and UX. A lack of facilitation around the cancellation process was a big one, but also cases of unclear language, overcomplicated flows to complete a task, or excluding important functions like sorting by category. 

Third, my research emphasized the importance of having a developed brand presence. TrackMySubs has a Facebook group where users can connect with the brand and each other, and the company’s founder shares personal anecdotes on their website about how and why he started the project, which adds a sense of trustworthiness and connection. It’s no coincidence that at the time of writing, TrackMySubs seems to be one of the most popular services in this space.

 Heuristic Analysis

To help illustrate more clearly a picture of some of the existing services in this space I also performed a heuristic analysis of TrackMySubs’ web platform and the mobile applications Rescribe and Subscription Manager. I chose three of Nielsen Norman Group’s heuristics with which to perform this analysis: Help and Documentation, Aesthetic and Minimal Design, and Recognition Rather than Recall.

I found that while they each had different strong points, none of the platforms I evaluated excelled in all three of the NNG heuristics I selected. Rescribe performed well in Aesthetic and Minimal Design, with an intuitive hierarchy and simple yet effective interface, and Recognition Rather than Recall, keeping all relevant information visible on the page. Subscription Manager performed well in Help and Documentation, with a developed FAQ section, and in Aesthetic and Minimal Design, featuring visually pleasing color contrasts, a well thought out hierarchy, and use of easily identifiable iconography. While I had to keep in mind for TrackMySubs that I was evaluating a web-based platform instead of a mobile app, the service performed well when looked at through the lens of Help and Documentation with a searchable FAQ section.

 Takeaways

My evaluation of the three services helped me prioritize what features I wanted to include when developing SubsHelper. These features are:

• A subscription dashboard where users can see all their active subscriptions at once

• Ability to set reminders before billing payments with a variety of options for when to be reminded

• A built-in and regularly updated database of subscription services to streamline the addition of  subscriptions to track

• Ability to tag or categorize subscriptions 

• Ability to sort or filter their subscriptions in different ways, including by category or tag

• Module that  tells the user their monthly expenditures on subscriptions

• Facilitating the process of canceling a subscription, at minimum a link to the company’s website

 Design and Testing

 Creating the Company Name and Visual UI Style

When it came to creating the name, I had to get in the mind of the target user in order to appeal to them. The name had to be friendly and casual, but at the same time convey trustworthiness and caring. I settled on the name SubsHelper for a few reasons. I feel that this name is in touch with the brand’s attributes while being easy to remember and clear in conveying its purpose. Using the shorthand “subs” in place of “subscriptions” puts the user at ease and conveys a casual demeanor, while the inclusion of “helper” assures the user that it will make things easier for them and provide utility.  

For the color palette, I chose a shade of blue that would feature prominently throughout the design. Blue conveys loyalty, trustworthiness, calmness, and dependability - all attributes I want potential users to associate with SubsHelper. As an accent color I chose a shade of orange, to serve as a lively counterpart and suggest determination, success, confidence, and fun. 

As I was creating this application for use on iOS, I chose the SF Pro Display font as iOS users are likely already familiar with it. I wanted the font choice to be clear and unobtrusive, something that functions well for users and avoids unnecessary cognitive load.

 User Flows

 Low Fidelity Sketches

After finishing the user flows, I created a set of low-fidelity sketches to expand on the steps I had envisioned. These sketches help me visualize page layouts, information architecture and hierarchy, and check if I had left out anything critical before turning them into wireframes.

 Wireframes and Low Fidelity Prototype

Using the low-fidelity sketches as a guide, I created wireframes in Figma which I would use in my lo-fi prototype. These wireframes were meant to be simple yet functional, allowing me to quickly move onto the testing phase to try to validate my design choices and also include enough detail that testers could imagine using it as an actual app.

I used Marvel to create the prototype I would test with users. I wanted to make this prototype functional enough that users could complete all tasks relating to the user flows based on the previously stated business goals.

View the Marvel prototype

 First Round of User Testing

This first round of testing was all conducted in person. Five participants were given the prototype and I acted as the host/moderator, providing them with a set of tasks to perform and documenting their process along the way. The tasks given were:

1. If you wanted to see all of your subscriptions in one place, what would you do? Is there anything that allows you to sort them in a specific way?

2. If you wanted to unsubscribe from a subscription then remove it from the app, how would you do that?

3. If you wanted to add a new subscription, then make sure you get notified before the automatic payment occurs for that subscription, how would you do that?

4. How would you add a billing reminder to an existing subscription that doesn’t yet have one?

After completing testing and synthesizing the feedback I received, I discerned a few critical errors that would need to be resolved before the next design phase and further testing. 

The most critical issue relates to the second task of unsubscribing and removing the subscription, in that users were not using the in-app option to visit the company website. Only one user used the link to visit the company’s website and cancel the subscription as I had envisioned, the rest proceeded directly to the bottom of the page and selected the option for “delete subscription” without realizing that it would not cancel their subscription with the service provider. This could be problematic for the business goals, as the inclusion of a link to the company’s site as I had originally envisioned did not help people to cancel their subscriptions. If a user deleted a subscription from the app and stopped tracking it, thinking they had cancelled the subscription when they really had not, it could lead to unexpected charges for the user as well as an erosion of trust towards the brand and service. To remedy this issue, I decided that I would change the wording of the text and make this feature more prominent on the page. 

A second critical issue was that many users had trouble finding the save button on the page after making changes and wishing to continue on. Users finished the task on the page, paused and I observed them looking around the page for a few seconds before finally finding the save button. There were a few different pieces of feedback as to why this issue was occurring for most of the participants. Some of them were more familiar with Android phones and did not think to look for the save button in the upper right corner, others mentioned they expected to find it at the bottom of the page after entering information instead of back at the top. If users are not able to figure out how to perform a common action like saving the page, they may become frustrated and not achieve their goals or move onto a different app altogether. To remedy this issue, I decided I would add a CTA save button towards the bottom of the page which would be easier for users to find. 

A third critical issue I discovered in this round of testing was that some users became stuck when viewing the new subscription page. They did not realize they had to tap on the page in order to start entering information, so they waited a little while for something to happen and asked what they were supposed to do before eventually figuring it out - some intentionally, and some by chance. Here, users mentioned they were looking for something more akin to a traditional text input field or something that clearly denoted it was to be interacted with. This could potentially cause the same problems of user frustration and attrition. In order to fix this issue I decided I would change the look of this section: making the appearance more module-like and adding lines to separate different options.

In addition to these three critical issues, some other minor issues arose that I would address in the upcoming iterations. Some users commented that they were visually drawn immediately to the “delete subscription” option at the bottom of the page. I was unsure whether this was due to the red text here standing out against the shades of grey used elsewhere throughout the wireframes or something else, so I decided I would change the wording to try to convey the function more clearly and see if the issue still arose in the second round of testing. One participant was unsure of what the dashboard page was and commented that they didn’t know what they were looking at, so I decided to clearly label the page to alleviate any confusion.

 High Fidelity Designs

With the first round of user testing complete and a set of issues identified, I transformed the low-fidelity wireframes into high-fidelity screens in Figma, incorporating solutions that would resolve the aforementioned critical errors. Here I would also incorporate the fonts, colors, and visual UI style I previously developed. After designing the screens, I created an interactive prototype in Marvel and organized another round of testing.

 Second Round of User Testing

In the second round of user testing, I conducted a mix of in-person and virtual tests with a new set of participants. Participants were given the same tasks as in the first round of testing, as the tasks all related back to the company’s stated business goals for users. This would allow me to evaluate whether the iterations I made provided a better experience for users and helped them better achieve their goals. 

As was the case with the first round of testing, the link to the company’s website proved to be an issue, although with fewer users this time around. Among those who did not use the link, they mentioned they would have thought to leave SubsHelper and visit the website or app of the service they were wishing to cancel, and that they wouldn’t have expected the app to help them cancel a subscription (as in, it was strictly for tracking and management). Others proceeded directly to the “Remove subscription” option at the bottom of the page like in the previous round, however in this round the text of the modal popup window helped them to realize they needed to return to the previous screen and cancel using the provided link before removing the subscription from the app. This signaled to me that not only would changes need to be made to the company website link, but also the “Remove subscription” option at the bottom to make it less attention-grabbing to users. For the next set of iterations, I decided I would turn the website link to start the cancellation process into a button and add a symbol signifying the button would launch an external website. I would also change the wording of “Remove subscription” to “Remove (subscription name) from SubsHelper” to make its purpose clearer. 

A second, albeit less critical issue that arose in this round was that users were confused by the wording of the “Duration” section when setting up a new task. As they verbalized their thought process while going through the tasks, two users remarked they weren’t sure what was meant by duration in this instance. After clicking on it and seeing the available options for them to select, they were able to discern the meaning. When iterating, I decided I would change “Duration” to “Subscription length” for clarity.

Aside from these issues, this round of testing proved to be less problematic for users and most of the changes I made after the first round of testing helped to assuage users’ issues. While the link for starting a cancellation was still an issue, no users got stuck on the new subscription page as they had in the first round and no users had any trouble finding the save button. All users were able to identify that the first page they saw was the dashboard page and that it contained all the subscriptions they were tracking.

View the Marvel Prototype v2

 Second Round of Iterations

To address issues identified in the second round, I changed the link that said “Cancel your subscription” into a button, with the addition of the “launch external link” symbol and the universal symbol for cancel, a red ‘X.’ The text for “Duration” was changed to “Subscription length,” and the option to remove the subscription at the bottom of the page was changed from “Remove subscription” to “Remove (subscription name) from SubsHelper.” I also edited the CTA save buttons on certain pages, greying them out in instances where the user had not made any changes to preemptively prevent any confusion regarding the button’s function.

 Results

Validation 

After multiple rounds of testing and incorporating feedback, I’m fairly confident the present iteration of SubsHelper helps users achieve all of the company’s stated business goals, with the caveat that the final revisions were not user-tested. The user feedback I received proved invaluable in the design process to provide an effective user experience. While testing the high-fidelity prototype, second-round participants commented that they would find an app like SubsHelper useful, and agreed that it can be difficult to keep track of their subscriptions. This was a great feeling, as it showed I could envision a product that provides solutions to real-world problems faced by real people, and simultaneously satisfies the business goals of a company.

 Future Testing Sessions

Given the scope and timetable for this project, I did not perform further testing sessions. If I had the opportunity to test further, I would want to assess whether the last round of iterations made any impact, specifically changing the link to cancel a subscription into a button. With an app like this, directly canceling a subscription of a service provided by a separate company does not seem feasible - users would need some way to link all of their various subscription accounts within the SubsHelper app which seems outside the scope of technical possibility. It may also be infeasible to ask the user to grant permission to SubsHelper to act on the user’s behalf in the login and cancellation process in an external app or service. If the button solution still proved to be problematic, I would prioritize developing solutions to facilitate the cancellation process.