A white-label, iOS and Android video player. A UX Case Study

Context

The challenges of building a white-label platform

Simplestream is a B2B2C SaaS company. We build advanced streaming apps for media companies based on a common white-label framework.

Any given time, each of our 16+ clients has their own version of our app live on the app store. Each with a unique architecture, colours scheme, content, copy and language.

Our design must work well for our small clients with no live channels, our bigger clients with 60+ channels and everyone in between.

This is what the iOS app of some of our clients looks like. As you can see, the home screen looks similar, but the colours, architecture, content and fonts is different.

Key Drivers of the new player

The interest on "internet TV" is growing. We need to enable our clients to easily stream dozens of live channels right from our app.

Our player can't support live content so we are taking the opportunity to completely rebuild the player into one of the most advanced in the industry.

Support the most advanced live video streaming. Our player must seamlessly play 4 different types of Live and VOD video streaming,

Be re-skinned to fit our client’s branding and re-architected to fit their app’s functionality. The player must respect accessibility and maintain performance no matter the branding and content of the app.

Provide a solid foundation for any future improvements. Simplestream is growing fast, we need our player design to remain flexible and be able to adapt to any future requirements.

BEFORE and AFTER of the player redesign

Research

Competitor analysis

Many of the biggest tech companies (Netflix, Youtube, Facebook, Amazon…) rely on video to attract users and dedicate an enormous amount of resources to their players.

As a small team, learning from their decisions by analyzing the designs of these billion-dollar companies was invaluable. It allowed us to create a custom solution that is orders of magnitude better than what we could have done on our own.

Heuristic Evaluations offered a systematic approach to uncover the design decisions of the best players.

We looked at dozens of players, performing a deeper analysis of the 6 that best matched our requirements (Youtube, Netflix, BBC, VLC, Infuse4 & Amazon Prime)

Bringing screenshots into Sketch to analyse minute details

User interviews

Throughout the project we used the following interview pattern:

We fist engaged users through directed interviews asking a prepared set of question (e.g. can you take me through the process of watching a video on your favourite streaming app?)

We then moved to a non-directed interview style, asking open-ended questions about their video watching and player habits.

Insights from these interviews shaped almost all elements in the UI, from the button layout to the all-new channel changer screen.

Early Findings

When designing utilitarian screens like a player, a user's existing mental models become central to their experience. Users have built strong mental models of how a player works and get frustrated when it doesn't behave as expected.

💡 Insight: Most players are very similar - users like that. Bells and whistles (custom layouts, fancy buttons, complex gesture control…) are only welcomed by a minority of users.

As long as watching the content is straightforward, users don't think (or care much) about a player's UI.

💡 Insight: As a designer, this was a hard realisation although it soon made the project that much more interesting. We were building one of the most advanced players in the industry, and it forced us to find solutions that feel effortless and familiar to the user.

👀 The takeaway: Our goal is to wrap our complex features and restrictions under a UI so simple and intuitive users won’t even notice it.

Our process

A better outcome by separating the UI into its components

Tight constraints and a component-based approach to design allowed us to move directly from rough paper sketches into high-fidelity prototypes.

⚠️ Mini-problem: tracking and comparing different iterations of our components was proving a real challenge.

⭐️ Mini-solution: we came up with an innovative way to use symbols in Sketch. It allowed us to separate the UI into 16 basic building components (e.g. background, overlay, play button, title…) and quickly and consistently swap those components in a way that made easy to compare even small iterations.

🎯 Impact: our approach sped up the design. Unexpectedly, it was especially useful during user testing, allowing us to swap components in and out in a matter of seconds.

On this example, we were able to change the background to compare how different layouts performed.

Some of the player overlays we tested

User testing

We created high-fidelity prototypes using Principle which even allowed us to play a video in the background to offer a realistic experience to out test participants.

Problem 1: Define a layout and navigation

🥅 Goal: Intuitive controls that seamlessly adapt to changes in the back end.

After dozens of iterations, we compared 3 finalist UIs head to head in user tests.

60+ VOD player iterations

The three finalist UI that were tested

Final player UI

Testing high-fidelity prototypes showed a ‘Netflix like’ bottom layout far outperforms other solutions.

✅

Users found it easier to use.

⚠️ Mini-Problem: with icon only buttons (see option 1 below), users had problems identifying our less common buttons like the 'live channel changer'. ⭐️ Mini-Solution: A bottom layout provides enough space to add text to each icon, making it a lot easier to understand.

✅

Effortless taping for all users.

Buttons at the bottom of the screen were easier to reach by both left and right-handed users.

✅

Flexibility for our clients.

