Each of these platforms serves a distinct purpose such as their company directory, a repository of best practices, internal support requests, company events, and more.
However finding what you want across these platforms meant that you had to log into the corresponding app, locate the search tool and run your query.
Uber Search allows users to search across all of the internal platforms through a single app.
Uber
UX Research, Competitive Analysis, Concepts, UX Design, UI Design, Prototyping, UX Writing, Interaction Design, Project Management, Team Management
For this project, I served as an individual contributor (Product Designer) and Design Manager. I worked alongside another product designer and the product owner at Uber.
Combined six disparate search platforms into one, saving each employee over 15 minutes per day on search.
With over 20,000 business employees every second spent searching for the right answer, document, or person can cost the company millions of dollars.
Uber utilizes dozens of apps to run their business, and when looking for a particular thing, a user might not even know where to start. Was it mentioned in a text thread, a Jira issue, or maybe Confluence...?
To find what is needed, a user had to log into several different systems and spend time digging for the right info. This situation was not optimized to get the proper data and expanding the scope of apps meant even more inefficiency.
Every platform had its own search methods and filters meaning that users had to learn the intricacies of filtering through data in multiple ways.
Rather than needing to log into each application individually, we would utilize OneLogin to authenticate the user into every Uber internal application whereby saving each user several minutes per day.
Data should be prioritized based on the context of the user. Their geographic location, role within the company, team structure, date & time, and past search interactions should all be used to provide the most relevant results.
Results should become more relevant over time based on the content each user interacts with. The feedback should happen both actively by a user indicating whether or not the result was helpful, and passively by accepting a result interaction as a positive result.
Unified log in experience authenticates the user on all associated platforms.
Capture interaction data to refine the experience.
User metadata personalizes search results.
The development team built a proof-of-concept that demonstrated that it was possible to run queries across the internal platforms in a matter of milliseconds. Now we needed to design a solution for combining the results and allowing users to filter through them.
To achieve optimal efficiency, the workflow for searching needed to allow the user multiple offramps from Uber Search to their destination so that the trigger could be pulled as early as possible.
To begin exploring the possibilities of what a new search platform could look like, we put together concepts for features.
The goal of running a search is not the list of results, it is running an action based on the thing you were looking for. With this in mind, we included actions directly on the search result items where possible. This allowed users to do things like RSVP to events, start a chat with a co-worker, and update the status of development issues right in the search result view. Thus eliminating the need to open the result in the corresponding platform and finding the action they want to perform.
To narrow down the results of your search, we created two methods that served two different purposes. Type-ahead results would allow users to identify and select their intended search result without needing to run a full search.
Filters gave users the tools needed to identify hard-to-find results based on the context of the type of result. For example, when looking for people, the user is presented with Region, Title, Org, and Employment Type filters. While looking for documents, they could filter by Data Source, Date Modified, and Owner.
Feedback from users would be provided both passively and actively. The value of a result could be judged by the frequency at which users acted on a given result. Higher frequency results would rate higher and be shown further up in the list of results for subsequent queries. Users would also be provided the ability to give active feedback on a result to identify it as helpful, not helpful, or a security risk. This active feedback would give weight to the result or alert the corresponding party of the security risk.
During the design phase, we met with several users to get their feedback on the workflows of the prototype. Through this process, we identified a few themes that our team would work on enhancing.
While users found navigating the workflows with a mouse was rather easy, it wasn't as efficient as they had expected. A majority of the users of uSearch are developers who are accustomed to spending most of their working day on their keyboard. So we built workflows that could be completed using only the keyboard.
Because of the efficiency of the search algorithm, users found that most of the time they could identify their intended search result by only typing in a few characters. The importance of type-ahead results would prove to be higher than initially expected.
We discovered that there were many more possibilities for contextual actions than originally anticipated. For example, developers pointed out the tasks in Phabricator (their development tool) could be accomplished with a simple workflow like assigning it to another user or marking it as complete.
As a result of the design and development efforts of Uber Search, we shortened average search workflow from 10 clicks to 3 steps, Increased adoption of the Uber Search tool by approximately 50%, and saved each employee over 15 minutes per day on search.
As with all things in life, you must learn from your mistakes. Here are a some things I learned in this process.
When there is an existing product, it's always wise to conduct usability testing before designing solutions based solely on leadership's and your assumptions. When my team was brought into this project, we made the assumption that the requests coming from the leadership team were based on user feedback. We found later that they were not. Had we done user testing early in the process, we could have been more efficient and ultimately produced a more useful product.
Components, styles, and constraints! This was my first project using Figma. After several years of a Sketch > InVision workflow, I wasn't comfortable with Figma's component system. Revisiting the project after becoming an expert in Figma, I see how much time was wasted by not using the tools that Figma provides.
