Pluto TV Search

At Pluto TV, the search feature was never included in the product by design. This decision was made long before I joined, the premise was that Pluto TV is where you go to find something to watch and serendipitously stumbled onto a show that you enjoyed. From a user's perspective and as a designer it always felt so backwards, why wouldn't we just add the most basic search functionality? Search was one of most requested features so there was clear user demand in including it.

As I learned over the 4 years of being there, that decision was the correct one, while it was the complete opposite of what every other streaming service did. I learned that every product is different, even those in the same industry will require different solutions to problems. It took Pluto TV 7 years to finally consider including a search function in the product. I had the great opportunity to lead the search design efforts and work jointly with the product owner to lay out the foundations. In this case study I will focus on the areas where I had the most impact as the lead designer and will cover the contributions and hurdles we had to overcome to get the feature to market.

The search experience is tailored for users who know exactly what they want to watch, reducing time to watch is one of key indicators we were shooting for. This search experience needed to be flexible enough to accommodate Channels, On Demand Shows & Movies, Content that is live, and content scheduled for the future.

We were able to deliver the search feature across Mobile, Tablet, and Connected TV thanks to our amazing Apple engineering team. As with any project, product needed to make sure this feature would not cause harm, this canary was built before all other platforms to reduce risk. Ultimatley this MVP's goal was to learn as much as we could, as fast as we could, before taking taking it to other platforms.

Soon after we all started working from home, the Product & Design team at Pluto started running a virtual 5 day design sprint. We needed to move fast, our first sprint focused on getting an MVP search feature out for the TV experience. Included in the sprint was Product, Engineering, and Design, the goal for the sprint was to have a tested MVP that we knew was feasible for the end of year launch. We ended up running a second one with focus on the mobile experience given that we had an amazing outcome the first time around.

In anticipation of the sprints, I did some thorough research on this project. I ran user tests on similar services such as Philo to get insights on what users expect out of a search. I also benchmarked other streaming services and apps that we felt had similar complex searching functionality. What I found was that all streaming services have essentially the same experience.

The aspects of search that shine are in the details you can’t see, while the Netflix UI is not any different than any other. I'm sure you have noticed that on a TV experience, Netflix  just always seems to know exactly what you are looking for within a few clicks. For Netflix we found out that 3 characters is all it takes for the majority of users to get to the content they want to watch. Netflix is able to do this by using multiple recommendation engines and ranking algorithms. You’ll also notice that even when the content is not available to watch on the service you’ll still see that exact title in an auto-fill format. This provides users the queue that they know what you are trying to spell but it is not available, instead users are given amazing recommendations.

Another great example we found was Home Depot. I've found that looking outside of industry usually helps break away from the standard and find a solution that works best for your particular problem. Home Depot uses a filtered approach to search, instead of just giving you the thing you asked for like Amazon would, you are dropped into the a filtered view where you can see all relevant results and can take a step back to look at the broader section in case there was a different product that would better suit your needs. After some research it turns out their team wanted to mimic the in store aisle & merchandising experience, which they have already been optimizing and perfecting for decades. This particular one was important for us, because at the beginning of this project we weren't sure whether we could pull off a text based search or if we would need a complex filtering system instead.

At Pluto one of the problems we needed to avoid was “No Results”, we don’t have the variety of content that you can find on Netflix or Amazon Prime. While our library was vast it was not inclusive of all the latest shows & movies (those are reserved for the premium paid services). If you searched for Titanic, we may have Titanic 2 along with 5 other shipwreck movies and maybe one Leonardo DiCaprio or Kate Winslet movie. This was the problem Pluto had to overcome before releasing the search. Product was considering a filtering system, a solution that we could do quickly without any additional backend changes. Throughout this journey, and with the support of the greater organization a real text-based search feature was coming to fruition.

At Pluto we didn't have a recommendation engine or even a database we could use to reference content that isn't in our system. We had a lot of content and a lot of noise. There are third party services that are built to solve this, however any integration would be costly and risk getting the search feature out to market.

Luckily, after our design sprint the excitement for search was heard throughout the company, our backend team jumped onboard to help us get a solid search system into the product. Our engineering team was thrilled to be at the forefront of this feature as well, the engineering lead did not want to set any limits, they just wanted us to make the best possible experience to pioneer the feature.

Even though we were confident that the engineering team could produce our expected results to spec we needed to consider Android Mobile, Android TV, Roku, and the host of other platforms supported by the Web team Including Smart TVs, Consoles, and set top boxes. Working closely with the respective teams we ensured that the same approach could be taken on the other platforms. While Ideally we could use the exact same design across platforms that just isn't possible, building a custom keyboard per platform would require additional effort and further increase the risk of launching on time . We had to make the search experience optimized per platform specifications, which ultimately made it so that the layout was modular enough to accommodate for the different platforms.

As we got a greenlight from Product on the design and flow I started to build out a prototype. We needed to user test the TV & Mobile platforms. I ultimately decided to create the prototype using a Roku remote on the Roku experience as well as an iPhone. This was made directly within figma. If the atomic design system is used correctly, figma is an incredible prototyping tool that can be leveraged to create high fidelity prototypes with quick turnarounds.

After this project, and quite a few other projects over the years, I have learned to more efficiently build high fidelity prototypes. This is a whole other blog & case study on its own so I’ll link it here when it's available.

I would now consider high fidelity prototypes a requirement for many of my projects, we can use them to gain insights on usability during the design phase. During the product requirement phase it allows us to run through the flow and determine use cases with the product team. During the development phase we can deliver a video along with static screens to bring the product feature to life answering many of the interaction questions engineers have during hand off. Having these prototypes built in high fidelity helps visualize and showcase the feature to teams outside of our immediate tech teams such as sales, marketing, and even for decks at the highest level. This search prototype was used for all of these cases at Pluto. We made it clear what we wanted and how we needed it to work, so much so, I (the designer) was writing product requirements and having the product owner sign off. Thanks Jeremy :)  

I built out a script for user testing, the primary goal for this user test was usability, we needed to make sure there were no missing pieces in the flow and that users knew how to get from launching the app to the content they were looking for via search. For this test we screened for Roku & iOS users, half of whom had used Pluto within the last couple weeks and the other half had never used it.

We set the scenario up for a user who knew exactly what they were looking for (our target for the feature) and had them run through a sequence of steps in the flow. The findings turned out extremely valuable, one insight we found was that having both Linear & On Demand is somewhat confusing. Users needed to decipher whether content is available to watch now or if they need to tune back in later. This is already too much to ask for from a leanback experience. Even though this finding was not directly caused by the search feature, mixing of content within search made it more apparent, and we needed a solution before launch.

As shown above, there were alot of cases we needed to account for.

I added clear verbiage to the content results as a quick fix for this phase, but we realized that we needed a segmented search, something we would plan on for the following phase. We also took measures within the show details pages to ensure no one ever questioned whether content was Live, On Demand or both.

Being at the intersection of Design, Product & Engineering we already were very clear on what we needed to accomplish. Our engineering team was working on implementing while Product & myself were taking a deep dive on the results themselves. We had a vision beyond the MVP and we needed to set up the search API to give us the most accurate response without providing too much noise.

Given this feature was a big change to the experience, it was decided that it would best be released as a beta to a select number of users on Roku & iOS to get additional feedback and ensure the feature did no harm. While it is clear the search results themselves could be greatly improved, the first phase of search was already miles better than not having search at all. Having 200+ channels and thousands of shows & movies it can get overwhelming to choose, this feature was designed for the portion of users who knew what they wanted.

The Search feature can now be found live on tvOS, Roku, and iOS with the other platforms coming soon.