Company
Harvard Business Review

Role
Lead product designer — Interaction design, UI design.

Team
Agile team consisting of a Product Manager, Project Manager, UX Researcher, and team of Developers. Art directed by Director of User Experience & Product Design.

Duration
September 2017 — November 2018

The challenge

Harvard Business Review decided in the fall of 2017 to go from a one-tier subscription model to a three-tier, Good/Better/Best (or G/B/B) model. Our team was tasked with two main things:

1. Communicate the benefits and information of each tier. A considerable worry for the business was how users would react to a more complex subscription model with not only new products but a new monthly billing option. We tried to mitigate or eliminate issues as much as we could through multiple rounds of testing with the current subscription page and prototypes.

2. Make the subscription flow quick and painless. There should be no distractions or needless friction once the user is attempting to check out. The team already knew from earlier user testing and data from the current subscription page what pain points to begin working on.

Above is the final subscription checkout flow that was implemented with some small modifications. The visual design of the landing page was ultimately changed before go-live.

My role

As lead designer for this project, I worked with an agile team consisting of a product owner, UX researcher and a small team of developers to design the best solutions for the goals mentioned above. The capacities in which I was involved were:

• Collaborating in regular brainstorming sessions with the team about possible solutions.
• Being actively involved in planning and participating in user tests.
• Researching common best practices for subscription and transaction flows and patterns.
• Creating sketches, wireframes, prototypes and other artifacts for user testing, proofs-of-concept and live testing on HBR.org.
• Presenting designs to get buy-in from stakeholders.
• Delivering the final UI so that it used patterns from our established design system and creating new interaction/UI patterns when needed that could be used in future projects.
• Working closely with our in-house and subscription fulfillment house’s development team to implement the design.

Preliminary research

What do three choices look like?

Because HBR hadn’t ever offered more than one subscription tier before, we decided that I would perform some competitive analysis and look around at how services and sites with subscriptions incorporate multiple offers.

G/B/B as a subscription model has been widely used, but not as much in the publishing industry at the time from what I'd found. Not only that, but HBR was offering products besides articles within the site to subscribers at different tiers, which added a layer of complexity to the information we had to clarify for potential subscribers. I used my research to gain inspiration and gather best practices, which is why I didn’t limit it to only subscription pages.

A small sample of the document I created to present my research to stakeholders.

What did we already know through previous testing and data?

We had already performed user testing with the current subscription page and mobile wireframes before this project. We also gathered data on how users were behaving on the current page that could be applied to the new subscription flow.

What we knew:

• The “Bill Me Later” option confused most users and was rarely used.
• Only 43% of new subscribers initiated syncing their subscription with an account on HBR.org within the same visit that they subscribed.
• Users thought the visual design of the page was not on-brand for HBR.
• Mobile drop-off during subscription purchase was very high at 98.4%.

Taking a first pass at the experience

Taking users through the flow one step at a time.

The team first brainstormed what the ideal flow should look like, which ended up being a sequence of screens that took a user step-by-step through the subscription purchase process. At the same time, we were trying to figure out with our development team how to work with the subscription API to alleviate issues with users connecting or “syncing” their subscription.

A photo of one of the brainstormings we had around sketching the user flow.

The subscription purchase user flow

Creating the wireframes for testing

I collaborated with UX to design a prototype of the full subscription experience for desktop to see how users would react. While there was a lot of discussion about the flow, I produced some rough wireframes quickly to test our assumptions.

Photos of the subscription flow laid out using pieces of paper as components — I worked with our UX researcher to sketch pieces we could use to lay out the full flow. It was easier and less restraining than moving things around on a screen.

Step one — Choose a subscription option

At this point we weren’t testing how users understood the benefits within each tier, so we went for the simplest way to show it.

Step two — Confirm billing cycle and enter contact information

This button opens a slider with details of their chosen subscription.

It made more sense to make users choose a billing cycle and enter their contact information in one step rather than splitting it up.

The flow was divided into two parts: Payment cycle + contact/shipping information and then payment. This was done to keep the user focused on each step in the process.

This link takes the user back to the subscription landing page.

We added a small reminded to potential subscribers that they had to use the email address entered in order to access subscriber-only digital content on the site.

Benefits overlay (if user clicks on “View details”)

Step three — Enter payment information

“Bill Me Later”— an action that let a user receive a print magazine at no cost to try out for a short period of time — had confused many users before in the current subscription flow.

We tried to minimize confusion by re-labeling the checkbox “Bill me later instead” and having the payment input fields become disabled. This would hopefuly signal to users that they didn’t need to fill in any payment information at this stage.

A quick summary of what subscription a user was purchasing and how much they were going to be charged was placed so that user could double-check before finalizing their purchase.

Step four — Subscription success and confirmation

We prompted users to create an account on HBR.org and link it to their subscription. This was an important step to complete or a subscriber wouldn't be able to take advantage of their benefits.

Testing the wireframes

Our UX researcher set up a test to find out how well the flow worked. We conducted four moderated tests with non-subscribers.

The results

• 3/4 users said they would prefer account creation within the subscription flow.
• All users thought the interaction for choosing between annual/monthly billing was intuitive.
• 3/4 users liked the sequence-based flow.
• 3/4 users still found Bill Me Later confusing. They had no idea what it meant.
• All users wanted a receipt at the end of their purchase.

Round one of designing and testing for mobile

After our first round of user testing for desktop let us know that overall we were on the right track, I moved on to wireframing the flow for mobile. To ensure that mobile wouldn’t be an afterthought I designed for both mobile and desktop almost concurrently.

