More selected projects

A not-so-short story about the redesign of the content card for the streaming service

Content
Card

Reading time 15 min

content-card-1content-card-1

IVI is the leading streaming service in Russia. Like Netflix, but smaller. The monthly audience of the service is more than 40 million people. The service works on a variety of devices: web, smartphones, Smart TV, Android TV, Apple TV and game consoles.

A content card is a page of a movie, series or cartoon in the service. Of course, this is an important part of the user flow. I redesigned the page as part of the videofication strategy, solved some old problems, improved the visual and prepared the card for the further development and new experiments.

Within the framework of the project, I was the only product designer from the moment of concepts to rolling out after the tests. However, the result of the work is the result of extensive and close communication within the team, with other designers, product managers, the development team and project stakeholders.

Chapter I

Problem Formulation

Background and concepts

IVI takes regular UX research of our product and competitors. As part of these researches, we test the main usage scenarios of the application and compare the usability of these scenarios with competitors.

Based on the results, we observed that the content card was scoring progressively lower scores compared to its competitors. In addition to this, other problems were accumulating. The number of complaints to support and technical debt was growing.

content-card-2content-card-2

Screenshots of researches with problems related to the content card

With this background in August 2020, as part of the work on the product strategy, we began to work on the concepts of the content card. At that time, we did not work out the problem in detail — we will do this later. At that moment, we concentrated on conceptualizing the card of the future.

After this exercise, we postponed the project for a few months and after that, we returned having already validated our hypotheses and problems.

content-card-3content-card-3

First concepts of the content card for different platforms in 2020

Analysis of problems and hypotheses.
Validation.

While collecting information about issues related to the content card, we took into account:

  • All the latest product UX research;
  • Requests from support;
  • Existing competitor solutions;
  • Task requirements from stakeholders;
  • Current features that have not been implemented in the content card on all platforms;
  • New features that were in progress and the foreseeable future (up to 1 year) will be included in the new card;
  • Platform restrictions, as well as restrictions on the content that we can use in the design. It's about texts and images;
  • We also researched how users generally choose movies. Based on what they decide to watch;
  • In conclusion, we collected all the hypotheses that have accumulated over the past year and a half in the product and design.

Formulated problems and hypotheses

As a result, we have accumulated about 20 problems and hypotheses with different levels of complexity. If we sum them up, we get three volumetric categories:

Trailer and visual design

We knew from research that the trailer was well engaging, however, on the old card, the trailer ended up being overlaid with information and text, or only available on click.

Smart TV had trouble understanding how to play the trailer.

As for the visual, we did not use title logos, and the background image was overlapped by text.

New features

We have implemented a lot of new things in the product: match, title awards, and editorial descriptions of films, but they were not presented in the content card on all platforms.

Further experiments were planned and we wanted to understand where to place them.

There were complaints from users to support some of the metadata.

Series and navigation

Working with the block of seasons raised questions. On all platforms, episodes and seasons were placed in one small gallery.

As for navigation. On mobile phones, you constantly had to jump from catalog to card. On TV all information was placed on one page.

On mobile phones, it was difficult to understand whether the series was available for download.

Chapter II

Problem 1
Trailer and visual design

Mobile applications

We started with mobile applications. We kept consistency in mind, but each platform has its limitations, audience, needs, and cases, so the implementation is different in detail.

content-card-4content-card-4

Journey from the original version of the card to the final one. Major versions.

Since we were strategically moving towards video content delivery, we wanted to make it easier and more convenient to show the trailer. We considered the option of a static juicy cover, but since, according to research, the trailer is better involved in viewing, we decided to change the vector. For a more emotional presentation in the card, we decided to use something similar to the underlying bias lighting, for example, Ambilight in Philips TVs.

Smart TV

The implemented screen format on Smart TV has already become a kind of industry standard. We've repositioned the content, softened the background gradient to make the trailer more enjoyable to watch, and added a seamless transition to the trailer after a while.

content-card-5content-card-5

Working on options for the application on Smart TV

Web

Initially, on the mobile web, we focused on a visual similar to Smart TV. Beautiful, large cover, which then goes into the trailer. But we ran into several obstacles that forced us to reconsider the decision radically.

content-card-6content-card-6

Working on options for the ivi website

Firstly, IVI works not only with a subscription model of monetization, but also with advertising. This is how we allow a large audience of users to watch a limited catalog of legal content for free. In the advertising model, the player is an essential part of the advertising inventory, which means long-term advertising contracts with documented areas. Our changes would lead to the revision of all these contracts.

