Design Case Study
September 2, 2016

Gbox

Implementing and testing a "white-labeled" checkout flow for video content creators.

Gbox
Role

Product Designer & Researcher

Expertise

User Interface Design, Interaction Design, User profiling and recruitment, and Evaluative Research

Team

Product Manager, Frontend Engineer, and Product Designer (me)

Tools

Sketch, Camtasia, Proto.io, and Google Sheets

Overview

Gbox allows content creators to distribute and monetize their videos online. Unlike typical video platforms, Gbox is decentralized – content creators can embed (and get paid for) their videos anywhere they want.

The following is the high-level journey of a typical Gbox user:

  1. A content creator uploads their videos in Gbox and adds a price to them (with the option to create subscriptions, season passes, accept donations, or set a fixed price per asset)
  2. They generate a code snippet that they embed in any website
  3. End-users run into the video, open it, and watch a small preview
  4. When the preview is over, the user sees a paywall to unlock the rest of the video
  5. The end-user completes the purchase, and both the content creator and Gbox get paid

This case study focuses on the last three bullets of the list.

Goal

Create a seamless checkout flow for end-users, so they pay for videos through Gbox without leaving the publisher's website, choose between season passes and single videos, and pay a fixed or a flexible price (a.k.a. contributions).

Challenge

Paying for the video without leaving the website implied using a modal window as our main container, which presented limitations of space and navigation, a complex puzzle to solve when considering all the information we needed to show through the different steps in the interaction.

Process & Solution

One big assumption to validate

Currently, the signup process starts after the user purchases a piece of content; once they do it, they get a receipt on their email along with a call-to-action to create an account. The assumption behind this decision is that popping up a signup screen earlier in the process would create friction and reduce conversion rates.

However, when users purchase a video, we need to link the video to their email, so we create a temporary account either way. If later on, they decide to "create an account", we only activate it by changing their password. The issues come when they try to create an account from scratch with the same email. Since they don't know they already have an account, they get confused when asking them to "log in". It is not a good experience, and it is tricky to solve it backstage for development.

The alternative is to ask users to create an account from the beginning, an approach that the team has never tested and that, if proved viable, would save a lot of trouble for everyone.

Process

I designed high-fidelity mocks in Sketch and then used Proto.io for the prototype. I used this tool because it allows me to create more complex interactions than inVision: I can embed videos and automatically transition to other views once they are done playing. I can also store values in global variables to use them across every screen, two features that were essential for making the prototype look as real as possible. This is the flow that I simulated for the study:

  1. Play a preview on a website
  2. Run into the paywall after the preview ends
  3. Click on one of the options to unlock the video
  4. Go through the checkout flow
  5. Play the full video after completing the purchase

The prototype I made replicates the website of one of our clients: Hull FC, a professional rugby team that is part of the Super League in England. The script describes scenarios in which users watch exclusive videos from Hull FC and unlock the content through the different options available: fixed price, name your price, unlock by signing up, and get a season pass.

I ran the study in two days one week apart, five users per day. Running the sessions this way allowed me to process the feedback from the first session and make changes to the interface for the second week. All the users were rugby fans, and some were even players from regional teams here in Guadalajara, Mexico.

I also decided to split each session into two parts: first, I would spend around 15 to 20 minutes interviewing them, understanding their current needs and pain points, and getting more data to add to our current Personas. The second part was about testing the solution. The first week users would create their account after purchasing the content; the second week, they would do it before entering their credit card information.

I recorded the sessions with Camtasia and managed to share the screen, video, and audio through Google Meet for the Product Managers (and anyone who would like to join the call) to watch and take notes.

These are some screens of the checkout prototype

The first try

I interviewed six instead of five users because we always plan for no-shows, and whenever everybody attends, I interview the backfills as well. This is the summary of the findings after the first session:

  • The modal window: users felt comfortable navigating to a modal window. Adding the publisher's logo and colors was enough for users to feel they were not abandoning the website.
  • Purchasing a single video vs. a season pass: users felt comfortable while paying for a single video – they had already seen the preview and knew what they were getting. The season pass, on the other hand, was a bit confusing: they needed to see the complete list of videos before paying, and although the list was available, it was hidden under a "details" button they needed to click on, but this element was not visually prominent, and they didn't see it.
  • Form over function: the cards they run into after watching the preview and that trigger the checkout flow contain relevant information that was too small for the users to see at first glance. I even rotated a couple of labels 90 degrees to make them look pretty inside of a ticket-shaped container. Rookie mistake.
  • Creating an account: all users felt comfortable creating an account just after paying for a video or season pass. The reason for that? Because they had already entered their credit card details, so they at least wanted to have them stored somewhere, along with their video. They didn't feel their information was safe if they didn't create an account.
  • Flexible payment: when donating in exchange for a video, the user could either use a slider or enter a custom amount in an input field. Nobody used the second option, and having two controls to do the same forced me to reduce the font size and made the UI look crammed.

Main changes

After discussing internally, I made the following changes to the design:

  • I removed the cards and graphics that were enclosing the asset's information, both in the video player and the checkout screen. We realized these elements were more ornamental than functional. This change allowed me to increase the font of the information and make the UI way cleaner.
  • Changed the control for opening the full list of videos when purchasing a season pass. Now they would be able to click on the "More than 50 videos" bullet to open the list.
  • Replaced the controls for naming their price with a much simpler component.
  • I moved the "sign-in" screen earlier in the flow (before entering their payment information).

By this moment, the development team was already catching up with my mockups, so they put together a development instance that saved me the effort to create another prototype. All I had to do was to create a few temporary email accounts, so every user had a fresh start with their session.

The second try

After running the second study and debriefing with the team, I summarized the main findings as follows:

  • Clarity of information: The information in the card buttons after watching the preview was clear; they understood the benefits of each option before starting the checkout process. The information on the left side of the checkout screen was also clear enough to feel compelled to create their account.
  • Creating an account: It was natural for users to create an account from the beginning. Three of them actually used their own email or social media accounts. This is what one user said when I asked his opinion about having to create an account upfront:
"It is the standard procedure; I'm paying for a Crunchyroll subscription, and the flow is similar. Having your account gives you the certainty that you own the content, and it is useful because the platform can make suggestions based on your preferences."
  • When contributing to a video, the affordance of the buttons for increasing or decreasing the amount was not clear enough; they looked like non-clickable icons for most users.
  • Even though the item in the list is underlined and followed by a "plus sign" icon, three out of five users didn't find the way to open the list of videos of a Season Pass. This issue might be due to low contrast and lack of visual prominence – the blurred background may be too distracting, and the font is probably too thin.

Outcomes

Even though there are minor adjustments still to make on the UI, we validated our primary assumption through the study:

Users prefer to create their account first and then introduce their credit card details. What we thought was going to be a point of friction in the process is the one that can help users feel safer and ultimately increase the chances to pay for a piece of content.

Joel Monteon's picture
by Joel Monteon
Product Designer