Creating an Improved Product Search Experience for Medtech Customers

Whether you want to provide your customers with an online catalog of all the products offered by your medtech company, or you actually want to offer the ability to order products online, a robust search tool can be really helpful. 

Often, a medtech company might have several similar products or components, and it can be difficult for customers to find what they need at a glance. Individually looking through each product listing to find the right item can be a time-consuming task. Medtech companies can take cues from search features used by other industries like e-commerce to make it easier for customers to find what they need and place their orders. People are used to using these robust types of searches in their everyday lives when ordering products from retailers, so this kind of feature can be a real value-add.

In the past, we’ve helped a medtech company build this type of ecommerce-style search feature for their Online Product Catalog. Here are some of the options we included in a significant update to the catalog, based on user feedback.

Advanced Search & Filtering Options

The search feature for the catalog includes the traditional search bar, but also has advanced filtering options to filter the results by kit, part, product number, procedure type, etc. This makes it easier for the customer to find what they need based on the criteria they have.

To facilitate this, we used an open-source enterprise-search platform called Solr. Solr has a lot of built-in features that improved the search capabilities on the platform, while allowing us to customize the search experience based on the customer’s data. This required some structuring and pre-processing of the data on our part before feeding it into Solr, including filtering down the data in a way that would work with the advanced search experience the client needed. To this end, we wrote a very robust importer that handled data imports in a specific order and verified that the data imported without error to ensure data integrity. As an added bonus, building upon the Solr platform made the search experience much faster than what the catalog had previously.

The online catalog was also built upon the Spree e-commerce software framework. Though the client did not want full e-commerce capabilities at the initial launch of the catalog, Spree provided a more robust framework to add on that option down the road. In the meantime, it enabled their team with content curation options on the backend, such as defining images and supplemental documents.

Options to Search for Product Kits

Some products could be sold in kits, but sometimes the customer wouldn’t know the name of the kit–they would only know its components. So, we included an option that would allow customers to search for the full kit based on its components.

To enable this option, we took the client’s data and organized it so that kits were composed of products, and products were composed of components. We wrote code that created topical notes about each component to add context, and logic that fit everything together so that the system would be able to relate an individual component to its associated kits. By relating the data together in that way, we were also able to ensure that any change to a component’s data would be reflected all the way up to its associated kits.

Better Product Matching for Searches

One common issue with a lot of search features is that they can be very literal. If a customer doesn’t type in the product name, item number, etc. exactly as it is listed in the system, it may not turn up any results. To fix this, we updated the system to parse sequences of search terms, so that close matches would turn up the right results more often. For example, product code searches for “CV-12123-F”, “CV12123F”, and “CV 12123 F” would be treated as equivalent and produce the same results.

Some of this functionality is standard within the Solr system, including recognizing common misspellings and variations of words, abbreviations, and differences in case. However, since we were dealing with a set of components and products that were specific to our client’s company, we had to do a bit of work to fill in the gaps between the out-of-the-box functionality and what the client needed. That included pre-processing the data to strip dashes, spaces, and cases out of the product codes before adding them to the system.

Direct Product-Code Search

When a user enters a product code in the search bar and only a single product is returned, we set up logic so that the user would be brought directly to the product page rather than a search result page displaying only that product. This helps customers who already know exactly what they need get to the product page more quickly by eliminating an unnecessary step in the search process.

Product Comparison

When they get to a search results page, customers are able to select the products they want to view, then click a link to go to the product comparison view. There, they can compare the features and specifications of the products they selected to see which is the right option. All of the products are linked in the comparison, so users can go right to the product they ended up selecting. The comparison page can also be downloaded, printed, or emailed if it needs to be shared with others in the organization.

To accomplish this, we set up parameters that allowed a user to click to add products to a comparison list as they went through the site. Once they had selected at least two products for a comparison, a link would appear that would take them to a product comparison page. We set up the product comparison pages as separate entities that would feed in the product comparison codes. This allowed us to create the product comparison links that enabled users to share the comparison information with others.

Component Hyperlink

Several of this medtech company’s products require additional components that are sold separately. We updated the product pages to include hyperlinks for each of the product’s components. These links would take the customer to a search results page that would list out all of the products that contain that component so that the customer doesn’t have to search for them.

This search feature was also facilitated in part by Solr’s native functionality, as well as the manner in which we organized the client’s data to relate relevant components to products.

Back Button Preserves Search Data

We took steps to override the browser back button behavior on the Product Search/Filtration page so that when users click “back,” they are taken to their previous search selection. The standard functionality on clicking the back button was to take the user to the page they were previously on prior to the search (frequently be the Home Page). That can be a frustrating experience for users who want to reference a previous search, as the standard functionality would require them to re-enter all of their search parameters to do so. Overriding this makes for a much better experience in this regard. Our code interacted directly with the user’s browser history, using Javascript, providing additional pages centered on the user’s search actions. These pages would not have otherwise been recorded because they were single page interactions (e.g. filtering on a page). This ensured that users browsing the site had a performant browsing experience (because they were only loading the data for the changing search results), while also ensuring that they could interact with the website in a fashion similar to a classic website.

While your medtech company may have different needs for a search feature than this client, it’s helpful to consider that you can take cues from other industries to create more useful applications for your customers. With more aspects of everyday life moving to digital formats, there could be more that you could do to make product purchasing easier on your customers, and a robust search feature is one way to do that.