We tested with mid-fidelity wireframes to ascertain if participants had issues understanding the benefits of each tier or if they ran into any blockers during the transaction process.

The first iteration of comparing offers on mobile

The biggest difference between mobile and desktop was how users could compare offers on the landing page.

On mobile, the benefits were seen in a full-screen overlay where a user tabbed between tiers. All three offers opened the same overlay showing the corresponding tab. I chose to do this so that the offer page would be free from informational clutter for users who already knew what they’d like to subscribe to, but it also lets users who needed more information have quick access to it.

One of the later iterations of the details overlay.

How do you teach users about ‘Bill Me Later’?

After the negative response to the ‘Bill Me Later’ option during desktop testing, we attempted to lessen the confusion and possibility of users accidentally choosing it. 

By converting the interaction to two radio buttons, I made it more evident to users that they were choosing between two options. This also allowed me add explanatory information to the ‘Bill Me Later’ tab about how it worked.

Eventually, stakeholders chose to remove this option altogether, simplifying the checkout process.

The results from testing the mobile wireframes

• All users were able to successfully choose a tier and subscribe.
• Most users liked the benefits overlay but wanted it to be more obvious what they didn’t get without having to double-check with another tier.
• Users still didn’t understand why they had to create an account or connect their existing one at the end of the transaction.

Perfecting the mobile experience

Why put so much effort on mobile if users subscribed primarily on desktop?

I finalized the visual design and the interaction on mobile while we were testing with both mobile and desktop. It was a known issue that we had the lowest conversion rate on phones, so I wanted to make sure we had the ideal design and interaction on mobile before scaling it up to desktop.

What’s the most intuitive way for users to compare offers?

Creating options to test.

I created many options to possibly test with the main goal of the design being:

• The layout had to facilitate comparing offers against each other.
• Benefits had to be explained enough for users to make an informed decision without leaving the page.
• Basic offer information such as offer name, price, and type of payment had to be clear and easily scannable.

Option one — Showing all information at once.

Pros: Straightforward and easy enough to compare what gives you the most benefits. Although not their favorite, it tested alright with users.

Cons: Some users didn’t know what the carets were meant to do and so they didn’t use them. A lot of information is shown up-front, making it hard to scan.

Option two — Focus on what benefits are available in each tier.

Pros: If designed correctly, users could understand the basic differences of each tier quickly. Other subscription services use this approach for showing offer details so it’s not an unexpected pattern to users.

Cons: Some designs of this pattern didn’t test well with users who were expecting to see at a glance which tier offered the most benefits by seeing the list become longer in each subsequent tier. Stakeholders preferred a visually simpler approach to showing the information. 

Option three — Show basic offer information with option to see benefits.

Pros: Gives users who know what they want a clean, minimal design that lets them get to the check-out process immediately. Users responded favorably to how simple this approach is.

Cons: Some stakeholders were worried about how users would react to having to do an extra click to find more information.

Going with the most straightforward approach 

After unmoderated user testing and multiple rounds of refinement, we were able to convince stakeholders to take a chance on the third and most simple approach. Testing showed us that users were able to see the option to compare benefits, but we agreed it was a good idea to use metrics to keep track of how many times it was used.

Streamlining the transaction process

Showing one step at a time may not always be the best approach

Throughout this project, our team assumed that taking a user step-by-step through purchasing a subscription worked best because it wouldn’t overwhelm the user.

Previous data from the current similar flow showed that users had no problem with completing a purchase. However, after looking at the flow again without the complexity of subscriber syncing we thought we should take a second look at our approach.

Were we introducing unnecessary friction?

It became apparent that making users take action to confirm that they wanted to move on after every step was ultimately very tedious.  The interaction didn’t make the experience more palatable because the whole transaction process was just three steps.

We made the experience more streamlined by showing the full transaction process on the page. This got positive feedback from users when we tested this as wireframes and we kept it as the final design.

The semi-final transaction experience  — The design that was implemented showed the full purchase flow to the user instead of dividing it into steps. We decided to scrap the previous experience of showing each step at a time for a more straightforward one after not being able to include subscriber syncing.

The finished design

The version of the landing page you see below was not developed due to changes in the visual direction later in the process. We went with a photographic approach that I did not design for the live subscription page instead of using MUTI's illustrations.

The landing page with open offer details — When the user lands on this page the offer details are closed by default. The Marketing team provided concise descriptions of each benefit so we wouldn’t need an accordion interaction to explain each benefit.

The purchase page — Besides removing subscriber syncing and showing all transaction steps, the complexity of this page was simplified even more after we removed the sliding overlay that had the subscription details for each offer. This was decided after we heard from current and non-subscribers that they would have a good idea of what they would subscribe to by the time they got to the landing page. Instead, there is a short list of benefits in the right-hand rail.

The purchase confirmation — This page acts as a simple receipt and link to go to the homepage of HBR.org. What used to be a prompt to go link your account with your new subscription was now being taken care of by a follow-up email.

Learnings and takeaways

The most important thing I learned from this project was that compromising due to stakeholder pushback didn’t mean I wasn’t advocating enough for the user. The subscription process is a very sensitive interaction for stakeholders, and for good reason; if it’s not designed well, it would have many consequences for the business. Throughout the design process our team had to balance marketing and business goals with user wants and needs. Sometimes these two things are in opposition and a compromise must be made.

We worked very closely with stakeholders as partners to see how we could meet in the middle to create a subscription purchasing process that could meet both business and user needs. In the end, we collaborated to design an experience that was functional, streamlined and on-brand for HBR.