Autocomplete revolutionized the search experience for users. You don’t have to look very far for proof; you only need to go as far as your search engine or online retailer of choice for a reminder.

Two of the biggest online names — Amazon and Google — are behemoths in their respective categories, and they each owe a large part of their success to their search experience, which relies heavily on autocomplete.

And when you take into account the vastness of their content, the need for precise and relevant suggestions served up before the user hits “enter” makes a lot of sense. Typing a query into either platform’s search bar is like combing the beach for a specific grain of sand. Their autocomplete experiences help users sift through the seemingly infinite to find and discover what they need in as few steps as possible.

With Algolia, online businesses can take the autocomplete experience one step further, adding more intuitive functionality like instant search results and “federated search” (defined below). These autocomplete-based features come with methods that create an immediate feedback loop that increases relevancy and speed and ultimately drives discovery. 

Adding autocomplete to your existing search

“How do we add Autocomplete to our already existing system? Do we need to redo everything? Will it take months, lots of resources?”

As you’ll see, adding autocomplete comes with little cost. But there’s a caveat: the autocomplete component that you use must be built separately from the rest of your website and designed to run independently from the rest of its code. 

Building an independent autocomplete component depends on:

1. How you’ve built your website (monolithic vs. headless)
2. How you’ve built your user interface (monolithic vs. composable)

Step 1 – Replacing a monolithic UI with a headless architecture

Let’s take a quick tour of systems design (Steps 1 & 2) before getting back to business in Step 3.

The monolith

A search user interface (the presentation layer) has two principal tasks: to manage the visual display (search bar, facets, results, etc.) and user interactions (query text input, facet clicks, clicking on results).  A monolithic front-end adds another element, the business and data logic, thus tightly weaving an application’s functional logic into its visual and user-interactive code by design. 

In a monolithic UI, “the parts will become extremely tightly coupled to each other. That’s the very definition of a monolith. The parts will rely on features of the platform they all use. They’ll communicate based on abstractions that are shared because they all use the same libraries.”

Take the example of calculating and displaying the sales tax after a user enters an order. A monolithic front end will calculate the sales tax itself without requesting the amount from a back-office financial system designed to calculate taxes. While there may be good reasons to take this approach, it’s not advisable: you’ll need to recode the front end code when the calculation changes (and taxes often do). Combine this with 10s or 100s of such business logics woven into the front-end code, and you end up with an impenetrable fabric that not even the most advanced engineer will be able to disentangle. 

Worse, the entanglement turns into a knot when one UI component shares its business logic with other components, creating an unnecessary co-dependency among all the UI components.

Developers resist modifying monolithic systems because they claim (rightfully and realistically) that changes take time and are too risky and complicated to attempt. The quick solution is to patch it on, but this only deepens the risk for future changes. And there’s no clean solution except rewriting, or refactoring, the system – those dreaded words that cost time and money.

And yet, change occurs: markets and ways of doing business constantly shift. 

When it’s okay to be Monolithic

It may come as a surprise, but sometimes a monolithic system is a sound design choice – if it doesn’t get too large or complex (or convoluted). Without getting too technical, a single body of code that does everything simplifies the interactions between various system components. To go non-monolithic requires abstraction and additional mechanisms to allow components to run independently (modular) and yet still be able share their data and logic. Monolithic designs simplify things by sharing code and data across the whole system, thereby making all data and business logic globally available.

When it’s not okay to be Monolithic

In this article, we’ll show you why a modern client/server web design cannot sustain a monolithic design. We’ll focus exclusively on a non-monolithic, composable front end (to be defined below), where each UI component is self sufficient and does not share its internal functionality, data, or code.

Headless architecture

Enter headless architecture, which removes the business logic from the front end, placing it properly back in the hands of the specialized back-office systems.

By going headless – that is, by decoupling the front end from the back end systems – the code on the front end is dramatically reduced, allowing the front end developer to focus exclusively on the visual and interactive features. 

A reduced code base with a singularity of focus enables an even greater decoupling and flexibility, which paves the way for composability and easy ingestion of new functionality like autocomplete. 

Composable components

Along with headless decoupling, you also want the presentation layer (i.e., the purely visual and interactive components) to be untangled. This requires the individual UI components to be independent from each other as much as possible, thus enabling true plug & play. Let’s see how that works in Step 2. 

Step 2 – Adding composable components to separate tasks and enable plug and play 

In a composable front-end, each UI element (search bar, menus, buttons, etc.) works independently from one another, performing different functionalities that, when combined, create the full user experience. True composable components can be easily replaced without causing any impact on the rest of the system. 

The goal of each UI element is to solve a particular problem, be easily implemented, and connect through an API layer to other pieces in the system. This setup allows ecommerce companies to combine their favorite in-house and third-party components into one flexible system. 

Being able to integrate third-party components is especially important because the experts who build them continuously evolve their software as market and technology advances. An example of this would be a textual-based search bar that can add a microphone in a single line of code and be transformed into a voice-based search. 

Step 3 – Choosing the best components for autocomplete and federated search 

A composable front end allows third-party developers to build the interchangeable components. These component providers include developers and business experts who specialize in the domain – in the autocomplete example, the developers, designers, and business experts specialize in both search and UI design. 

Our Autocomplete and InstantSearch components provide a headless/composable approach. We’ll see, in the next sections, how our Autocomplete library performs both inter-component and front/back-end decoupling, by doing most of the work itself, mostly requiring that it be placed in the right area of the code and properly configured and parametrized.   

