Network Search & Unified Search
A project story from my work at Bridge
Background
Bridge (brdg.app) is a B2C SaaS in the networking productivity space that helps people make introductions faster and track the outcomes, and enables others to actively seek out new connections. Users connect their email accounts and sync their contacts, and can then share their network contacts with others, who can then request intros to anyone in their network.
Search was a vital component of the UX with a variety of entry points from user flows throughout the product. There were a number of contextual search flows, like when making an introduction or searching a specific group. There was also a global search, but it was limited to only searching within your own 1st degree contacts.
Users wanted access to discover and connect with 2nd degree connections from their network. This access was available within specific places in the product, but it was quite hidden and cumbersome. Users would have to go into each shared group and shared network to search within them. Due to technical constraints, we hadn't yet solved for making all of these 2nd degree connections in shared groups and networks searchable from one place (in global search).
Challenges & constraints
A user's own network would range from hundreds to thousands of contacts. A copy of these would be kept in local storage to make search results return very quickly and reduce requests to the backend.
However, when searching networks shared with you, this dataset could be many multiples of your own (e.g. with only 4 well-connected people sharing their networks with me, my extended network is over 60k people). These network results would take longer to return, not only due to the larger size of the dataset, but also from needing to deduplicate results, prioritize showing the better results when there were multiples, sorting results by relevance, etc.
We needed to make results easily accessible, both from your personal network (stored locally) and from networks shared with you (more expensive data fetching). We didn't want to wait for all search results to return before showing any — we could show results almost instantaneously from your network — but we also needed to avoid any layout shift while results from shared networks were still loading.
As a small startup team, we also always kept in mind to reduce scope for Engineering as much as possible, while still solving for the objectives. We reused existing components whenever possible, designed for flexibility, and had created systems for designing for mobile first and showing desktop views as needed, and when applicable we split up and sequenced work in order to ship incremental changes faster.
Searching across your extended networks (all 2nd degree connections) was much less performant than searching within your own network (1st degree connections), but we needed to combine the features into one search experience, while limiting scope and staying within the existing design system.
Initial direction: make network search an optional subflow of the core global search
With the understanding it could take much longer to search networks shared with you (also a variable based on the size of networks shared), and with it being a more expensive search function, the initial direction we took was to make the network search an optional subflow within the core global search. You'd continue to get instant results back from your network, and could choose to explore separate search results from all shared networks.
Here are samples from the rough drafts and the design spec for this first pass on network search:
Followup objective: unify all global search results
After we had implemented the above, the network search results had been faster than originally estimated, and after some time working through other features and specs, the Engineering team had also made more search performance improvements. So in the latest state the network search results were very performant.
We then decided to revisit the network search results and bring them into the the primary search results as opposed to keeping them as a secondary subflow. We still needed to solve for gracefully handling all possible search result states, and progressively showing results while avoiding layout shift as different results loaded in. We also wanted to explore surfacing search results for members of Bridge, even if they weren't among your 1st or 2nd degree connections.
Here's a high-level look at the drafts, where I explored ideas and shared options with the team, and received feedback and iterated:
During the drafts, I had identified some changes would be needed on the card components shown in results, along with some changes to profiles. These would be prerequisites to the unified search, and so I split those out into separate tasks and design spec files:
The design spec for unified search was then finished up for handoff to Engineering, with finalized notes around logic, UI and UX. A Codepen demo was included for the loading state, and a final Loom video walkthrough was added.
Wrapping things up
We had explored, designed, and implemented search solutions based on the UX goals and the evolving technical constraints. In the end, the opportunities for connecting with new people that had been buried in the product were now surfaced prominently in global search, while keeping search performant and gracefully handling all possible search result states.
