2022 Global Search
Unified search across Streampoint's event and attendee records, accessible from the top nav. Context-aware ranking surfaces results from the user's current page first. CS teams hit it dozens of times a shift; cuts time-to-find by 20%+.
Case highlights
20% ↓
Time to find
across user types in beta vs prior workflow
~60% eliminated
Secondary searches
context-aware ranking reduced double-searches
Single input
Surface
events + attendees in one unified result list
Streampoint had grown two separate search flows: one for events, one for attendee records. CS teams used both dozens of times a day, and they had to choose the right one or run multiple searches when the answer spanned both. The cost was small per-lookup but compounded hundreds of times a shift across a team that is judged on response times.
I led design on a single global search accessible from the top nav, with context-aware ranking that adapted to the user’s current page. For example if you’re inside an event, that event’s attendees rank first. Beta showed ~20% reduction in time-to-find and removed roughly 60% of the CS “search twice” pattern.
- Fragmented search. Separate pages for events vs attendees searches.
- Context-switching overhead. Different syntaxes and filter options per surface.
- Slow discoverability. Before every search, CS would have to navigate to the correct parent page.
- Time-intensive common workflows. Finding a specific attendee inside a specific event required multiple nav and filter steps.
CS team hours were getting wasted doing repetitive navigation, not actual support work. The opportunity was to unify the search surface.
Launch
Speed and accuracy
- 01 Time-to-find, target: 20%+ reduction.
- 02 First-attempt success rate for finding target results.
- 03 Adoption of advanced filtering features.
Strategy
Compound platform value
- 01 CS hours returned from navigation to support work.
- 02 Reduction in 'can't find' support tickets.
- 03 Engagement with platform features accessed through search.
- 04 Customer satisfaction scores for navigation.
- Performance ceiling on large event datasets. Indexing and query could be slow on large events. Needed progressive loading and ranked pagination.
- Cross-type ranking. Events and attendees are different shapes. Had to unify without losing the distinction at the result level.
- Can’t disrupt current habits. CS teams had established workflows with the two-surface model. The new search had to beat the old per-lookup in real use, measured against actual time-to-find.
CS interviews and workflow analysis surfaced that context-aware results could eliminate roughly half of secondary searches. The CS team was already running a second search after the first returned a too-broad result set; the cost was real and measurable.
Competitive analysis on Salesforce, HubSpot, and event platforms confirmed contextual result prioritization and unified-filter patterns are common.
The engineering challenge was indexing performance. Progressive loading and result pagination were essential; they shaped the interaction model from the start since events frequently had thousands of detailed records.
Initial wireframes explored two approaches: a global-nav unified search vs a contextual search living inside each module. Mocked both, mapped edge cases, prototyped the preferred path.
Refinement collaborated with eng on indexing performance and result pagination. The interaction model had to respect what the platform could actually handle.
REEL Open/close prototype
Animation prototype for the open/close behavior. Designed to make the search surface feel first-class, not grafted on, and to communicate processing during indexing delays.
REEL Production search
Final dev version. Single input, context-aware ranking, progressive loading on large datasets. Always one keystroke away from the global nav.
Context-aware ranking
Results get ranked against the user’s current page. If you’re in an event, that event’s attendees come first. Cross-platform matches are still there, just below.
Single input, always give results from both
Don’t make users pick events vs attendees immediately. Accept anything then differentiate at the result level: icon, metadata, type chip.
Clearly show loading states
On massive datasets the index takes real time to build. Rather than hide it behind a spinner, the open/close animation and result-loading states communicate system processing. Users read the delay as “it’s working” instead of “it’s broken.”
Global availability via top-nav placement
Search is always available on every page, it’s the most interacted with component. Consistent with how CS teams already work, just better optimized.
-
~20% ↓
Time to find search results
Across all user types in beta. Expected to improve post-GA as more customers use it.
-
~60%
Secondary searches eliminated
Context-aware ranking reduced the CS 'search twice' pattern to a single search in the common case.
-
Consolidated
Search surface
Eliminated the need for separate event and attendee search pages.
- Use context as a ranking signal. The user’s current page biases result order, which is both expected and improves the results.
- Communicate loading, don’t block on it. Progressive loading is a real constraint at scale; show results as they come in and show loading when more is coming.
- Platform-level UX has compound value. Time saved per-search is small, but across an entire CS team using the platform all day it adds up.
- Early eng collaboration changed the direction. Performance ceilings at scale required pagination and lazy-load patterns.
- If repeating: push for more analytics prior to changing search so the context ranking engine can be improved, that way we could judge on more than just speed.
Deep dive
Curious about the specifics?
Adoption cohorts, revenue pivot data, prototype walkthrough videos, and the internal PRD are available on request during a portfolio review.