Company
Harvard Business Review

Role
Lead product designer — Interaction design, UI design.

Team
Agile team consisting of a Product Manager, Senior UX Researcher, UX Researcher, and team of Developers.

Duration
September 2017 — February 2018

The challenge

Users who buy a subscription have to link an HBR.org account to it in order to access their site benefits. Currently, only 43% of new subscribers were initiating the account linking process in the same visit that they subscribed. Only 32% of these users successfully ended up with a subscriber account. This meant that half of our subscribers couldn’t take advantage of their HBR.org benefits upon subscribing.

With most of the subscription benefits (or all of them, in the case of the Digital-only tier) being contingent on site access, if a user did not manually link their account their subscription would be basically unusable. We were worried about this leading to frustration and degrading the user’s trust with the brand. Our team decided to tackle this issue and raise the percentage of users that linked their account as they purchased their subscription.

Above is the final subscription linking flow for users who are creating an account on HBR.org.

My role

I was the product designer in an agile team consisting of a product owner, UX researcher and a small team of developers to design the best solutions for the issues mentioned above. My responsibilities included:

• Collaborating in regular brainstorming sessions with the team about possible solutions.
• Being actively involved in planning and participating in user tests.
• Researching on common best practices for subscription flows.
• Creating sketches, wireframes and other artifacts for user testing, proof-of-concepts and live testing on HBR.org.
• Presenting designs and get buy-in and approval from stakeholders.
• Designing 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.

Evaluating constraints and pain points

As with any project, there were elements beyond our control that made linking a subscription more complicated than it should be:

Pain point #1: Linking subscriptions was not an automatic process. The subscription API was separated from HBR.org’s in such a way that they could not user pass data back and forth with each other. Because of this, users had to validate an account on HBR.org manually.

However, were also patterns that we could fix:

Pain point #2: Linking an account was more confusing than it should be. The current layout of the pages and interactions made it hard for the user to follow along in the linking process because it had no explanations as to why they had to do this. The combined account creation and sign-in interaction step amplified the confusion.

Pain point #3: It was not an organic step in the subscription process. Asking users to complete another step when they thought they were done was frustrating to them. We had a chance to build it into the subscription process in a way that wasn’t disruptive.

The current user experience

After subscribing, the user landed on a screen where they had to enter the email they subscribed with to look up their subscription details.

The issue

The screen the user landed wasn’t clear about why you need to “Register your HBR subscription”. It’s especially confusing for users who have already registered with HBR.org. 

The user gets taken to a page to confirm their information and either create an account or validate an existing one.

The issue:

The user had to figure out that the password field served both as a way to validate/log in to an existing account and create a new one. The instructional language was overly wordy and opaque.

After they’re finished the subscriber either got taken to a welcome page or was redirected back to the homepage if they were already registered on HBR.org.

Alleviating issues within the current flow

Working within development constraints

We had several whiteboarding sessions with our lead developer to figure out how to reduce the friction of the subscription flow. We tried to stick to simpler solutions since we didn’t know how much leeway we had with how HBR.org communicated with the subscription API. Some of these were:

Using clearer, concise language on the confirmation page to explain the purpose of this step.

Carrying over the subscriber’s email address to the account linking flow so that they could move on quickly to the next step.

Revisiting the possibility of the systems knowing who had an account and who didn’t so that we could more easily take the user down the correct path. Were there security issues with this?

Sketching out the user journey

During our first brainstorm, we didn’t want to push too far yet on what was possible when passing subscriber data back and forth through the back-end systems.

Shown above is some whiteboarding done mostly by our UX researcher during our team brainstormings.

Integrating linking a site account into the subscription flow.

Taking a possible risk.

After multiple discussions, the team suggested to stakeholders that we have account creation and log-in upfront.

Why have potential subscribers create an account or sign in first?

• It’s an established pattern used by brands like Wall Street Journal, The New York Times, and The Economist.
• Account creation amounts to setting a password, and users expect this to happen within the subscription process.
• It mitigates later confusion about account set-up, which is especially important for digital-only subscribers.
• It’s supported by previous user testing.

We arrived at a compromise with the stakeholders where we would conduct unmoderated test with users first with this solution and, if it was well-received, create a live A/B test versus the current subscription flow.

