A little more context on how I thought about this topic. I just came across Figma’s job opening for Discovery where they mentioned creating a strategy and vision for the file browser (including search and navigation).

Wayfinding across teams, projects and files becomes quite challenging as the team grows. I have encountered this problem as I keep browsing through different files and projects to understand and learn from other teams.

Therefore, I wanted to think about how I could solve this. With enough context let’s jump right into the problem.

Problem statement: Improve search and navigation inside Figma file browser.

To scope out the problem let’s start with a couple of clarifying questions.

Me: Figma was developed to make design accessible to all. One of their goals is to move quickly between idea, prototype and production. As a team grows, Figma wants to make it easier for teammates to find and weigh-in on the design that is happening within their team and across the organization. The goal is to increase collaboration and improve user experience which will in turn increase engagement. Are we aligned on the goal ?

Interviewer: Ya, sounds fine.

Me: Do we need to focus on mobile or web or both?

Interviewer: It’s up to you.

Me: I think we can start with Desktop first as most of the work happens there. People may review specific files on the app, generally the link to which is shared to them.

Interviewer: Makes sense.

Me: We are focused on mid to large size organizations as they have multiple teams and projects and not so much on individual contributors or really small startups.

Interviewer: Ya

Let’s dive into the different personas that use Figma, both FigJam and the design tool.

• Designers: Rekha is the head of design for 6 pods at a fitness company. She constantly has to review multiple files and provide feedback. People do send her links but just because of the sheer number of designers who work in her team, the number of requests are pretty high and it is quite tedious to go back to individual messages and find files. She also can’t keep all the tabs open because that makes her system really really slow.
• Product Managers: Rishabh is a product manager who leads 2 charters in a product. He has 3 designers who work with him. He ideates on problems/ ideas with his teams on FigJam and also reviews designs before handing it to developers. He also actively takes interest in following what is happening across teams in his organization. So in his spare time, he browses through other projects.
• Engineers: Arihant is an iOS developer who uses Figma for development. Usually he works on one project at a time, the link to which is pinned in a recent chat or on the PRD.

With the given context I would like to prioritize the personas:

Designers and Product Managers spend the most time navigating and searching for files. To drive the most impact, prioritizing the needs of these two user segments makes most sense.

Are you with me so far?

Interviewer: Yeah

Now going through the user journey let’s figure out a few pain points that the users experience:

• - Having used the search functionality on Figma myself to find files, it is often quite tedious to find the right one. For example: If I search “Comm” with the intention of finding communication, the first result may be appropriate but the second, third etc seem to be very off. I found things such as Journey Workshop, CRM, Journey creation etc none of which were relevant to my search prompt.
• - Also, some files may have common names. For example, onboarding. If there are multiple products and each product has an onboarding flow, it becomes very difficult to know which one may be the right one unless named correctly. There is no other relevant information other than the file name.
• - There are times when a user might not even have the right prompt for search while exploring files. So a user has to go inside each folder, open each file to figure out if it is the right one.
• - If a file was opened by the user recently, then they get to see if there are any updates made to it or not. Else, there is no way a user knows that a file may have been updated and they should check it out. This concept is only applicable to files and not projects, which means if there is a new file added to a project, user will not know until they explicitly check it out.
• - The application becomes extremely slow when many files are open simultaneously which means the search and navigation needs to be better so users are not forced to keep multiple files open.
• - The default page that opens when you click on the home icon on the top left of the navigation bar, is “Recents”. The downside to that is those files may be the same ones that are already open as tabs. There is a drop down that is not so prominent, that one could use to change the setting, but users mostly default to default behavior.
• - The “+” icon on the right of the navigation bar, opens a new tab. You can only create new files or open recently opened files. This behavior for users is familiar to what they are used to doing on a browser. Over there, they can search easily for a website and also access most visited pages. I as a user expected similar behavior and it took me a few attempts to change that mental model and use the home button.
• - There is a favorites feature, where you can find all the favorite files. It can quickly become very cluttered if a user favorites too many files just for the sake of finding them quickly.

