Discovery: Access, registration and entitlements

Outcome

The UX architecture of these journeys became the one every Discovery streaming service on the shared platform used. On dplay, where I had recommended registration before any playback, registered users rose sharply once registration was required. The journeys were also the basis of Eurosport Player’s authentication, a service in 127 countries, when it moved in-house from an external vendor.

Context

In test sessions run in the Nordics before I joined, and in customer service reports, dplay users could not tell a free account from a paid subscription, or whether they were signed in at all. Facebook sign-up was also creating duplicate accounts, and customer service was taking many calls about them.

Discovery was building a streaming platform from dplay’s codebase, to launch and test products quickly across markets. The existing journeys were modelled on dplay’s needs alone, and Eurosport, which sold subscriptions only and already had the more mature purchase journey, was due to move onto the same platform. The goal was to improve the customer experience and conversion on dplay, with modular journeys that would scale to other products on the platform.

Finding where dplay’s sign-up confused users

Before redesigning the journeys, I needed to see where in the live funnel users were getting confused. In my first weeks I audited dplay’s live acquisition funnel in Sweden screen by screen, as an anonymous user heading for a free show and for a premium one. I reviewed the incoming designs for version 1.4 alongside it, and gathered third-party research from the Baymard Institute.

The same Play button started a free show and opened an upsell on a premium one, and the upsell did not say what premium included or what it would cost after the free trial. The product page then offered a free account first to users who had come for premium. Registration asked for a gender and a date of birth that Facebook sign-up never collected, and I recommended making both optional under GDPR. In the 1.4 designs, individual screens improved while registration and purchase remained one journey.

01Exploration

Proposing a reason to upgrade at each user level

On the live product, a signed-in free user and a subscriber saw much the same interface, and users could not see the point of a free plan or how it differed from a paid one. I set out access as three user levels against three content entitlements. Each level unlocked a tier: open content (C0) for anonymous users (U0), walled free content (C1) for signed-in free users (U1), and walled premium content (C2) for subscribers (U2).

I then proposed what each level would offer as a reason to upgrade. I drew a task chain on a seasonal show, with box sets open to everyone, the current season for registered users and the latest episodes for subscribers. I based the chain on the Zeigarnik effect, as an example of how an unfinished show could lead a viewer to join and subscribe. My proposal included a feature matrix across the levels, for example from SD to 4K and from two devices to four, for the wider UX and design team to complete with research and best practice.

Mapping the market’s access models from the user’s side

The platform’s journeys had to serve products that did not share one access model. To see the options from the user’s side, I grouped the access models of more than 70 streaming services in Europe and the US, from public broadcasters to subscription players, by the effort it takes a user to watch. They fell into six patterns in three groups: no sign-in needed, sign-in needed and subscription needed. Discovery’s own products sat in four of the six, and dplay alone ran two models: open and free in Italy and Spain, and open, free and paid in the Nordics. I noted on the map that European broadcasters were moving to require sign-in.

In April 2019 I benchmarked parental PINs the same way, for dplay’s account area. Netflix covered in three journeys the scenarios that Sky’s NOW TV spread over five. I recommended Netflix-style journeys for dplay, built on existing UI patterns so that they would need no extra help from product design. Parental controls later went into the platform’s Account v2 spec as a P2 feature.

Letting each product switch access model with less development

Taking users straight to the journey they came for

In the live funnel, every anonymous user who wanted more than open content, from a free feature to a premium show, went through the same product page and its several choices. I replaced that route with targeted journeys, one per intent, and gave each entry point a single choice, so that neither users after a free account nor users after a subscription were confused by the other offer. I kept the comparison of both tiers for users who asked for it.

Registration and purchase became separate journeys, and I used the unentitled episode page, where I had found users most committed to watching, as the upsell. Account creation came before checkout with no payment requested, and I moved the profile form to after the purchase, where users could skip it.

02Specification

Letting each product configure its own sign-up and purchase

The platform now had to serve three products on three access models. The platform team moved out of dplay into a central digital unit, and from August 2019 I led its UX. I specified the journeys in Axure for web, iOS, Android and the TV apps, and the Auth v2 spec, published in November 2019, ran to 63 pages. Every journey was built from modules that each product could configure, from sign-up and plan selection to add-ons and payment, with in-app purchase on iOS and Android.

I defined seven user journeys for all three models, by the user’s level and by whether the touchpoint carried an entitlement label. The number of steps depended on the user’s level and the plans on offer, from three for an anonymous user choosing a plan down to one for a registered user with a single plan. A step counter showed how long purchase would take.

Answering the audit’s findings on sign-up and checkout

In the live funnel, the site navigation stayed on screen through sign-up, as I had flagged in the audit, and in the spec sign-up ran under a minimal header without it. Creating the account granted L1 access straight away, and the profile followed as a second step. Users of the live sign-up had not understood why the details were needed, so the profile step included a line saying why. Users who dropped out after the first step kept their access and were asked to complete the profile on their next visit. If the email address was already registered, the user was sent to sign in, with Facebook where the account had been created through it.

In the audit I had asked how card details were secured and what the security code was, and noted that card expiry is normally entered as MM/YY. In the card module I addressed them with a note that card details are encrypted, a hint for the security code and separate month and year fields for the expiry date, following Baymard’s guidance on expiry dates.

Offering TV users more ways to sign in

In July 2019, sign-in on the TV apps was a single page skewed towards Apple TV, while the platform served a wide range of vendors. By November I had specified seven methods, from credentials and a QR code to a one-time code and a magic link. Each product could pick its methods and their order to suit its business and its users, and land users on a default method or on a list of options.

I wrote each method as a user story with its requirements and a note on what it needed from the backend. In the QR code story, an anonymous user wants to sign in by scanning a code so as not to enter a username and password. Sign-in with credentials was fully supported and Facebook sign-in already existed in the previous version, and I flagged the other five methods for the backend team.

03Handoff

Validating shared journeys for every brand to build on

The journeys had to work for every product, and for brand teams that would design their own UI on them. I broke the journeys into self-contained modules and reviewed them weekly with the design team and the POs. We validated them in batches across sprints, until the journeys were shared and co-owned across the service. The spec was the reference for production and for the UI teams, and exceptions were documented as modules too, for user stories and developer reference.

The Eurosport design team built its UI on the journeys with my guidance where needed, and I amended the documentation from product feedback where a change added flexibility for every product. In December 2019 I documented Eurosport’s web subscription states, from pre-active to terminated, in the same format. I included targeted offers that led back into the purchase modules, from a better deal for an active customer to a new plan for one whose subscription had ended.

Sources

• Auth v2 discovery and audit boardsMiro, 2019
• Auth v2 spec ↗Axure, November 2019Get password →
• Earlier spec exportsAxure, March and July 2019June 2019 ↗Get password →
• Eurosport pre-active subscriptions ↗Axure, December 2019Get password →
• Portfolio slides ↗Figma, 2020