Our primary goal was to offer a more engaging experience for users. BR has recently developed “Game Companion”, a new data-driven technology that automatically translates real-time game statistics into sport insights. These insights could be record-breaking actions in the game, players’ career or team milestones. The new live score dashboard was designed to accomodate this brand new “Smart Play-by-Play” feature.
1. Single page scrolling
The previous live score dashboard was integrated within a single-page scrolling framework of a team page. This design was driven by the native “Stream” format of Team Stream. So it was important to leave the social media feed layout minimally altered to preserve the main functionality of the app, instead of confusing users and wasting resources on a structural redesign.
2. Prioritisation of features
With the introduction of a bunch of new features, there was limited real estate for the visibility of content, especially in the front-page dashboard. So the main challenge of this project was one of information architecture.
3. Visual consistency of Native View
Team Stream is a strongly hybrid mobile app with many webviews alongside Native UI views. Considering how to leverage our architecture and native designs was key to providing a more engaging and consistent visual experience.
4. Incremental improvement
The company’s cost-efficient and agile development approach meant avoiding the risks and costs of a radical redesign for this MVP release. The solutions should be simple and seamlessly integrated so that our users feel at home and naturally adjusted to BR’s new features.
1. Rework the navigation
Introduce an internal navigation bar (at the top for iOS and bottom for Android), which includes three navigation items: “Team Stats”, “Live” and “Player Stats” to separate Live game information from the Team Page items, making game data super accessible.
2. Redirect to a separate page
The “View all” option now redirects user to a new page, replacing the vertical expand/collapse model. This provides more space for keeping track of all updates without losing the sense of information heirarchy. Also, this navigational variation added some flexibility to the one-page scroll framework.
3. Use a module design pattern
Each new functionality would be built out and embedded in the app as an individual webview. A module design pattern is a good way to package all the webviews and present the different features in the consistent style of Team Stream’s native UI.
Original Design vs Competitors
I carried out an in-depth analysis of our current live score page in comparison to ESPN’s mobile Gamecast. Although ESPN’s recently revamped app provided the most comprehensive and useful features in the market, it was overwhelming to use and not conduicive to data discovery. While Team Stream provided less content and interactive items, our unique social media driven design offered a more streamlined and user-friendly way to engage. As this project aimed to add more functional components to this simple framework, we needed to put usability first and steer away from ESPN’s feature-heavy, unintuitive approach.
Preserving the home feed layout meant that design changes could only be subtle and structural changes as minimal and incremental as possible, despite the addition of many new functionalities. The logic behind Team Stream’s traditional fixed one-page view was that only relevant information should be presented to the users without them having to look through a cluster of interfaces. This was however problematic for those who want more freedom to explore information and dive below the surface of the current play-by-play review.
Map out the Content
The need to maintain the fundamental components of the app provided me with an opportunity to rethink navigation possibilities. Before attempting to design a new navigational system, I gathered and mapped out all of the available data assets. Then I created a content inventory by looking at raw data sets presented through our api during a live MLB game. The diagram shown in the image on the left below presents the data structure on the current live score page.
Talking to the senior PMs gave me a clear idea of what data we currently own and will be able to acquire or build natively in the future. To help develop a content strategy, I made a little group map showing all the available options of data to be used. Red indicates the features already existing on the current live game page, blue shows the features which we were planning on building out natively, green shows the “graphic” feature whose production was still in debate, and gray indicates low priority.
Selecting and prioritising the numerous data we had was a real IA challenge. With constrained screen space, I had to narrow my use case to the most relevant to the user and define the minimum UI necessary to accomplish these use cases. For example, we discussed how useful of a field chart would be for game followers as a visual aid. By the third design sprint, we dropped the field chart, deciding that its benefits wouldn’t outweigh the development costs, at least for this release.
In rethinking the navigation pattern, I examined two possible approaches: flatten the structure of information hierarchy or preserve its depth. Previously, the users were unable to expand on the Play-by-Play box, which was frustrating if you wanted to review what was happening in the past minutes or quarters. The “Broad & Shallow” model addressed this issue by redirecting the user to a new different page that contains a full list of either Play-by-Play or social media updates. The potential drawback of redirects was that users might be disoriented to where they were relative to the entire app. The “Deep & Narrow” model, on the other hand, relied on a more logical system of sequence and seemed more intuitive to first-time users. I adopted this method as a foundation to my first design iteration.
My first attempt concentrated on how users look for information. Taking the “Deep & Narrow” approach, I utilised an “expand and collapse” system to single out the most important information and provide users the ability to immediately spot whatever they’re looking for upon landing. By directly presenting an overview of all features and options on the home screen, we avoided the problem of superfluous tabination that ESPN faced.
However, having a little bit of everything in one place might cause the users might feel instantly overwhelmed on first impression and so have to spend extra time looking through everything before making a choice. Expanding and collapsing parts may also requires as much redundant action as going through a row of tabs.
To avoid the consistent hassle of having to expand/collapse content, I introduced horizontal navigation by adding a right arrow to each banner or section, indicating a “View all” option. I had tried to avoid mixing the horizontal and vertical navigation systems for the sake of consistency and predictability. But since redirects were limited to only one page, this was a reasonable trade-off.
Final Iteration and Trade-Offs
1) The final iteration dealt with the problem of confusion, in which there were two nav bars on the same screen; the primary one at the top and the secondary one directly below. Our solution was to fix the secondary nav bar to the bottom of the screen. Still, the lack of stylistic distinction between the two nav bars on the same screen presented a problem. This was one of the logical trade-offs we made in favour of visual consistency and will need to be resolved in the next rollout.
Unclear Labelling of Features
2) A trade-off that I thought we could have better addressed was the structure and labelling of the navigation items. The “Team Stats” page on the left shows both the matchup game stats and “Game Summary” yet for convenience’s sake, the tab was labelled Team Stats. Although “Summary” or “Recap” made more sense to me, I recognised that it’s more important to be specific than 100% accurate to highlight the most important features.
3) Cramming the team stats visualisation and game summary together in one page was a poor yet viable solution in the context of our first release. Tossing in game summary was a late and sudden decision. Otherwise, I would have put the Stats bar charts on the same page as the player stats and give Game summary its own space to be explored.
Design variation: soccer is tremendously different from football and basketball in terms of data collected. While keeping the same information structure, I adjusted content and design to fit the context of soccer.