Discovery: Account v2

Outcome

I took the ideas of the off-boarding workshop I facilitated into Account v2. By November 2019 its off-boarding screen offered the shows coming up and a pause before a subscriber cancels. I handed over the spec for the first release, with the later phases specified before the platform could support them and the missing backend capability written on each of their pages.

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.

Working on the account area, I found that cancelling on dplay 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 designed to reduce churn while keeping pause, cancel and delete easy to reach.

Scoping what each user level could manage

What a signed-in user could do in the account depended on their user level and on where they had bought their plan. Only part of it could go into the first phase. I mapped the information architecture as a Miro mind map rooted in My Account, in one frame for P1 and one for P1 and P2. 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. I linked every leaf still in scope to the page in the Axure spec that held its screens.

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

01Stacks

Letting each product team configure the account from stacks

Each product team needed to set the account’s stacks, and their order and grouping, for its own service. I designed the dashboard as 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. In P1 the stacks are listed in one column. For P2, following usability principles for when too many stacks are in view, 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 product teams to set both on the back end according to 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, and P1 had one profile per account. The spec notes the backend was nearly ready for more. Communication preferences in P1 covered email only.

02Off-boarding

Giving dplay subscribers a reason to stay before cancelling

In the July 2019 version of the spec, the cancel screen in the plan stack had no offer yet for a subscriber about to leave. It held a placeholder upsell box, with a note that the screen would be informed by an off-boarding workshop still to come.

Alongside it, to give dplay’s own subscribers a reason to stay, I drafted three alternative cancel journeys for dplay’s 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.

Generating ideas to reduce churn

To find ideas that would improve the off-boarding experience and reduce churn, in Q3 2019 I facilitated an ideation workshop with designers and product owners. 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, as guidelines, 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.

Keeping pause, cancel and delete easy to reach

The Honest pillar’s hypothesis was that an off-boarding meant to reduce churn still needed pause, cancel and delete to be easy to find. I took the workshop’s ideas 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

Getting product teams to an MVP quickly

So that product owners and engineering could break each journey into testable stories and deliver MVPs quickly, I handed the spec over as annotated Axure pages, one per stack. They had numbered callouts on every 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 the platform’s neutral placeholder brand, 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, and two of them were already on the platform’s roadmap. The last two were phased for later releases.

Sources

• Off-boarding workshop and account mind mapsMiro, 2019
• dplay cancel and pause drafts ↗Axure, July 2019Get password →
• Competitor scan: Netflix, Amazon Prime and MUBIScreenshots, 2019
• Account v2 spec ↗Axure, March 2020Get password →