Busting Ghost Subscriptions: The Devil is in the Details
“By Failing to Prepare, You are Preparing to Fail” — Benjamin Franklin
Responsive Web Design
General Assembly UXDI Galápagos, Project 3
My Role: UX Researcher along with Jessica Chiu and Zevy Blokh
Duration: 2 Weeks | Project Status: Ongoing
Project Overview
The goal of this project was to develop a responsive website from idea through to handoff to the a team of Developers, in this case fellow students in the Software Engineering Immersive course running concurrently with ours
The Project introduced us to the following UX methodologies, concepts and tools;
- Topic Mapping
- Screener Surveys
- Journey Mapping
- MoSCow and Feature Prioritization Matrix
- Minimum Viable Product
- Design Studio
- Figma software
- Zeplin software
Scope of Work
We were given the topic of Finance and asked to create a responsive website for both mobile and desktop, and prepare a Zeplin file to hand off to developers. The primary focus was on the front-end development and having a user create, update and delete an account was a required feature.
Process
We followed the Double Diamond framework of UX development.
First Diamond: Design the Right Thing:
Discover: Research based on our initial hypothesis.
Define: Take the research findings and determine what problem needed to be solved.
Second Diamond: Design Things Right.
Design: Design a solution, test it and refine it.
Deliver: We are not yet at the point of delivering a final product.
Problem Space Statement (Hypothesis Assumptions)
We started by topic mapping the subject of finance, which involved thinking of as many financial topics as we could and mapping each out in finer detail until we found an issue we thought we could solve. Our topic map covered mortgages to micro finance, but we settled on the subject of subscriptions.
We hypothesised that people had trouble managing subscriptions and were prone to being charged for services they no longer used, especially online. We each had a story about a free trial that ended and morphed into a paid account or discovering that we had forgotten to cancel something.
How might we help people better manage their digital subscriptions and avoid wasting money on services they don’t use?
DESIGN THE RIGHT THING
Discover
As with all things in User Experience we had to test our assumptions. In this case we wanted to interview people.
The Screener Survey
To find the interviewees we developed a screener survey which we put out to our networks and the General Assembly student body. The three key requirements were that users were
- Over the age of 18
- Used digital subscriptions
- Were willing to be interviewed
Our survey also collected valuable quantitative data about what subscriptions people used, how often they used them and if they had ever cancelled one. Of the 17 survey responses six agreed to be interviewed. One of those was on the West Coast an we couldn’t make it work so we were down to five.
The Interviews
We wrote a discussion guide for our interviews to ensure we asked the same questions of each person, while recognizing that each answer could take us down various paths.
All five interviewees were technologically savvy and aged between 23 and 33. All of them had a story about a subscription that had got away from them. They only discovered this while they were looking over their bank accounts. All of them said they got emails from service providers but few actually read them. Some even had a separate email account for site registration specifically to avoid being spammed by businesses.
We wrote the observations and quotes from each interview on virtual sticky notes in a program called Miro and grouped them into common themes by the process of affinity mapping.
Here are some representative quotes
“I assume they’re not going to say like, ‘Hey, you haven’t used this in four months. Are you sure you want to still keep giving us money?’ It’s kind of an out of sight out of mind thing.” — Peter the Elder
“I got the free trial but you also have to put your credit card down. And after the trial some months went by, and I was like paying and paying and paying.” — Peter the Younger
“In terms of managing it, like I don’t do it, I’m sure other people do. But that’s not really my it’s not really my forte, to be on top of that sort of thing. “ — Jackie
Define
The Insights
Our initial assumptions were validated and we distilled the following key insight from our research.
- Users Struggle To Keep Track Of Accounts They Do Not Use Regularly
- Users Only Discovered Forgotten Subscriptions Through Bank Statements
- Users Don’t Have A Way To Talk To Their Service Providers
Persona
Based on our interviews we developed a Persona called Jaime. Jaime might be a fictitious amalgam of the people we interviewed, but he helped us as designers remember our insights relate to problems real people have in the real world.
Journey Map
A journey map follows the user Persona through a process. In our case it was the discovery and cancellation of a rogue subscription. One of the key elements is to track the emotional state of the user. This can elucidate pain points and opportunities to develop a solution.
In Jamie’s journey the pain points and corresponding opportunites were
- the discovery of a re-occuring charge on his bank statement,
- the hassle of determining what that charge was for, (have an alternative way to track subscriptions)
- the difficulty in search for the account details (alternative to email)
- the time spent cancelling the account (provide information)
DESIGN THINGS RIGHT
Design
The Journey map moved us towards the Design Phase of the project. To kick this off we invited our colleagues in the Software Engineering Immersive to join us in brainstorming ideas.
This involved a return to the virtual Miro wall where everyone put possible features of the product on sticky notes and arranged them on a MoSCoW chart.
This involves splitting the features into 4 categories
- Must have at launch
- Should have at launch, but can be in a future build
- Could have at launch, but will probably slip to a future build
- Won’t have a launch, but might be in a future build.
After the MoSCoW has sorted the possible features of a site the Must haves and Should haves are further refined using a Feature Prioritization Matrix, where the effort required to build them is plotted against the time and resources available.
The goal of all this is to come up with a Minimum Viable Product. What must be built to launch the website with regard to what is possible.
Our Minimum Viable Product included the following features
- A way to create an account profile
- A way to add a subscription to your profile, both automatically and manually
- A way to view your subscriptions in a table or on a calendar
- A way to alert the user if a subscription had not been used for a set time
Design Studio
Once we had determined the MVP we moved into a Design Studio to try and come up with some ideas as to how it would look and function.
Deign Studio is a collaborative process, facilitated by the designers but one that encourages people from all across an organization to contribute. The idea is that more perspectives lead to more ideas to choose from. The other benefits are that it is fun and encourages buy in from the rest of the team.
The process is heavily structured.
- Everybody sketches ideas for 5 minutes
- Every pitches their sketches to the group for 2 minutes
- The other members of the group respond to the pitch one by one (1 minute each)
- Everyone splits and sketches again, iterating on the best ideas they saw in round one.
- There is a second round of pitch and response
- The group converges on a best design.
Mid-Fidelity Prototyping
The weekend following the Friday afternoon Design Studio we worked up the ideas as a Mid-Fidelity Mobile Prototype in the design program Figma. This process put the minimum in Minimum Viable Product as we ran against the constraints of time while observing the Sabbath and Father’s Day. The wireframes included the following functionality.
- Ability to create an account
- Ability to add a subscription
- Ability to find a ghost subscription
- Link to information to cancel a subscription.
Link to View Design of Mid-Fi Prototype
Link to View Prototype used in Testing
We ran five usability tests on this prototype asking the user to perform the following tasks. We recorded the users success (Direct, Indirect or Fail), time on task and evaluation of the ease of the task.
- SCENARIO
You are on the Subscription Busters welcome page
TASK Sign up for a new account, and setup your monthly Netflix subscription. - SCENARIO
Now imagine you have repeated that step and set up your new account with multiple subscriptions.
You are on the signed-in homepage with your subscriptions on the dashboard…
TASK Adjust your dashboard so you can see which subscription you have not accessed in a while. - SCENARIO
You have successfully filtered your dashboard to show the least used subscriptions. You have some Ghost Subscriptions that you have not used for a while.
TASK Find the video streaming service you are not using and cancel it.
Of the 15 tasks only 2 were performed indirectly, but users pointed out some minor formatting and language issues that we could incorporate into the next prototype, they also commented
- The site looked gimmicky and not credible, which could have been a function of the mid-fidelity prototype and would hopefully be resolved with a high-fidelity prototype
- There was some confusion over the asking for a credit card account nickname (so the user could know what account the subscription was charged to) was actually giving over the credit card.
- Users also wanted to add subscriptions without having to putting data in manually, “Do I have to manually enter my subscriptions? That would be a lot of effort to set up, what if I missed one that I had forgotten about?”
- And they suggested the Ghost subscriptions should be at top of the dashboard in a separate list
- The prototype was not clear the user had to cancel the subscription on the provider’s website,“How do I know for real if it actually cancelled the subscription?
A Critical Crit
That Tuesday we had a Crit with our instructors.
They suggested the next prototype should actually display the iPhone keypad to mimic the action of filling in the forms to register for the site. A short cut in the original prototype meant users did not read a instruction about the credit card nickname which lead to confusion
They called into question the decision to remove the automated addition of a subscription from the Minimum Viable Product over the weekend. As the research while the feature to manually add information was necessary, the automated feature was integral to the usefulness of the site.
They also pushed back on whether it was possible to track the use of a subscription on the device by searching cookies, and told us to get a software developer’s opinion on how this could be done.
Obviously this addition of the automated feature was more work and if we couldn’t track usage then one of the major features would have to be cut. Eventually we were informed we could track subscription use with a plug-in.
Any use that was on another device could not be tracked and would rely on the user to confirm if they were using the service.
High-Fidelity Mobile Prototype
The next step was to develop High Fidelity Prototypes for mobile and desktop. As we had to do another round of usability testing on the mobile prototype first, we developed the look and feel of the site on mobile.
We were scrambling after the crit and didn’t think to set a text style guide, and page templates, before we started moving onto the individual pages. I’m not sure if one of General Assembly’s Growth Mindset principles is Learn From Your Mistakes, but in this case we certainly did.
When I was a producer at FoxSports.com from 2003–2008 Dan Strauss the Lead Developer congratulated me on producing one of the first functional specs, for the 2006 Soccer World Cup, that his developers could code without clarification. Back then I wireframed it in Word and the design was handled by the creative department who handed it off to the dev. Team.
This was different. As designers we had to prepare the creative spec as well. This would be a Zeplin file and as we were introduced to it in class, it quickly dawned on me that we were about to serve our SEI teammates a dog’s breakfast of inconsistently spaced and sized elements.
So in addition to building out the rest of the mobile functionality, conducting another round of usability testing and developing a desktop version, we had to tidy up what we had. Something had to give.
More Usability Testing
As we had changed the feature set, the tasks in the second round of usability testing were no longer analogous to the first round. We tested the flow of automatically adding subscriptions by having the user link it to a bank account so the site could search for recurring payments and display them in a dashboard. The user could then select which ones were subscriptions they wanted to track.
We also tested the downloading of the plugin, and the full cancelation flow. Again there were some things to change, and the credibility of the site was still questioned by some users. I think qualified graphic designer might be necessary to thread the needle between delightful and credible.
High-Fidelity Desktop Prototype
Link to the Desktop Prototype
Deliver
Next Steps
The project was presented on Friday afternoon
The version of the Zeplin file submitted is insufficient for handoff. The following work needs to be done:
- Complete Desktop screens for Account Update and the Fine Print Files in Figma
- Add mobile dropdown menu, profile picture and credit card account features.
- Ensure Desktop and Mobile styles completely align in Figma.
- Review annotations of pages in Zeplin
- Review spacing in Zeplin.
- Any necessary changes coming out of the Design Crit in Figma and Zeplin
What I Learned
Plan…
The toughest part of the Design Studio is the convergence on a single idea at the end. In both the class and project examples this process was a free for all on the Miro board. It would have been more productive to have one person sketching with the others coming to a consensus about the design as it was sketched.
Plan…
Run the idea by a supervisor to ensure that you are proposing something that is technologically possible.
And Plan Again…
Develop a style guide and page template before you start on the pages of a High-Fidelity Prototype.