This pattern accommodates extremely well all types of streams, content types and user statuses with minimal changes to the UI.

Problem 2: Live stream interface

We created dozens of solutions. Testing with users was essential to iterate on this subtle UI changes.

🗺 Context: our player must support 4 types of VOD and Live video streams. Each stream type has subtle changes in functionality that proved a challenge to communicate effectively to users.

⚠️ Problem: these changes in functionality can be very subtle but important for a user’s experience. Here is one example: some live channels can be paused and scrolled backwards while others can only be watched live; how can we let the user know the difference? What happens when a user scrolls back on a live channel so it’s no longer live? We needed to answer these and similar questions.

🤔 Challenge: create a UI that 1- instantly lets viewers know which type of stream they are watching. And 2 - makes it clear which functionality is available to them.

Due to the complex requirements, live was among the most iterated and tested parts of the UI.

Live player UI

The channel logo provides a clear indicator to the user that they are on a live stream and which channel they are watching.

The stop button is a subtle cue that the stream can’t be paused.

The circular handle used to indicate the current playing position disappears.

The 'LIVE' tag also serves to indicate a live the stream is live.

There is now a pause button, a subtle indication that pausing is available.

When watching live, the video time stamp disappears. When the user scrolls back, the time stamp reappears, marking the minutes behind live.

The circular handle used to indicate the current playing position reappears, indicating to the user that it's an available action.

The live tag disappears whenever the user is not watching live.

Learnings of working on the live UI:

⚠️

During user test, the Live UI results were mixed, although most users cold navigate without any problems, many didn't relate changes in the UI to changes in functionality (e.i. the stop button meaning that the program can't be paused.)

✅

This was to be expected when dealing with very subtle changes in the UI and functionality. We would have loved to spend more time refining these small elements, but it got to a point where we had to move on.

✅

We followed a "do not harm" approach. The final elements were those that created less confusion, even if they weren't understood by all users.

Problem 3: Allow users to browse other channels without leaving the player.

The channel changer is a very valuable feature both for our bigger TELCO clients and for Simplestream, as it would set our player apart from the competition.

⚠️ Requirements: because of our white-label, we needed a pattern that could accommodate both our larger clients (with 60+ live channels) and smaller clients with 2 or 3 live channels.

Some of our initial concepts that made it into Sketch

We explored about a dozen solutions, settling down for two that slightly modified UI patterns already in production. This provided the benefit of being tried and tested, familiar to the user and easier to build by our devs.

Our 2 finalist patterns

User testing results

Part of our presentation to stakeholders summarising research findings

Final channel-changer UI

After several rounds of tests and iterations, we decided to go with vertically stalked cards.

✅

White-label flexibility.

This solution works great for clients who have 3 and 3 dozen channels.

✅

Easier to use.

With long lists, users found it easier to scroll vertically. We enabled scrolling on the left hand of the screen for left-handed use.

✅

Browse and watch at the same time.

With 60% of the current video is still visible, users can keep watching the current channel while browsing others. This was a much requested feature.

Development & Launch

Working closely with our developer team throughout the project meant we were able to catch and fix problems early during the design and development phase.

The handoff was done using Zeplin.

Design Review and launch

For me, getting together with the developer for a design review is one of the most interesting yet nerve-racking moments of any project.

We spent an afternoon together discussing differences and making the final adjustments directly in the code.

Shoutout to Shyam Bhudia who made the whole process a breeze 👏👏

I took screenshots of every coded screen and brought them at a 1:1 resolution into Sketch where we could easily compare by overlaying design to code.

Learnings

What we did well

✅

Stress test our designs early and often.

Working on a white label product, our UI must perform under all conditions, constantly stress-testing our design to make sure nothing breaks — what if the background is pure white? What about pure black? And highly contrasted?. What happens if the text is extremely short? And extremely long?…

Actionable item: To make this process easier, we cleverly used symbols in Sketch to instantly swap images and channel logos throughout the UI to test for accessibility under all conditions. To test different copy on the UI, we used the free plugin Craft to replace the text with real data from some of our clients. I'll write an article detailing these techniques soon.

I now use these techniques on each one of my projects, saving me time and headaches down the road.

What we need to improve

❗️

Map out all the possible screens and states beforehand and try to identify problem areas; it will save time in the long run.

This is essential to make sure nothing gets left behind and to accurately estimate the time the design will take.Wanting to get started quickly, I only mapped the main screens, states and flows. These lead to underestimating the time some flows would take and in some cases to have to backtrack on design decisions.

Nacho Allendesalazar

Company

Core team

Time

My role

Tools

Designed a powerful video player live in 40+ apps

Summary