Discovery: Access, registration and entitlements

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.

Auditing the live funnel

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

Defining user levels and entitlements

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). On the live product, a signed-in free user and a subscriber saw much the same interface.

I then proposed what each level would offer as a reason to upgrade. I drew a task chain on a seasonal show, after the Zeigarnik effect, with box sets open to everyone, the current season for registered users and the latest episodes for subscribers. A feature matrix ran 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.

Benchmarking access models

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. Netflix covered in three journeys the scenarios that Sky’s NOW TV spread over five, and I recommended Netflix-style journeys for dplay’s account area, on existing UI patterns.

Simplifying to three access models

Separating registration from purchase

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, each entry point offering a single choice, and 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 the profile form moved to after the purchase, where users could skip it.

02Specification

Specifying modular journeys

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 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 level, from three for an anonymous user choosing a plan down to one for a registered user with a single plan on offer.

Sign-up ran under a minimal header, without the site navigation I had flagged in the audit. Creating the account granted L1 access straight away, and the profile followed as a second step, with a line saying why the details were needed. 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 card module I answered the three questions I had raised about the live checkout, 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.

Signing in on connected TVs

In July 2019, sign-in on the TV apps was a single page skewed towards Apple TV. By November I had specified seven methods, from credentials and a QR code to a one-time code and a magic link, and each product could pick its methods and their order, landing 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 backend support. Sign-in with credentials was fully supported and Facebook sign-in already existed in the previous version, while the other five methods were flagged for the backend team.

03Handoff

Handing over to the brand teams

I broke the journeys into self-contained modules and took them through weekly reviews with the design team and the POs, validating them in batches across sprints. 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, with targeted offers that led back into the purchase modules.

Outcome

By my account in 2020, the journeys were the basis of Eurosport Player’s authentication when it moved in-house from an external vendor. On dplay, registration became required before playback, and by the same account registered users rose sharply.