An SDK used by many companies worldwide to collect users’ privacy preferences on connected televisions.
The Challenges.
- It was the 1st time the company was approaching CTV platforms. Nobody knew much about them, a part of the fact that we needed those applications as soon as possible.
- The apps needed to re-use existing APIs to fetch the data, this put several constraints on the information architecture of the apps.
- I had to work in parallel for two different platforms (AndroidTV and tvOS) and participate daily in the activity of two different teams.
- Testing each new release on a real television was complex and time consuming.
The project.
I was the only product designer on the team and acted as product owner for a few weeks due to an internal reorganization. It took less than six months to go from the very beginning to the 1st release of the product. Around ten weeks to align the stakeholders and reach the final design and three months of development with two developers teams working in parallel.
I started by studying the CTV interfaces’ peculiarities, constraints, and best practices. I then built some interactive prototypes in Figma and tested it with stakeholders and potential users. This preparatory work allowed me to map out all the features to include and all the information to display on the applications. Overall, it’s been essential for me to understand the peculiarity of an interface controlled by a TV remote controller, which differs significantly from a standard web interface.
I run few user tests on Figma interactive prototypes.
After converging on the final product prototype, I started researching and studying the Android TV platform and the Apple tvOS one, together with their guidelines and documentation. I concluded that I needed to design two different applications.
It took me around eight weeks to create the two UI Kits and finalize the design propositions. During this time, I regularly checked the designs of the applications with the developers and the legal team to be sure to design something feasible and meaningful.
The documentation I provided to the team is a lean documentation realized in Figma. It gives a clear view of the application screens, all the UI components, the navigation flow, and the essential notes are directly attached to the design. Lean documentation is the most appropriate when working within an agile team because it’s highly effective in explaining the requirements and can be quickly reviewed and reworked during the refinements. Indeed, I participated in all the refinement calls of the agile squad, and I was an active part of the agile team.
The lean documentation.
It’s a live documentation that acts as a single source of truth during the development process. It contains the UI designs of the entire pages, the indication of how the users can navigate them, and a few notes that point out the most important or less apparent aspects.
The lean documentation in Figma was crucial to explain the requirements and to onboard the developers.
Functional specifications are attached to the design of the page, easily accessible to the whole team.
Furthermore, it also includes an introduction about the peculiarities of the TV interfaces, the field’s best practices, and indications about the templates’ layout.
The specifications of one of the layouts.
The introduction to the CTV peculiarities, to onboard the team.
The UI kit
Both the Android TV and the Apple tvOS applications are based on different sets of UI components, which was necessary given the different design standards and guidelines of the two platforms.
Nevertheless, having UI kits helps in many ways. While it made the design more consistent, it also made explicit the behaviors and the specifications of all the UI components, delivering a very effective big picture to the team.
From an operational point of view, creating these components in Figma during the initial phase allowed very fast reworks and corrections during the refinement calls with the devs.
A partial view of the UI kit for the Android TV. A different one was created for tvOS.
Even if such a UI kit could have evolved into a custom design system, I saw no need to bring more complexity here. I preferred to stick with the interaction guidelines provided by the two platforms to keep it standard and intuitive. In addition, the apps are SDKs, meaning the Didomi brand guidelines had to play a very subtle role.
The platforms guidelines.
The main reason why I opted for designing two different applications is because tvOS and Android TV have different approaches to the user experience.
Indeed, the two platforms suggest different interaction patterns. To offer everybody a good level of affordance and predictability, I had no choice but to provide each user base with the patterns they already knew. Being consistent within the ecosystem is extremely important, after all.
An excellent example of a different interaction pattern is the toggle inside the buttons component. In fact, a button on an Android TV interface can contain both a toggle element and a right-arrow element.
When focusing on such an element, the user with the remote controller can either press “OK” to switch the toggle or press “right” to access a page containing more details.
This pattern is in line with existing Android TV applications, and it’s very convenient since it makes navigation faster. This is important when, like in this app, the content is distributed on many pages and structured in several nested layers.
The Android TV application. The blue focus highlights one of the buttons that contain both a toggle and an arrow.
In the case of the Apple’s platform, such a solution was not acceptable. The tvOS guidelines push for an extremely clear and error-proof design, even at the cost of slowing down the users.
On tvOS, a button must have only one function to avoid any possible misunderstanding. The users can click “OK” on their remotes, and by doing so, they access a new page where they can finally switch the toggle. Indeed, they can read the current value of the toggle (on/off) before accessing the new page, but they need one additional action if they want to change it.
The Apple TV interface. These buttons are only used to navigate the pages, they don’t act as a toggle.
Another example of the differences between the two platforms is the so-called “drawer”, an overlay layer that slides in from the side of the screen and provides new content.
It is a UI pattern widely used on Android operating systems, including Android TV. Once again, it works in favor of the navigation speed and has the advantage of keeping the previous page partially visible in the background, giving more context to the user.
The Android TV makes use of the “drawer”: a new page which appears in overlay, partially overlapping the previous one. It speeds up the navigation.
Unfortunately, the Apple approach to the user experience makes the “drawer” an imperfect solution. The overlapping of multiple pages with different content is interpreted as a possible distraction for the users.
This is why the page’s content is displayed in all its splendor on a completely black background. The additional context – to help the users remember which page they are currently seeing – is provided through a breadcrumb.
The tvOS doesn’t make use of complex overlays, it’s in favour of a simpler visual hierarchy and a higher level of affordance.
It’s important to note that even if the two platforms have two different approaches to the user experience, both make sense when considered in their ecosystem. Both are based on solid principles. Both solutions are the right one for their users.