Product and Engineering, Design and UX

Designing Multiple Layers into Search

On the Product team at ThoughtSpot, we spend a lot of time thinking about search. When a user is searching their data from our Relational Search bar, what’s the best way to display (and simplify) all of the information that comes back? Internet users by and large understand what a search bar does—you type in what you want, and a list of results come back—so search is a strong user experience (UX) convention that we leverage to make it easier to look through your data.

basic search bar.png

Easy enough. But what users don’t tend to encounter on the Internet is multi-component search: that is, when a search engine understands and responds to multiple discrete items from a search query. That’s what ThoughtSpot’s Relational Search engine does.

segmented search bar.png

Instead of only considering the search phrase as a single, whole unit, we’re identifying and assembling several independent items—we call them “tokens,” i.e., columns or values from data tables—each of which has a unique identity, effects, and arrangements. In a recent initiative, the Product team experimented with ways to better visualize this information in our search bar. Our challenge: how can we communicate additional, multi-layered information to a search user without overcomplicating their experience?

Here are the layers we wanted to visualize:

Information layer

Types within

Display type

Token type

Measure, attribute, filter, date, list

Categories

Interaction

Default, mouse hover, currently editing

Categories

Visualized (vs not)

Active, inactive

Categories

Recognized (by the system)

Exact match, estimated match, ignored, error

Categories

Token identity

Column or filter

Text string

Location and linking

Source table, column, table joins

Text string

That's quite a few layers to work with! But this is all significant information for our users. In building a search engine for data, we have to meet challenges and expectations beyond those of "normal" online search. For one: in navigating through data, meta information (e.g., which database a piece of data comes from) is critical... a "Profits" metric in one database could represent something completely different than a "Profits" metric in another. And, speaking more broadly: data is only as valuable as the trust that the user has in it, and precision is not just a "nice to have" feature: it’s fundamental to working with quantitative information.

Anyway, on to the visualization! The last column in the table above describes how we displayed each layer of information, whether it’s a finite set of categories (e.g., cat temperament = nice OR mean), or an open-ended text string (e.g,. cat’s name = "Henry VII"). Each display type has different tools and approaches to consider.

Category visualization

When we’re working with a known set of categories, we can leverage visual keys to express those categories in a streamlined way that makes visual scanning easier. A simple example of a visual key is the common traffic light: it uses colors and location (red/top, green/bottom, and yellow/middle) to convey information more quickly than if it simply printed out "STOP," "GO," or “MAYBE GO IF YOU THINK YOU CAN MAKE IT IN TIME."

Sometimes a layer of information will have so many categories that it's best to express those as text strings anyway (e.g., country of origin = Afghanistan, Albania, Algeria, etc…). Fortunately, the Category layers we’re working with only have a few categories each, so we can display those using visual keys, rather than having to print out the category name each time.

loose dimensions.png

Using a visual key becomes more challenging, though, when you're displaying multiple layers (so, multiple keys) simultaneously.

dimensions mixing poorly.png

We want to display information along multiple layers without having disruptive overlap between the visual keys. To do so, we isolated each layer to a single visual factor (e.g., “background color,” or “shape”), and designed them to overlap in a friendly way. After trying out many versions, we came up with a system that seems to visualize everything without disruption:

 

token map.png

tokens demo.png

 

While we’ll continue experiment with new ideas, this system seems to work well for now. As an added bonus, we didn’t need to use many colors! This was a design constraint we put on ourselves: ThoughtSpot is a product that shows lots of colorful data visualizations on screen, so we didn’t want users to misunderstand how this search bar relates to the charts.

Icons

Simple visual keys (like color) work well when there are few categories, but when there are more (say, more than three but fewer than a dozen), an icon system can be useful. Icons are commonly used in product designs to fill just this need, providing recognizable visual anchors that let users easily interact with an interface. For us, icons came in handy in our search suggestions more than in the search bar itself..

suggestions with symbols.png

The most obvious (and most often successful) icons are ones with strong, established conventions and associations: the magnifying glass (🔍) means “search,” the clock (🕒) often means “recent” or “from your history” in this search context. means "done" or "selected". But the use case we’re addressing requires icons beyond the obvious ones. We’re showing whether each search suggestion is a numeric measure, a date, or a non-numeric column or data value, so we had to get creative to find icons that could convey all of that (plus a few more categories, to boot).

