vusearchbar

2025

product-design & prototyping,
at vunet systems.

vunet built vusmartmaps — an observability platform that financial institutions use to identify, diagnose, and resolve errors across their distributed components. in 2025, i was hired as a design-consultant, to work on ambiguous asks.

while the product was complex, and comprised many modules, there were only two types of distinct pages where people consumed information — listing-pages (with cards, panels, et-cetera), and table-pages (with many rows & columns).

in both cases, finding a specific item was laborious. there was a search-bar, but it only allowed people to perform keyword searches.

to facilitate more complex searches on pages with tables, vunet had built its own query-language (vql). this allowed people to write functions & expressions to find specific items across loads of entries. however, using vql assumed an understanding of the language & its syntax, which only 'advanced-users' were expected to have. therefore, the ability to write vql queries was limited to specific pages.

if a person encountered a vql-enabled search bar, they had to visit an external documentation-website to understand its syntax (and then come back to the original page to use it). this was impractical, since vusmartmaps was not an exploration-based product — it was meant to help people do specific things, in the least amount of time possible.

so, i proposed a contextually-aware search-bar, that could be deployed across different pages on the platform, helping people find specific items quicker. the idea was to help people:

  1. know what they can search for, when they see the search-bar.
  2. understand how they can perform a search, when they activate it.
  3. narrow down their search, as they type.
  4. remain syntactically correct, if they try to build a vql-query.
activated search-bar on a page.
dynamically updating suggestions based on what the person typed.
navigating through suggestions, and accepting one (performing a search).

i accounted for all possible keyboard-triggers (and the resulting suggestions), error resolution (if people were syntactically incorrect), and left room in the design for the query-language to grow in the future.

to demonstrate digital-tactility and technical-feasibility*, i also built a javascript-prototype.

* a person from the engineering-team was concerned about the number of calls we'd have to make to the backend, in order to recommend items to a person as they typed. so, the prototype demonstrated how the search-bar could store items locally (in different arrays), and perform searches locally (instead of sending calls to do so externally).

acknowledgements:

co-instigator: shobhan; worked with: jithesh, bharat, pukal, nithin, jishnu, arko (all from vunet).