Autocomplete: getting the best query possible 

At its core, autocomplete is a search bar and a place for a drop down list as the user types. A great autocomplete feature will show users the query that will get them the information they need before entering their full search term.

A federated search offers an enhanced autocomplete experience, with a placeholder for facets and multiple kinds of results.

This easy-viewing multiplicity is what makes federated search a powerful autocomplete pattern. An autocomplete, federated search interface can displays different results in different columns, or more generally, in different parts of the screen. For example, in the image above, products appear in the center, drawing the most attention; but suggestions, categories, and articles appear on the sides and below the products, offering the user to go further, to discover more.

Additionally, autocomplete can appear as an interactive popup window separate from the underlying website’s other features. Once they click on an option on the separate window, the user returns to the website.

Under the hood, autocomplete needs API access to the data on the server side. If there are multiple columns of results, each result can come from a separate dataset. 

Putting together the headless aspect (an API call to get information) and the composable part (a popup window that does everything in its own codebase), any online business can get up and running almost immediately. And depending on the configurability of the autocomplete component, going from a simple to an ambitious design should not require much additional coding. 

The benefits of autocomplete

Autocomplete has become so ubiquitous that it’s now found its way onto most sites that use search as a central part of the experience. Even messaging apps like Slack use autocomplete to make it easier for users to find what they need. In fact, Slack is a pretty perfect use case for autocomplete at its best. As a rule of thumb, the greater the breadth of possible search results (how many Slack messages do you send every day?), the more helpful autocomplete is for users. 

Many search-centric sites take the usefulness of autocomplete even further – for example, Blissim (previously, BirchBox), an online beauty retailer and subscription service that provides France’s number one beauty box. 

On the Blissim website, users might want to search for several things: a brand name, a specific product, or even a blog post about how to try a specific beauty trend. To accommodate the number of possible categories a user might be trying to access, Blissim’s autocomplete suggestions branch out into clearly-delineated categories: brands, categories, hints, products, advice, and FAQs.

Blissim is able to provide such a robust autocomplete experience because they have a lot of confidence in their data and the relevance of their suggestions. Their confidence is so strong, in fact, that the website even shows suggestions to their most-visited pages when the search field is empty. 

Collecting data over time is the best way to build this kind of relevance. Blissim has had ten years to analyze their search data and turn it into a tool that helps customers get the best possible search query every time they visit the website.

Instant search results: driving discovery

If autocomplete exists to help users generate the best possible search query, instant search results takes the experience a step further, helping to drive discovery. Rather than update query suggestions in real-time, instant search refreshes the actual search results page as the user types their query into the search bar. 

InstantSearch is a complete set of composable components that work separately and interchangeably. So it has the same advantage as Autocomplete, being relatively simple to integrate into an existing application.

To see InstantSearch in action, let’s look at Lacoste as an example. The popular clothing company’s French website provides a truly interactive search experience by refreshing the search result page as the user completes their query. For example, if the user starts by typing the letter “d” into the search bar, the search results page instantly updates with product names containing the letter “d”. However, if the user continues to type and enters “dresses”, the results page now narrows the items to dresses and even shows promotions on dresses. 

Adding this layer creates a whole new experience for the user. Rather than trying to predict the user’s query, instant search tries to predict the most effective end result — which is normally withheld until the user hits “enter” — instead. Rather than sift through categories, the user is presented with the most relevant items that match their query, which gets them from point A to point B even more quickly than if the website relied solely on autocomplete.

Putting it all together: a great end-to-end experience

The ways a site can cater to its users are myriad, and there is no one-size-fits-all approach. Let’s look at two different examples to illustrate this point.

Firstly, consider a pharmacy with both a patient portal and a site for doctors to use. While the library of results would be identical for each group, how these two audiences interact with their respective websites would be very different. It would be up to the pharmacy to consider which search functions would deliver a great end-to-end experience for each audience, which may involve tailoring the autocomplete suggestions for each site or serving up instant search results geared toward each audience. 

While offering refinement is helpful, it can also lead people astray. Consider a user logging into Open Table to make a dinner reservation. They could be searching for a specific restaurant, a type of cuisine, or a location. Trying to narrow down results too early might actually limit the user experience. Unifying all three possible paths into one display area using autocomplete with federated search ensures that the user won’t be led down the wrong path. 

When it comes to building a great search experience, building an interface that enables search and discovery should always be considered. For example, Mobile now represents more than 50% of Web traffic in the US and Europe, and even more in developing countries; having an autocomplete component with Query Suggestions is therefore a must have in order to accommodate the limited real estate. But even on large displays, autocomplete provides an easy-to-use interface that offers a variety of choices that broadens a shopper’s possibilities.

Let your data lead the way

At the end of the day, the best online experiences are the ones that feel tailored to the user. The more personalized, relevant, and helpful the search results, the easier it will be for the user to get where they’re trying to go. 

Great data is the key to achieving this. When you collect lots of quality data over time, it gets easier to learn about users’ habits and be able to predict them — and then serve up the best search experience to cater to those habits. 

A personalized search experience isn’t something that happens overnight; it takes patience, analysis, and a willingness to experiment. But if you want to start building towards that experience, the time to start is now. Check out our demos or request a demo. The sooner you start collecting quality data, the sooner you can find your ideal mix of autocomplete and instant search elements.