Solutions:

Our north star is to reduce the time it takes for a user to find the right file and have a frictionless experience in doing so therefore I’d like to discuss solutions centered around it.

• - Relevant searches: If I search for the keyword smart watch, I get results like Smartwatch but it wouldn’t return smartwatch Dev file. I know ideally it is not a correct match, but similar to Google identifying a search error and stating did you mean smartwatch and showing results for it, Figma could do the same. File naming can be very subjective and therefore the results have to be a lot more inclusive.

• - Sort order of returned results: The results seem to be sorted in a very random order, something I couldn’t identify the pattern for. There were some results that didn’t even have the prompt I searched for. The results could be ordered by the highest match to prompt, files the user is a teammate on, a file user is recently tagged on, recently updated, favorited etc. The priority of a search result increases if it meets more than one of the above criterias.

• - All results: The search results page has the following navigation hierarchy. There is no place where users could see all the results at once, especially for files and projects. Sometimes even team names are the same as project names adding to the confusion. If the user can’t find something inside the file tab, they will look into the project tab and then if they don’t find it there too, they will change the prompt. This increases the number of clicks a user has to perform to get to the right result. Therefore an “all results” page is important to see everything in once glance.  

• - Naming convention: Each organization may enforce a naming convention for its teams. But as the # of teams increase, human errors are bound to happen leading to inconsistency. While creating a new file or a project there could be an enforced naming convention. It could be as simple as Team: Project: File Name. Later it could be modular enough that each org can determine what convention works best for them.

• - Recently updated: Instead of just having a “Favorites” tab, there could be a
  “Recently Updated” tab, that users could check to see files that were updated. Users could also add “watch these files” like in JIRA where you want to stay updated on certain tickets. The only issue is that designers may not want everyone to see WIP changes and they can choose to not publish it by selecting “draft” or something. The default would be for the file changes to be visible on the basis of access rules.

• - Search on a new tab: Adhering to the mental model of a user when using a new tab, there should be a search functionality, to search the relevant files and folders. The entire home tab could be replicated within the new tab as well.

• - Personalized home page: The user could be nudged to close a few tabs that have been open for quite some time and the user has not accessed it. This could improve the applications performance and enhance user experience. This is similar to Slack asking a user to delete some channels that they have not interacted with. There could be a list of categories on the homepage, like “Recently updated”, “Your Projects”, “ Favorites” etc and the user could customize the ones they want to see along with setting the order. Apps like Insight Timer etc allow you to do so.

• - Add tags to files: Users should be able to add tags to the files and search them using the tag.

The next step is to prioritize these solutions on a roadmap. The approach I'd like to take is using the RICE framework. Feature #1 is table stakes when it comes to reducing the time taken to find a file which is our north star. The effort is significant but if deployed in iterations it could really enhance the experience. #2 and #3 organize search results in a much more digestible format. This could really help in pointed exploration till the search feature is perfected. Similarly #4 is really easy to implement at least partially where a standard naming convention is mandated. #6 is simple to implement as the functionality currently exists and is more about changing the IA than building a new feature. We do have to be mindful of the impact of the change for folks who have developed the new mental model of accessing it from the home tab. #7 and #8 are good to have. #7 needs a lot of experimentation to figure out when it is the right time to prompt the user. #8 works best for feeds when there are 100s of files. Though orgs may have many files, it’s probably not at that scale.

In short, we should start with #1, #2, #3, and #4 with parallel efforts to get data around the impact of #6. #5 and #7 could be done V2. #8 could be reconsidered after analyzing user behavior around exploration and impact of previously implemented solutions.

Metrics to measure:

• - Average number of searches to find the right file
• - Average time to find the right file
• - NPS
• - % sessions with search
• - Number of scrolls to find the result after a search
• - % search exits i.e. % of searches where user didn’t click on any result
• - Time spent on the file after the search, ideally longer the time, more likely that the result was correct.