Search

Zoom Desktop Redesign—Setting up the context

Over the course of 2018 I worked on a team of 4 designers (including myself) on a full-blown desktop redesign. The primary goal of this redesign was to fix a broken experience using chat. Codenamed "One Window", it aimed to merge the prior 2 window experience.

I’m going to walk you through the redesigned search experience
Project Duration: 2 Weeks
Role: Lead Designer

So, what’s the problem

With the updated client, the previous search solution wasn’t going to work. Previously living solely in the Chat pop-out window, it would need to be integrated with the rest of the product. Some key problems customers faced were...

  • It was hard to find
  • It wasn’t clear it was a global search
  • Weren’t able to find what they were looking for
  • Slow to get results
It was hard to find

Zoom has been focusing in on the messaging market, which meant search was going to become an integral part of the product. The first step was giving hierarchy to the placement to allow for easy discovery and quick access.

It wasn’t clear it was a global search

Relating closely to discovery and access, establishing the component visually as a global search required considerations of being visible throughout the experience. This meant regardless of where you are in the product, you should always be able to search.

The solution - Moving search to the navigation title bar provided a visual hierachy equal to the navigation, which gave a clear understanding it wasn’t only for that specific page.

The surface

The search previously lived solely in chat, which meant the experience would require a new surface. Being accessible at any moment, this led to exploring new ways to display results on top of the task at hand. Narrowing the explorations down to the top 3 for testing, we got the following feedback...

Modal

Consistent feedback was their searches started from something viewed within the product, and that losing visibility of where they were and what they were looking at caused going back and forth to gain context and/or remember what they were originally looking for.

Full-Screen Modal

With the original assumption of providing only the results, we could maximize space and focus. This exploration was quickly dismissed after many testers attempted to use the system traffic lights to go back. This was in part due to being a new pattern that didn’t exist anywhere else.

Right Panel

The last exploration was to have the search results “slide in” when they were needed. This resonated most with our testers since they expressed still having visibility of what they were doing, and a more clear understanding since it’s proximity was close to the original search bar placement.

Weren’t able to find what they were looking for

With the scope of the project only encompassing the search location, the search results surface, and improved speed, this meant the component needed to be set up to scale for future tools to help find what they are looking for.

Filters

Previously, only 2 different filters were supported for managing search results. The component needed to be set up to scale for more in the future.

Hidden by default

Another question we needed to answer was whether to show the filters by default. Prototypes were built in Framer for both and tested.

The feedback consistently pointed towards having it hidden by default, where many expressed initial confusion whether or not the filters were required for a search. We wanted to remove that ambiguity and at the same time give a clear focus on the results, and only if you need that help it’s there.

Slow to get results

This may seem more of an engineering problem, but a problem is still a problem to a designer. The existing search would take an upwards of 20 seconds.

How we store data

The first part of this problem is to have a clear understanding of how data is stored, because this will determine how we can choose to fetch the results. Zoom is a native application, and stores the data locally instead of the cloud. As you use Zoom, it begins saving data stored on Zoom’s servers (the cloud) onto your device when it’s needed. For example, only after viewing a chat message or clicking on a photo will it be locally stored. This also means all searches require fetching the data stored in the cloud before any results can be displayed.

People search for things they’ve seen

An insight we discovered after viewing product data is that 96% of all successful searches ended with interacting with a locally stored item. This meant the typical flow for someone is to look for something they’ve previously seen in the product whether it be a message, file, or contact.

The solution

Since searches were typically for something they’ve seen before and therefore locally stored, we chose to search through and display those first. Only if they couldn’t find what they were looking for would we need to fetch the cloud results. The design tradeoff with this method is the sorting must display local first and therefore sorting from most recent to oldest will have a break between local and cloud.

Results

Search speeds were almost instant, displaying results in less than a second. This is a speed increase of over 1000% with just the use of clever design (if I do say so myself).

Final Design

Next steps

Overall, during the 2 week design period most of the pain points experienced were addressed. We’re still following the data closely to get a better idea of how people use Zoom search in their day to day, and how to make it better.

Back to work