Exploring how to start the subscription process with account linking.

The overall goals we wanted to address were keeping the subscription process short and simple, being as transparent about the full process with the user as possible, and having the experience feel organic within the subscription flow.

The first version of the new flow

I mapped out a new user flow with hand-drawn wireframes in collaboration with our UX researchers and feedback from the rest of the team.

We decided to go in the direction that required a user to create an account or log in so that they could move forward. They would have to do it later on, and it was already a recognizable pattern used by other publishing companies.

User testing with wireframes based on new subscription page designs.

We ran some more unmoderated tests with mid-fidelity clickable prototypes that I built. While these wireframes used the updated, cleaner design that I was creating for the subscription page, we were also concurrently developing a live A/B test with a design based on the current subscription page.

Account Creation

Testing account creation — Half of our test participants were linked to the prototype above to test the ease of account creation.

Account sign-in

Testing account sign-in — The other half of the participants were asked to sign into an existing account.

The results of our tests proved most of our assumptions correct (thus far)

Users had no issues going through the full subscription flow in addition to either creating an account or signing in at the beginning. As we had hypothesized, it wasn’t an unexpected pattern for them and they did not have negative reactions to the mandatory account linking as long as we weaved it organically into the process.

Pressure-testing the new user flow live on the site

Tweaking the design to slot into the current subscription experience.

I worked with our development team to see how we could implement a version of the improved account linking flow that could work with the current subscription page. It was a challenge because the page had a different transaction flow than the updated design we were planning to go live with in the future. I had to make sure that what we were testing was able to fit organically into the current and future subscription experience. This also allowed me to address issues with the design that had been brought up in the last test.

The subscription page at the time, which had been designed by an outside vendor.

But first, one more round of unmoderated testing.

We tested the prototypes I created one last time before committing to developing the full account linking flow. It was an efficient way to check again that our assumptions about this flow being more user-friendly than our current one weren’t completely off base.

Our test included nine participants (non-registered, non-subscribers) who had visited our site within the last 1 month on desktop.

Sketching the updated flow

The sketch above was drawn by one of our UX researchers in collaboration with me to show the planned flow.

The newest flow placed the “Sign in” and “Create account” CTAs front and center so that users couldn’t miss it. Stakeholders also agreed to not include the “Buying on behalf of someone else?” information for simplicity and to address it in some other stage of the process.

First version of the high-fidelity prototype

The new design and prototype I created for testing.

In combination with choosing a payment plan (final version)

This was the version we ended up testing with users. I added the step of choosing a monthly or annual payment plan at the request of our stakeholders.

The results: Overall incredibly positive!

The test results showed that users weren’t bothered by having to sign in or create an account to subscribe. They thought it was intuitive and frictionless and understood that they were automatically logged in after they subscribed.

The results that concerned us were that only half of the participants understood why we asked them to sign in. Three users thought it was for data purposes. One user assumed it was so HBR knows where to mail the latest issue, and another that it was for accessing customized content; it appeared that we needed to be more obvious about the purpose of account linking.

Moving forward with A/B testing

Planning it out

We quickly launched an A/B test domestically in the U.S. for the subscription page. Half of our users would get the regular subscription flow and the other half would get the flow with the added experience of creating an account or logging in at the beginning.

The results: A conversion drop

Adding the account creation/sign in as a first step impacted conversion rate by -23% compared to the current design. After learning of these results it was up to the business to decide how to react. Should we iterate until we saw better results, or was this enough proof that the proposed solution wouldn't work at all?

Reacting to the test data and reflecting on learnings.

In the end, the business decided that with the back-end issues happening when subscriber information got passed back and forth between HBR.org and the subscriber API, it was better to cut our losses and rely on the paywalls that were currently being designed to catch potential non-linked subscribers. The team was disappointed, but we resolved to revisit this issue when our back-end capabilities were more advanced.

A positive thing that came out of this project was that we were able to use what we learned about stretching the capabilities of our subscription vendor to work for us and improve on the user’s experience in subtle ways. The testing results and design explorations helped us particularly with our paywall re-design initiative which had a significant chunk of the user journey rely on linking an account.