Enhancing the video checkout experience, one iteration at a time

Running several rounds of usability testing until finding the best experience to increase conversion rates.

Case study
September 2, 2016
Enhancing the video checkout experience, one iteration at a time
My role

Product Designer & Researcher

The activities

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

The team

Product Manager and Frontend Engineer

The tools

Sketch, Camtasia, Proto.io, and Google Sheets


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.


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 flexible price (a.k.a. contributions).


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 presenting 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 we ask them to "log in". It is not a good experience, and it is tricky to solve it backstage in a seamless way 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.


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 users in the study:

  1. Play a preview/trailer of a video on a website
  2. Run into the paywall after the preview ends
  3. Click on one of the options to unlock the rest of 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 but 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; some were players from regional teams here in Guadalajara, Mexico.

I also 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. Our app's white-labeling capabilities allow users to see the publisher's logo and colors in our interface, which was enough for them to feel that they never left the website.
  • Purchasing a single video vs. a season pass: users felt comfortable 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 couldn't find it.
  • Form over function: the cards they run into after watching the preview triggered the checkout flow and contained 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 a ticket-shaped container—rookie mistake.
  • Creating an account: all users felt comfortable creating an account after paying for a video or season pass. The reason for that? Because they had already entered their credit card details, they 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 for a video, the user could use a slider or manually enter an amount. Nobody used the second option, and having two controls to do the same thing forced me to reduce the font size and make the UI look cramped.

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.
  • I 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 had already caught up with my mockups, so they put together a development instance that saved me the effort of creating another prototype. All I had to do was create a few temporary email accounts so every user had a fresh start when testing.

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. The following is a quote from one user 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 donating for 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.


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 would be a point of friction in the process actually makes users feel safe and ultimately increases the chances of paying for a piece of content.