DAZN: Navigation v2

Outcome

The native tiles documented in the new navigation became the standard tile pattern on every platform, from the web to connected TVs. Navigation v2 got excellent reviews on the App Store, where it went live first, and DAZN then rolled it out to Android and the responsive web.

Context

Navigation and browse in DAZN’s first release came from a creative agency’s deliverables. In the release spec, the schedule, every sport, the account and help sat in one overlay menu opened from the header. In usability testing in Japan in March 2016, most participants did not notice the menu, and they found the list of sports only by scrolling to the last rail of the home page. Users in testing also expected the navigation on phones and tablets to follow the device’s own interface.

Following and downloads were due to be added after launch, along with a new schedule, and the navigation already differed from one platform to the next. The goal was a consistent navigation across every device DAZN ran on, with quick access to content and room for the new features. As with all our browse and discovery work, we measured success by conversion, retention and successful viewing sessions, and by what customers told us through customer service, app store reviews, surveys and testing.

01Discovery

Putting watching first in the information architecture

To give users quick access to content, I based the new navigation on how they grouped what DAZN offered. I gathered what was wrong with the live navigation from alpha testers’ feedback and user test sessions, then ran an open card sort and tree tests with users. The card sort fell into four clear areas, Watch, Preferences, Account and Support, which I organised as a labelled tree with Watch as the main focus. Users need legal pages, language settings and help only at specific moments, so I kept them out of the Watch experience, with help still offered in context when a problem came up.

From the card sort and the data we had, we ranked three user priorities, with engaging content first, managing the account and getting help second, and the legal pages and SEO last. We used the ranking to decide what took a place in the main navigation and what sat a level below it.

Benchmarking the navigation users already knew

DAZN’s apps, like Netflix’s at the time, used burger menus on both platforms, and users in testing expected the patterns of their own devices. To see what navigation people were used to on their phones, I benchmarked 20 of the top free apps in the App Store, all rated 4 stars or more on both stores, along with their Android versions and mobile websites. Most of the iOS apps, 12 of the 20, used a tab bar, usually at the bottom of the screen, while most Android apps used a burger menu and put any tabs at the top. Seven of the 20 had no mobile website.

I drew three concepts that applied these findings to iOS, Android and the web at phone size, and we ran quick concept tests on them as prototypes.

Focusing mobile resources on native apps

The leadership team accepted the case and hired in-house native developers. The native developers built the new apps on a separate branch, so we could release the new navigation on the native apps first, test it with users there and take what worked to the other platforms.

02Design

Following each platform’s own navigation patterns

To match the patterns users knew on each device, by September 2016 we had turned the concepts into one structure with a pattern for each platform. The iPhone design had a bottom tab bar with Home, Schedule, Sports, Downloads and More, and the Android design kept a burger menu, with Home, Schedule, Sports and Downloads as tabs at the top. On the web at phone size a drawer held the account, settings, help and legal pages, and on larger screens they moved into a My DAZN menu at the right of the top bar. Sports had taken the place of Following as a tab, and led from the list of sports to each sport’s leagues.

In the final iPhone and iPad designs of December 2016, Sports leads to a sport, then a tournament, then a team. Each of those pages shows its live and catch-up events, DAZN’s picks and a rail for the level below. Search groups its results by sport, tournament, competitor and event. More holds settings, the account, help and the legal pages, the second and third priorities, away from Watch. I tested the navigation in guerrilla sessions and with alpha testers before its release on iOS.

Making an event’s state and time clear on every tile

Users kept raising problems with the first release’s tile, whose stack of several boxes, repeated dozens of times on every page, added clutter and cognitive overload. Coming-up and catch-up events differed only by a subtle colour code. The original designs did not allow for some types of content, which the live tiles could not explain, and each fix for them added more clutter. A date was two pairs of digits, so 02 03 meant 2 March, and long titles were cut off by a label of fixed height. In testing, users also could not tell whether the time on a tile meant the start in Japan, the local start or the length of the match, and labels such as Catch up confused them. Downloads needed the same tiles as the home page, so I took these problems on while designing it.

I redesigned the tile as one component that shows what an event is, when it is on and whether it can be watched. It puts fewer, more flexible data points over a 16:9 image: the competition and a time relative to today, then the event, then its state in words, such as Live in 20 mins, Highlights available, Catch up available on Sunday 21 or Postponed. The same component has a state for each stage of an event, from coming up to live, catch up and highlights, and variants for mobile, desktop and downloaded videos. It did well enough in testing and internal workshops to replace the original tiles across the service, on every platform.

03Release

Keeping the build consistent across teams in two countries

The native apps were built in Poland, and the web and TV in the UK. There were no design sprints, so I worked with the teams through reviews, test sessions and time on site.

For the developer handoff in January 2017, I prepared the responsive web at five breakpoints, from the home page through Sports to a team page, a first pass at the TV home and player, and the tile specs for iPad. The specs set tile sizes by screen width, with one full tile in view on a phone and two or more from 600 points.

In June 2017, after the Android v2.0 build, I specified UI fixes to fonts, margins and tile sizes for every Android phone and tablet. For Android v2.1 I moved the tabs to the bottom of the screen, as on iOS, in line with Material Design’s bottom navigation.

Keeping every tile in one place for every platform

With tiles inside the navigation files, every tile change would have meant updating the navigation for web at three breakpoint groups, iOS, Android and TV. Android developers updating the schedule had also built an old tile design that the schedule file still showed. To keep each tile change in one place and stop developers building tiles from the navigation files, by the handover in September 2017 I had split navigation and tiles into separate Sketch files, with all the tile components together, and left the tiles in the navigation files blank.

Each project had its Sketch file, an InVision prototype and its screens in Zeplin, indexed by device. By then both native apps had the second version of the tiles, and v2.1, without the black background under the labels, was implemented on Android and in progress on iOS.

Letting users filter the schedule by sport

Once the first native app was out, users asked for a way to browse the schedule of events and filter it by sport. After designing and testing the schedule on the apps, I tested its sports filter on site in Japan, with four or five Japanese users per session and a Japanese-speaking product owner, and changed it between sessions through the week. The flow had to let users find the filter from the schedule, apply one or more sports, cancel a change, clear every filter, and go back to the schedule as they last saw it. We also used the filter tests in Japan to check the use of Japanese fonts.

After release we kept testing with users, either existing customers or, in a new market, people from its likely audience. In July 2017 we ran research in Japan, testing the live iPhone app, version 2.0.4, against two newer iterations built as InVision prototypes.

Sources

• Navigation presentation for the leadership teamJuly 2016
• Navigation and tiles files, v1 to v2.1Sketch, 2016 to 2017
• iOS presentation to AppleJanuary 2017
• Developer handoff and handoverJanuary and September 2017
• Research in JapanJuly 2017
• Portfolio slides2018 and 2019