Discovery: Account v2

Context

Discovery was building one streaming platform on dplay’s codebase, to launch services in several markets quickly and test new products on it. I led UX for the platform from August 2019, as its only UX architect. Sign-up and entitlements came first, in Auth v2. Account v2 covered what a signed-in user manages after that: credentials, plan and add-ons, billing and payment, preferences, and their data.

On dplay, cancelling fell short of both customer experience and business expectations. The goal was an account area each product team could configure for its own service, and an off-boarding that aimed to reduce churn while keeping pause, cancel and delete easy to reach.

Mapping the account IA

I mapped the information architecture as a Miro mind map rooted in My Account. The first branches covered credentials, sign-out, data download and account deletion, and a profile limited to first name and interface language. Below them the tree split by user level: L1 users could buy a plan or reactivate a lapsed one, and L2 users split by purchase route, with in-app plans managed through the app store. Every leaf still in scope linked to its page in the Axure spec.

Last name, age and gender are struck through in the profile, as is third-party consent in communication settings, and the plan name, service period and receipt on the next and last bill, though billing history keeps all three.

01Stacks

Building the dashboard from stacks

The dashboard is built from stacks, each a card for one goal, such as changing a password or updating a payment method, with its flows behind it. The principles on the spec page were to keep it simple, modular and flexible, and focused on user goals. P1 lists the stacks in one column. For P2 I grouped them under four tabs (account, subscription and billing, promo codes, privacy) as in-page navigation, where a tap scrolls the page to the group. I based the order and grouping on competitive analysis, and left both for product teams to set on the back end, following user insights.

Each stack page states who can see it, by user level and purchase route. Credentials follow the account type: an email account edits them, a Facebook-only account can add an email and password, and an account linked through a pay-TV partner cannot change its email here.

Phasing to what the platform supported

Four features in the spec needed backend capability the platform did not have yet: parental controls, pause, devices, and switching between monthly and annual plans. Parental controls were also a legal requirement in one of the markets.

Multiple profiles stayed out of both phases, with one profile per account in P1, although the spec notes the backend was nearly ready for more. P1 also limited communication preferences to email.

02Off-boarding

Drafting cancel journeys for dplay

In the July 2019 version of the spec, the cancel screen in the plan stack held only a placeholder upsell box, with a note that the screen would be informed by an off-boarding workshop still to come.

Alongside it I drafted three alternative cancel journeys for dplay’s own account page, published to the dplay workspace in August. Option A listed the shows coming up that users would miss, option B offered a pause, and option C offered a cheaper plan. In each draft I listed what it needed from other teams: an editorial schedule of upcoming shows for A and B, pause capability on the backend for B, and new plan options from the business for C.

Reasoning from the brand pillars

In Q3 2019 I facilitated an ideation workshop with designers and product owners on improving off-boarding and reducing churn. On the Miro board I first defined the three flows. Pause gives subscribers a break from paying, cancel ends the subscription, and delete removes the user’s data from the service. Then I took the four brand pillars in turn and wrote the hypotheses each one implied.

The last frame on the board is about re-engaging users just after they cancel. For the competitive scan I picked Netflix, Amazon and MUBI, because all three rely on customer data yet built very different experiences. Every idea was to be judged against the Auth v2 design principles: simple, modular, flexible, goal oriented.

Designing pause, cancel and delete

The workshop’s ideas went into the plan stack of the Account v2 spec. Manage plan links to pausing or cancelling from its first screen, and from P2 it offers the annual plan with its saving. The link opens one off-boarding screen: the shows coming up and a button to keep the plan, then a pause box and a cancel box, each listing what happens next.

Pause offers two, three or six months, as a configurable set, and the dashboard then shows the plan paused with its restart date. A cancelled plan stays on the dashboard with a link to resume it. Annual plans got no pause, since cancellation rules for annual plans were already complex in some markets. Deleting an account follows the user level: an L1 account goes at once, while a subscriber’s account and data go when the plan ends, with a banner offering to keep both.

03Handoff

Specifying for product and engineering

The spec went to product owners and engineering as annotated Axure pages, one per stack, with numbered callouts on each flow screen, form states, the key screens at four breakpoints, and write actions traced to their backend responses. Account v2 was web only in this build. Between the July and November 2019 versions it moved from dplay’s skin to a neutral one, and gained the data, EU portability, devices and parental controls stacks. Legal still had to give feedback on the invoice, and for watching abroad it asked for the user’s home country to be verified by card.

In a January 2020 draft I turned the credentials stack into account details, adding a mobile number and a postcode, and drew two journeys: a change link beside each field on the dashboard, or one edit link that opens the stack. In the March spec I kept the first, behind the same password check, and added states for accounts created by SMS and for services that need a postcode.

What was held, and what was handed over

The first four waited on backend work, two of them already on the platform’s roadmap, and the last two were phased for later releases.

Outcome

Account v2 was handed over as the P1 spec for a first release, with the P2 and P3 stacks specified ahead of the platform.