Secondly, SEO and search engines is a significant part of attracting new subscribers and new users. And search engines have their own requirements about structure of the page. Because of this, we, for example, had to refuse the logos for non-subscribers.

Thirdly, the code of the video player on the web was organized somewhat differently than in other client applications. Therefore we finally decided to stay with the player as a separate window. However, we improved the position of the video on the screen by only slightly reducing its size.

In the next part, I will talk about a few, major decisions that have been made for different platforms.

Chapter III

Problem 2
New features

Mobile applications and Web
Meta and Medallions

We conducted small research and analyzed, based on what data users choose a movie to watch.

content-card-7content-card-7

Users' answers to the question "What do you usually pay attention to while choosing a movie?"

Based on these materials, we slightly reassembled the metadata. We wanted to somehow provide information about the actors, as well as new functionality — an analog of the Netflix Match. At the same time, we did not want to present this information too dryly. So we have a new block, which we internally call "Medallions".

This is the block with the most important meta-information about the content. And both with what is important in general, and personally for the user.

The first is the content rating, the actors playing the main roles. The second is the Match, and those characteristics of the content that are interesting to the user.

For example, if a user watches a lot of French films, then we can display this feature in medallions, immediately drawing attention to the fact that this film may be of interest to him.

Mobile applications
Main buttons

The content card is complex. It has many stakeholders. For example, the video player is a separate product unit with its own team. Match and explaining of content is also a separate product with a machine learning team. Texts, logos and graphics are the responsibility of the editors. The Buttons are the unique unit as well. It is owned by the Paid Model team that works on the subscription issues.

Previously, the buttons were placed one below the other. We decided to put them in one row to save the space. We had to rebuild the buttons, and collect documentation for all possible types of buttons, for which, as it turned out, there was no documentation and no one knew all the cases.

content-card-9content-card-9

We collected documentation for all possible types of buttons

Smart TV
Block with additional information

As I said above, we had a lot of new experiments and features in progress. We decided to allocate a separate place on the content card for new features. It is suitable for secondary, additional information while deciding about watching the content. We had quite a lot of such experiments.

content-card-10content-card-10

Different views of the block with additional information on Smart TV

Chapter IV

Problem 3
Series and navigation

Mobile Apps
Navigation

An important point while developing the design was that it takes a little time to study the card itself, but after that, if the title doesn't fit, the user had to go back to the catalog each time and move on to the next movie.

Our goal was to remove these unnecessary transitions. Make such a card so that the user on the first screen receives all the necessary information, and if the title does not suit him, then he could move to the next one in one motion.

content-card-11content-card-11

Content cards can be switched by swiping left or right

Mobile Apps
Block Series

One of our biggest mistakes is the block of episodes and seasons on the content card. The idea was to always show three episodes — one episode that you are watching now and two episodes following. 

The logic was simple — you ideally don't need episodes that you've already watched. And also, you probably don't need episodes two seasons ahead. If you need, there is a button "All episodes" which will show you a bottom sheet with a convenient display of series.

content-card-12content-card-12

Block of episodes on the content card and bottom sheet with all episodes

Everything broke because we didn't research the issue enough. It turned out that users quite often used this block to launch content, and after our changes, it became inconvenient to do this. As a result, the conversion to watching TV shows sank. We are planning to do another approach to this problem later.

Smart TV
Series and Navigation

We slightly complicated the navigation, and added tabs, where we laid out the information on different shelves. We did this because it is more important for the user to navigate through episodes and seasons on the page. We are going to experiment with the position of these page subsections.

content-card-13content-card-13

Different tabs in content card navigation on Smart TV

Smart TV
Full Screen Gallery

It is no coincidence that we made a new content card like this. The next step in the development of the content card on Smart TV was the appearance of a full-screen gallery in the catalog. There is not much to say about this solution as it is industry standard, however, the transition to this standard became possible only after the redesign of the content card.

content-card-14content-card-14

Full Screen Gallery on Smart TV

Chapter V

Other details

Web
SEO, Headlines, Appearance, and Ads

In addition to the standard interface that we did, it became necessary to also provide additional states. Namely: to think over ad impressions on the web, as well as to work out very important issues of content SEO optimization, which, by the way, quite strongly influenced the final format of the card.

We are faced with the fact that SEO content titles often contain additional information useful for search queries. This greatly lengthened the headlines, some of them reaching truly enormous sizes. We wanted to keep the card visually pleasing, so we had to implement a heading size mechanism. In mobile devices, such things are organized quite simply, but for the web, I made an algorithm that determines the length of words and the number of letters in the title and, depending on these two parameters, determines what size the title should be for each text resolution. The algorithm worked as it should, but maybe I got a little carried away with the number of options.

