Search by Algolia

Sorry, there is no results for this query

How a one-to-many API-first design can deliver diverse experiences for different users

Apr 21st 2022 product

How a one-to-many API-first design can deliver diverse experiences for different users
facebookfacebooklinkedinlinkedintwittertwittermailmail

We’ve previously written about creating a many-to-one search experience. A multi-view, federated search a technique used to search and display multiple data sources in one interface.

The data sources can be any discrete database. If you run a media streaming service, perhaps your first data source is movies and your second is TV shows. If you manage an online fashion retailer, you could have different databases of men’s, women’s, and children’s clothes.

Whatever the specifics, many-to-one allows you to search through all your data sources via a single API call. Many-to-one offers a huge improvement to customer experience—users can search multiple databases at once, rather than performing the same search in each data source. But that’s not what we’re talking about today.

Instead, we’re focusing on the next step: one-to-many.

One-to-many takes that one API call and uses it to serve many different search experiences on multiple interfaces. Each interface serves a specific audience with different needs and purposes. For example, you may have interfaces for your users (customers, employees, or partners) or devices (web, mobile, or desktop). In the next section, we’ll take a closer look at a few of these applications.

What do one-to-many experiences look like?

There are hundreds or thousands of possible interfaces, each tailored to the unique needs of a group of users.

Consider a media streaming company. They might want separate interfaces for different devices. After all, people interact with a product differently depending on whether they’re on their phone or desktop. The company might also want an internal interface, showing audience activity and trends. Maybe they want to share some of that information publicly, too. The options really are endless.

To explore the possibilities of one-to-many design, let’s explore three applications in more detail: in-store kiosks, merchandising apps, and website discovery.

In-store kiosks

Your average big-box supermarket carries around 100,000 to 150,000 products. Even with perfect signage, customers are inevitably going to get lost. Unless they can find a store assistant, their options are either to continue wandering until they stumble across their desired product or decide not to buy it. Neither is a good option.

The frustrating thing is that retailers usually have the data customers need. They have product location information and stock quantities in their merchandising platform. What they need is a way to share that data with the public. This is the first problem one-to-many can solve. The retailer can take their “single” index and display it via a public-facing interface. The interface can allow customers to search for products and track their location.

(It’s not quite accurate to call it a “single index,” as the search may cover multiple indexes. But even a multi-index search is considered a single API call.)

If the retailer loads that app onto some kiosks and places them around their store, it’s like having a team of always-available retail assistants. Customers can search for products, check their stock status, and find their location in the store. While this is a great experience, this technology can do far more.

Customers can check stock information at other stores, too. Say they want a sweater in a different color but it’s not available at their current store. Perhaps they can order via the app and pick it up at a different location on their way home. It blends the experience of in-store and online, offering customers the best of both worlds.

Merchandising apps

Think again about the data a big-box retailer has access to. It’s not just basic information like stock quantities and aisle location. They have a wealth of transactional data like sales and returns. That information is meaningless to customers but priceless for internal employees.

Retailers can then take that same data and create an additional search interface for merchandisers and marketers. They can use the merchandising interface to examine customer buying patterns and evaluate product performance. They can measure the impact of promotions and assess profitability. They can also select products for immediate promotion and design lines for their next season.

Website discovery

As the world’s leading crowdfunding platform, GoFundMe supports an incredible range of campaigns. Memorials for loved ones, emergency relief after disasters, creatives looking for patrons, businesses searching for backers, the list goes on. With such a broad range of campaigns, finding what you’re looking for (or interested in) is always going to be a challenge.

Using one-to-many, they began building out different “discovery” pages for each cause: medical, education, environmental. Instead of exploring all campaigns, users enjoy a filtered experience. But discovery pages were just the start.

GoFundMe’s team designed another experience for the site’s homepage. Using a carousel, they could show featured campaigns, helping to publicize select initiatives.

Why is one-to-many important?

One-to-many offers almost limitless possibilities. But if in-store kiosks, merchandising apps, and improved discovery don’t whet your appetite, you may still be wondering why this is so important. There are two key benefits one-to-many offers:

#1 You delegate back-end development work to third parties

Technology giants like Amazon or Google have enormous engineering teams. If they want to create a new search experience, they can throw a hundred developers at the problem. But most other businesses aren’t so well-resourced. Developing a new search experience means rethinking data structures and rebuilding the search interface.

Unfortunately, that trade-off means companies don’t invest in in-store apps or new in-app searches. They delay, postpone, and ultimately miss opportunities.

But one-to-many offers a fix. Think about it as delegating the back-end work. Once your data sources and search API are set up, your search provider manages the upkeep and maintenance. It’s like you’ve delegated the work elsewhere, freeing up your engineers to focus on what matters. That brings us to the second benefit.

#2 Your engineers can focus on the functionality you want to deliver to your users

By eliminating back-end development, your engineering resources suddenly go a lot further. Instead of starting each new project with weeks or months of back-end work, you can jump straight to the important part: building new experiences.

That’s especially important today with the world still adapting to the pandemic. Over the past two years, buyer behaviors and preferences have evolved at breakneck speed.

The companies that thrived during the pandemic were the ones that quickly adapted like restaurants offering curbside collection, events going virtual, and local retailers launching fully-fledged ecommerce stores. With one-to-many design, businesses can move quicker, tackle more ambitious projects, and thrive during difficult times.

One-to-many means doing more with less

Few organizations have the engineering resources of Amazon or Google. For most companies, investing in new experiences is a question of compromise. Developing an in-store kiosk or a new website discovery experience means not doing something else. Engineering teams often push out decisions, delaying projects and losing impact in the process.

At its heart, one-to-many is an efficiency benefit. Once set up, it entirely eliminates ongoing back-end development. It frees your engineers to focus on the front end, developing new and exciting experiences. In short, it allows you to do more with less.

About the author
John Stewart

VP Corporate Marketing

Recommended Articles

Powered byAlgolia Algolia Recommend

The (almost) ultimate guide to site search
product

Ivana Ivanovic

Senior Content Strategist

Search personalization 101: how to capitalize on personalized search and discovery
ux

Catherine Dee

Search & Discovery Writer

What to look for in a Search API
product

Benoit Perrot

Director, Engineering