Brian Rhea Brian Rhea

Structured Search in an Omnibox

If there’s one thing Google has spoiled us with, it’s the ability to throw a bucket’s worth of words in to a single field and expect magically-relevant results to appear.

It doesn’t hurt that they’ve got an army of PhDs on staff who not only know a thing or two about ranking algorithms, but apparently also know how many golf balls fit in a school bus.

For the rest of us mere mortals trying to cobble together an enjoyable search experience for our customers, we often find ourselves at the mercy of overwhelming search forms that intimidate our users.

The Double-edged Sword of Advanced Search Forms

At Mocavo and FindMyPast, we have several hundred thousand datasets in our indexes. Our customers can search the entire index at once, or they may choose to zero in on a given dataset and search it individually. One such dataset is the very popular 1940 United States Census which has 14 unique columns – and as a result – requires a search form that’s on the cluttered side of cramped.

1940 Census on Mocavo

We’ve tinkered around with hiding some of these inputs behind a “Show Advanced Fields” toggle, but that’s had mixed results. And besides, it doesn’t change the fact that once the customer reveals the advanced fields, they’re still looking at 14 inputs.

Inputs, that by the way, can be really useful. If use the following column-specific inputs, I’ll find who I’m looking for (my gr-grandfather, Thomas Jefferson Tallant) right away:

  • Last Name: Tallant
  • County: Lamar
  • Birth Place: Arkansas

So, searching structured data by column is a great way to dramatically increase the relevancy of results, but still, we want a more approachable means for customers to find what they’re looking for that doesn’t begin with this barrage of fields.

Structured Search in an Omnibox

The notion of having a single search box for a more “Google-like” experience has floated around our offices for a couple years, but how exactly could it be pulled off? Take the example I just used above: if I throw “Tallant Lamar Arkansas” at our search engine as a string of keywords, the likelihood that I’ll get decent results is very low. “Arkansas” will find matches in several unintended columns: Last Name, City, County; the same will be true for Lamar. You get the idea.

But what if we know that Tallant is almost always a last name, Lamar is probably either a last name or a county, and Arkansas is usually a state? If we have a library of likely values to compare the customer’s input against, could we make an initial best guess and provide the user with some UI for correcting our assumptions when they’re wrong?

I think so:

Omnibox Search Overview

As you can see, if we think the word is a name, a date, or a place, we indicate that best guess with a person, calendar, or map-marker icon.

This takes us in the direction of a simpler and more approachable search experience, without losing the accuracy of the column-based structured search that our market expects.

Notice how when I entered “born 1980" that it merges those two previously separate fields together. We could expand on that sort of contextual intelligence in a number of other ways. For example:

Omnisearch Jackson

When Jackson is on its own, it’s usually a last name. But, when followed by Mississippi, it is almost always a city; so the column assignment changes when its context changes.

Teaching Syntax on the Fly

I showed the prototype to Drew, one of our developers, and he had an interesting idea that would educate users on the syntax of commonly used terms like born, died, married, etc.


Power users will learn these time-saving hints as they go until they become part of their natural workflow.

Correct Us When We’re Wrong

Of course, sometimes our first guess will be wrong. In which case, the customer will be able to change the field type and resubmit their query.


Other Applications

Few things are as obnoxious as the unsolicited redesign shamelessly promoted on the Twitters. So trust me, I’m not suggesting that the following sites are not already doing amazing work and giving their customers a fantastic search experience. As I was iterating this prototype, I couldn’t help but wonder how it might be applied to other services.


Already one of the easiest travel sites to use, what if instead of this:

hipmunk's homepage

You saw this:

hipmunk with omnisearch


yelp with omnisearch


amazon with omnisearch




Stay Tuned

We’ll be kicking this around internally for a little bit and getting it wired up to some live datasets for testing.

Take action

Step up your product game

I've helped innovative teams all over the world make better product decisions using Jobs to Be Done. Now it's time to step up your product game with AI + JTBD.

Join the newsletter

Get familiar

Join 1,000+ product people and get practical AI + product tips delivered once per week.


  • Gain a deeper understanding of JTBD
  • Stay ahead of the curve
  • Develop a critical eye for innovation
  • Sharpen your skills

Try some resources

Get started

Instantly level up your Jobs to Be Done mastery and uncover insights that lead to meaningful innovations customers want.

$1 / name your price

  • Quickstart ChatGPT Prompts for JTBD
  • Forces of Progress for ChatGPT
  • Beginner's Guide to JTBD Interviews
  • JTBD Resource Library

JTBD + AI Workshop

Get serious

Enhance Your JTBD Toolkit with AI


  • Better Prompts for Better Results
  • Hands-on ChatGPT for JTBD
  • Interview Analysis
  • Research Prep Essentials
  • Advanced Transcript Analysis
  • Copywriting Mastery
  • Developing Hypotheses
  • ... and more!
Get instant access