WWE Network: Native apps

Outcome

The UX specs for these apps became the standard UX architecture format for AXIS projects, with coded flows, numbered screens and journeys mapped from a user’s access level and entry point. The native journeys were the base for the other platforms’ UX documents and for the native UI. The app was very successful with WWE users, and its ratings rose on iOS and Android.

Context

WWE Network combined a 24-hour linear channel, the weekly shows and pay-per-view events with an on-demand library, in the same app as WWE’s news and results. Anyone could browse the app and watch short-form video and the pre-shows of live events, and the rest needed a subscription.

Massive specified Network 2.0 separately for the native apps, responsive web and TV. I covered iPhone and iPad, and Android phones and tablets. AXIS let a broadcaster launch a full VOD service in a short time. The brief was to use its modules wherever WWE’s content fitted them, and where it did not I offered alternatives WWE could agree to.

Organising WWE’s programming under one watch tab

The engagement opened with two days of client workshops in Connecticut in May 2018, followed by concept decks in June. On 13 July I shared a native document for review, with the site map, breakpoints, grids and tiles, native navigation for iPhone and Android, and two options for the home feed.

In the site map, v1.0 of 4 July, I put WWE’s programming under one Watch tab, from Featured and the pay-per-views to Raw, SmackDown, NXT, In Ring, Originals and the schedule. One player and detail page had variants for pay-per-view episodes, Originals episodes, clips and playlists.

Rendering the editorial feed natively

The Home tab showed WWE’s editorial feed of news, galleries, clips and playlists, and in July I put two ways of building it to review. The first loaded wwe.com’s home page in a webview, without the site’s header and footer. Each link opened a full-screen webview, and we agreed in review on a Close button in its top bar, to set it apart from the browser’s Back button at the bottom. I noted the assumption that any page opened from the feed, WWE’s own included, would keep its site header and footer inside the app, and asked for a correction if it was wrong. The second option rendered the feed in the app from a data source such as a JSON feed, and opened its links in a separate webview.

In both the November and January exports, the home feed is marked as in the backlog.

01Design

Following each platform’s conventions on phones and tablets

Users needed to move easily between the main content sections on every device class. In P1 I drew each page for the four device classes, and for both orientations where the layout changed, on grids and tile rows set for each class. Navigation followed each platform, with links to Apple’s and Google’s guidelines on the page. iPhone and iPad used native tab bars, and the Android bottom navigation replicated them on specs from Massive’s UI team. Sections with several shows, such as Network, used scrollable tabs along the top, and the More menu was a table view on iOS and a list on Android.

Playback had to work on every device class and on the TV through casting, so I specified it for each, with Chromecast sender flows for Android and iOS and the receiver, AirPlay as Apple’s standard flow, and a limit on concurrent streams that paused the oldest stream first.

Keeping the spec traceable across sprints and change requests

Delivery ran in ten sprints, and each week I reviewed the work with WWE’s product and design teams and Massive’s product team. Each flow in the Axure spec has a code, LOG for sign in and CWA for account creation, and each screen a number within it, such as LOG 01-02 for the email field in focus. When WWE changed the sign-up flows through a change request, I kept the previous diagrams in the spec as v1 and linked them from the new ones, as the reference for testing.

Routing each user level to the right sign-up or upgrade

Users came across locked videos in many places in the app, signed in or not and on different plans, and each needed a way on to the plan that unlocked them. Access depended on four user levels: an anonymous user (L1), a free account (L2), and the Premium (L3) and VIP (L4) subscriptions. I mapped twelve journeys in the sign-up and upgrade diagrams, each from a user level and an entry point, such as the first launch, the More menu or a locked video, to a goal level. Across the app, a locked item showed Upgrade to watch in place of Watch and opened the journey for the user’s level.

Upgrades also depended on where a subscriber had paid. Only a Premium subscriber who had paid through the app’s own store could upgrade to VIP in the app. Subscribers who had paid on the web, by card, PayPal or prepaid card, or through another store were referred to the web to upgrade.

Routing Canada and the Middle East to Premium through TV providers

By early December WWE had raised a change request, as a Jira ticket, for customers in Canada and the Middle East to join Premium only through their TV provider, with acquisition flows of their own for those regions. In the November state, TV Everywhere had been one page and a link on the sign-in screen for customers subscribed through a TV provider, with a note that Adobe Primetime authentication worked only in those two regions.

To produce the TVE flows the change request needed, I branched the Rest of the World flows into a TVE branch in the same spec, reusing as many flows and screens as I could, and colour-coded each flow in the branch as unchanged, slightly changed, significantly changed or new to TVE. In the branch, a native list of providers led to the provider’s own sign-in in a webview under a bar with a Cancel button, and a success token then granted Premium or left the user browsing on a free account. VIP content, which no one in those regions could buy, showed a message that it was not available there. For the same request I added a Create account link to the sign-in screen, and asked for it in both branches to keep them consistent.

Showing the right action for every content type and state

What a user could do with a video depended on its content type, on whether it was live, on now, partly watched or still to come, and on the user’s entitlement. In section 06 of the spec I set out WWE’s catalogue as three blocks, the metadata box on detail pages, the hero and the tile, each by content type.

The heroes matrix covers twelve types, from weekly and legacy In Ring shows to Originals, pay-per-views, clips, shows, playlists, superstars and promos, in their default, On Now and Live Now states. The Watch button reads Watch, Resume for a partly watched video longer than ten minutes, Upgrade to watch without the entitlement, or Preview for an event coming up. Tiles follow the same types, with states of their own for news and photos, the schedule, continue watching, now playing and watched.

02Handover

Writing a spec the UI team and developers could build from

Massive’s UI designers and the developers needed to see each layout and behaviour before building it. For the handover I documented every screen and behaviour variant for them, by device class and orientation. Where a layout was the UI team’s call, I said so on the page, marking the tablet columns of the schedule and the edit mode list as recommendations, and leaving the final styling of search, transparencies included, to the UI team.

Section 03 of the spec is the component library, from forms, error views and snackbars to modals, selects, a sort panel and a bottom sheet, most drawn for phones and for tablets in both orientations. I noted on each component page how it behaves and where it is used. Error views, for example, fade when the user taps close or anywhere outside, and appear in the sign-in, reset and sign-up flows.

Sources

• Native apps spec ↗Axure, July 2018 to January 2019Get password →
• Review document ↗Axure, 13 July 2018Get password →
• Portfolio slides2020