content-card-16content-card-16

An algorithm for determining the size of a header on the web

Web
Encyclopedic card

A separate task was the development of the so-called fake or, as we call it, an encyclopedic content card, which will contain much more information than a regular card. This is a content card for the content which is absent on IVI. It is close to Wikipedia. It contains more meta-information about the title, there may be additional data, photos, and text descriptions for episodes. It is essential for SEO.

content-card-17content-card-17

Details of an encyclopedic SEO content card

Handoff. Documentation

It was not possible to draw different states of each page block in separate screens. But it could be done within the documentation. In the documentation I described:

  • The behavior of each element, as well as all the necessary logic, a description of the algorithms;
  • Correlated the elements of each block with variations of the Design System components;
  • Made adaptive blocks, including their various variations;
  • Gathered a specification including padding between blocks and other details.


We also collected technical documentation in confluence, in which the assembly of blocks was described from the side of the backend and information from requests.

Communication

At the design stage, at the peak, we had about 12 people with whom we approved the results. In addition to colleagues and my immediate supervisor, the team also included product managers responsible for various details of the content card, as well as heads of the product department. The number of people was substantial and iterations were frequent.

It was impossible to get the whole team together every day for discussion, so I decided to use looms to record progress. The videos were a much better representation of my thought process and argumentation, and they could be viewed by all team members at any convenient time. In addition, the history of changes was saved.

I can't say that this is a suitable solution for the usual quiet work on a project with a small team or offline work. But for fast iterations in a large project team in a remote environment, this turned out to be a great solution.

Chapter VI

Results

Run and Analyze test data

Before launching AB testing, we conducted internal UX testing of builds on respondents. The results were encouraging. Users went through all the main scenarios well and in direct comparison, the new card won by a large margin on all platforms, so we started testing.

content-card-20content-card-20

Results of a direct comparison of content cards

We launched platforms with a gap. We got the first statistically significant results already after 3 weeks on the web. The news was bad and good. On the desktop web, everything was generally good, but on the mobile web, we were surprised. The changes with the trailer were not in vain, trailer views increased by ≈50%. However, this increase did not give the growth in viewing that we expected. The metrics sank but only for non-subscribers. We started to figure it out. We collected detailed statistics on screen resolutions in order to understand on which devices we had the most problems. We also collected video recordings of user screens from Hotjar. We found a few bugs:

  • Firstly, we didn't take into account a rather large number of banners that we had on the card of an unlogged user.
  • Secondly, we did not take into account the size of the browser interface on small devices.
  • Thirdly, in applications, we have disabled the operation of the application in Landscape mode. On the web, it works because it's a regular browser. And our screen in this mode had significant drawbacks.
  • Fourth, we found out that primary information about the content is extremely important for users on the mobile web, as they get to the content card directly from the search results and want visual confirmation that they are in the right place.
  • Fifthly, we did a little research and realized that when unauthorized users get to our website, they perceive the player window from above as an advertising banner, because it is common for pirate sites to place advertising banners from above.

Having corrected all these shortcomings, we managed to correct almost all the fallen metrics.

On other platforms, we also made minor adjustments, but there were much less drawdowns, possibly due to a more loyal audience. One of the most significant changes is the return of the old episodes block in mobile applications, since the new block did not perform well.

Results & Final words

The card was rolled out 100% on all platforms. Globally, if we count in aggregate across all platforms, this experiment ended in a plus for us. I can't show you specific numbers, but the new card performed best on global metrics on Smart TV, mobile web, and apps. The desktop web looked worse at the time of rolling out, but we have plans for further work on a new card and new experiments.

content-card-22content-card-22

What we have learned in the process

The obvious conclusion is that you should not try to implement everything at the same time, especially when it comes to a complex product with a large legacy:

  • It's unclear what affects on what.
  • Difficult to approve with a large number of stakeholders
  • Long to develop
  • The return is not always comparable to the effort put in.
  • For every change in any block, research is needed. However, due to the large number of changes at the same time in one place, the whole flow of using the product can change. The reaction of users becomes difficult to predict.


Detailed documentation in Figma is extremely convenient for developers, however, it is necessary to allocate time for its development and possible improvements in the future, since everyone will be guided by it.

You should always set aside time and resources to review analytics and make operational adjustments. The designer's eye is useful for generating hypotheses.