The good news is that symbols can still be valuable even if they're initially not obviously associated with a specific meaning. Firstly, users can learn the symbol-to-meaning associations by using the product (especially if we tip the scales with things like user onboarding and supplemental information, e.g., from a tooltip). An example of this is the hamburger symbol (☰). While this particular icon provokes polarizing reactions in the product design community, it's undeniably an icon that had virtually no inherent meaning before, but it's become well understood enough to be used widely in web design today.

Additionally, the mere display of differentiation has value. Here's an example:

circles and squares.png

Looking at the above, we don't know what "circle" or "square" means. But there is information we can glean. For one, there are many more squares than circles, so circles apparently represent something of relative rarity. Also, circles tend to gravitate towards the top, so perhaps there is a ranking or sorting mechanism that "favors" circles. All of that can be helpful information, even though we don't know the exact meaning of either symbol.

An icon system can benefit from partial understanding, too. What if I were to tell you that "circle" means "animal"? What would you think that "square" means, then? Something like "plant," or "human"? With partial knowledge of this icon system, we're able to narrow down the meaning of "square" from a limitless number of things down to a few likely ones. Pretty cool, huh?

So, given all of those considerations, here's the most promising icon system (so far) that we tested for our search suggestions:

icon list.png

suggest types in search.png

In designing icons, each symbol has its own metaphors, history, and contexts. We went through many versions of these icons (including ones that failed our user tests) to arrive at a workable system, but we'll have to save the individual stories of each one for another time!

String visualization

When there are many (even infinite) categories in a layer of information (like in "person's name"), then we pretty much have to display that as a text string. For displaying text strings inside the search bar, our visualization needs are simple: just state what the user has typed out, including recognized "tokens."

The visualization gets more interesting when we look at search suggestions, though; there are multiple layers of information represented in the suggestions, so we need to convey how these text strings relate to each other via layout and hierarchy.

Layout

For search suggestions, there are some solid layout conventions to work off of. For one, suggestions are generally surfaced in a single column underneath the search bar. Take a look at Google, Amazon, or pretty much any search engine online to see this pattern at play.

suggestions order.png

For ThoughtSpot's search suggestions, we want to display multiple pieces of information: the name of the column, value, or other item we're suggesting, plus the location (we call it the "lineage") of that item. Our early versions kept this information side-by-side, as it's a consolidated view that saves vertical screen space.

suggestions side by side.png

But this layout introduces some potentially unwelcome dynamism to the interface: given that we don't know how long these text strings will be for a given set of data (or even for a particular suggestion), the widths in this layout are unknown and ever-changing. This ultimately makes the experience more fractured and unpredictable.

suggestions side too far.png

One way to resolve this is through another emerging search pattern: vertical stacking for information and its associated meta-information. This is a layout we've seen in a few places, including Spotify and Google Trends. While it does occupy more vertical screen space than its horizontal counterpart, it creates clean, scannable, predictable lines.

suggestions stacked.png

Hierarchy

We're displaying multiple layers of text string information, so we need to visualize how they're related. Within each suggestion, there's a relationship between the suggestion name (the column, value, or other item we're suggesting) and that item's location in the user's database. For some designs, you'd want to design the visual hierarchy to reflect the literal object hierarchy: that is, showing the larger group (the database table or location) more prominently than the "children" underneath it.

traditional groups.png

However, in the case of search suggestions, we can't necessarily "group" items hierarchically, as there are cases where different suggestions come from different sources. Plus, when surfacing suggestions in response to something a user is typing in, the obvious focus should be on the item being matched to the user's input, not the meta-information that further describes the item. So we chose to have a visual hierarchy that emphasizes the suggested item, and leaves the location and other meta-information as a "second read".

suggestions with reverse hierarchy.png

Putting it all together

Between four category layers and two text string layers, we had a lot to visualize simultaneously in the ThoughtSpot search bar. By visually isolating the layers and approaching the challenge systematically, though, we've created a model that we can work off of.

search demo with edit.png

To revisit the goal: we want to display more information without overwhelming. While complexity will always come with some cognitive weight, this system does a lot to avoid that, as we've been careful to contain our visual keys and to prioritize the most important information. We'll continue to test and experiment with the design of the ThoughtSpot search engine, making adjustments as feedback comes in, so stay tuned!

×