Internal Search Database
The goal of this Colgate-Palmolive engagement was to bring Google Cloud search into Colgate's internal databases - allowing faster, more efficient searching of the various types of information that were previously searchable in disparate locations.
This is one of the first public projects involving this particular Google Search API, and I was ecstatic to assist in designing the interface.
When I was introduced to the project, all of the research and foundation had already been completed by Google. My task was to take what we had and produce a short-term UI for Colgate, using the pre-built structure of their POC.
Essentially, Colgate had multiple databases of information that were previously disconnected and used different tools. The goal of utilizing this new Google Search API would be to bring together results across all databases into one search result list - voila! This is exactly what Google Search does best, except in this scenario we are utilizing this search for Colgate's internal data.
The first thing I did was try to understand how this all flows together. The Google API was fairly limited, so I needed to work within its constraints.
The major user flow was fairly straightforward. Due to the time constraint of this project, this was as far as we could get for user flow understanding.
The one area I had some autonomy was the UI. The first thing I did was look at how other search sites handles result listings, especially ones that include images and multiple rows of data.
I’ve collected a variety of competitor’s solutions to research and learn from - for what is and isn’t working. The goal of competitive analysis is to analyze the best practices in the industry, so that we can give a seamless and satisfying experience for future users that is tailored just for them.
Unsurprisingly, I took a good look at Google search (images, shopping, normal results) since we wanted to keep this within the Google aesthetic as much as we could, without being Google.
There are 3 major aspects in this interface that I needed to iron out:
1. The search bar - what should be the top-level options?
2. The filters - How do we manage filters for results with different metadata?
3. The results - How do I separate results with differing metadata? And, how do I combine them into one consistent interface?
The search API also came with a set structure for data on the page - search would sit at the top, filters to the left, and search results in the center. I would need to work within these constraints, but thankfully the design pattern was standard.
I went through various iterations, testing out different formats for the search results. The biggest challenge was to find a way to list out data from disparate sources, without anything looking too out of place.
This new search API would be pulling data from 7 databases. To make sure you knew what data came from where, I implemented a color-coded tagging system. Because I knew this would be a temporary UI, it was very unlikely new databases would be added to this before they migrated fully over to their complete product.
You can search by individual source type, or by all sources. Search results would populate as you type within the keyword box, with color-coded tags to denote which data source they originate from.
When users search by "All Sources", the filter is hidden due to there not being enough overlap between metadata. To filter further, users will need to select a specific Source, which will reveal relevant fields.
In addition users can sort by recipe number, and ascending/descending. Pagination was also implemented to control the number of content shown (a limitation of the API, but useful nonetheless).
Colgate-Palmolive's internal search was presented at Google Cloud NEXT 2018, which was a remarkable milestone for the API. Although this project was a temporary interface and has since been deprecated, it set a precedent for future API collaborations.