ROLE
Product Designer
TIMELINE
2022 • 3 months
RESPONSIBILITY
Overview
I believe it's not a surprise if I say searching is one of the most important features of a streaming platform. We are using it a lot because it's commonly hard to find what we want to see. We have our preferences, and childhood memories and all of them point us in the search direction. So it's clear thatwe have to provide the perfect results to the users.
But the streaming search is really different than in e-commerce. It has its own characteristics and it's unique in the way it works. It can help the users or cause a lot of headaches. Let's keep our eyes on the first way.
Problem Space
At the beginning of the design phase, we asked ourselves questions to make it clear to everybody what the common challenges are with the search feature. We found out, we have a lot of them:
How might we show the results in the best way to our users? How should we set the engine behind the search?
How could we help the users to give them the possibility to filter their results?
How could we recommend alternative content if something is not available?
What kind of settings, small touches need to be defined for the perfect operation?
Opportunities
What if people can get quick and smart results after the first character being written?
What if people can filter their results?
What if people can get alternative contents if something is not available?
Providing a great Search Engine
Designing and defining a search engine started with setting the key principles of it.
Smart
The results are relevant and it manages to guess what users search intent* could be.
Transparent
It has a clear order and the relevancy of the results are obvious to the users.
Flexible
Quick
It requires minimal input and effort from the users to get the best results.
*The search intent describes what is the purpose behind an online search. Let's say, a user would like to watch Game of Thrones, then the search intent will be "Game of Thrones". Obviously, the user is not going to write in it all, they are mostly going to write in "Game" so the search engine should predict the rest of the search intent and give relevant results.
Search Domains
The search domains contain everything that the users can search in, so we had to discover what kind of search terms are used by our users. We can think in a way that we should be able to search in any metadata, but it's just simply wrong in this case, because the more search domain there is, the more false results are possible. So overall, more search domains do not always lead us to better results. So let's check what kind of domains the users want to search in:
It was clearly visible that we should include the title, genre, languages, keywords, creators, and cast members in the search domains, and we should exclude the descriptions and the titles of episodes. The reason for exclusion was really simple. Who wants to search for them? How many times do we search because of a description or even remember what the title of season 3 episode 4 of The Office is? We don't. If we are going to include e.g the description and the user's search for "The…", then they will see basically all the contents as a result and they will not trust the search.
Results
We already know what kind of domains we are going to search for, so let’s take a look at what items we should provide as results and how we should provide them?
Movies and Series
Cast Members and Directors
Genres
Keywords
Languages
The most important thing here was never showing individual episodes or seasons of a series. It's crucial, because if we are going to do that, then let's imagine: if you are going to search for "The Offi…" you will get more than 200 results. It would be a disaster.
Help the Users until their Final Decision
To build a great search experience, we should help the users on the results page too. If we are only providing them with a couple of results it's still hard to manage them, so we should help to specify the right content for the users.
Instant Search
As I mentioned previously, OSN operated with a search engine that required a minimum of 3 characters to provide results. We automatically thought that it was not the best way to display the contents. We noticed that we should not wait until 3 characters, we have the possibility to show content after one single character in the search field on the same page.
Tags
There can be a lot of cases when the users don't search for a specific movie or series. Instead of that, it's pretty common that somebody searches for Action, or simply just writes the letter A in the search field, so we needed to help them on the results page as well. To do that, we used tags to allow the users to filter their results.
No Results
If we can't provide a match for the search, it's a top priority to provide recommended content and let the users know, the search was right, the content they searched for was just not available. We just don't want the users to leave, so we should suggest them alternative movies and series they can watch.
Another key indicator was that we should clearly give positive and clear feedback when the user enters a title that is not available. For us, a big help was the huge database owned by OSN which collected all of the movies and series titles which were ever released so we could monitor the titles and we had the chance to give alternates, related titles to the specific title that the user wanted to watch.
Final Tunes to Make it Better
One of the hardest things during building a search was the final tunes, so setting up all of the rules that a search engine should follow, because this will give us the feeling that a search is smart, quick, transparent, and flexible.
Let's see a concrete example, how many tunes we had to set for a real movie called "Ford v Ferrari".
Partial Matches
We set our search that it should accept the partial matches at the beginningof a word. We can't expect the users that they will always write "Ford…" at the start of the search, so we should also accept, and provide the same result when they write "Ferrari". Another key thing is, we had to exclude the partial matches in the middle of a word, for example, "err…" because then it will give us much more irrelevant results. Also, it was logical, because we realized that no one is going to search by starting from a middle of a word.
Ignoring Special Characters
Sometimes the names of the contents are pretty tricky which is why we had to configure the search to ignore the special characters. In this way, there won't be frustration because somebody writes the vs. word with a dot while others don’t, regardless, the search will display the same results.
Ignoring the Order of Words
We learned that there are a few cases when the users don't remember the name of the content correctly and they just swap the order of the words, so we needed to make surd that both ways are accepted and avoid the frustration on the users' side.
Tolerance for Mispelling
We often misspell, right? Not a problem at all. After a quick round with the developers we had the opportunity to allow some percentage of error between the entered search term and the exact matching term. A lot of people don't speak English in the MENA region so they more or less remember the title or words from the title so this tolerance was a really big help to them.
The Outcome & Takeaways
Details matter, right? I personally really loved working on this feature, because it was an excellent collaboration between the designers and the developers. A cooperative brainstorming, drawing ideas, testing, and learning from them to make it better. I enjoyed creating this feature and I feel like I can bring this experience to every search feature that I work on.