Problem:

Your app does not use the data you already have in a way that is personal, contextual, or actionable. This means your applications have limited access to relevant data throughout the organization. Datasources are rapidly expanding and evolving, and your business data exists among all them all.

SE's need a way to bring in your data and showcase a meaningful demo that curates to any organization. Currently, each demo is inconsistent and no easy way to pull in data, customize in the backend and show to the client what they are missing out on: Fusion.

Solution:

Work with the backend and UI team to organize a set of rules for the SE's to follow and implement. This heavily documented process from a Github download to a final working demo lets the client customize what features they want turned on or off. For example, if you're an online retail organization, you will want to showcase relevant info such as photos, reviews, and faceting to that specific user. This Standalone Search UI is that solution to sell the client on Fusion and its capabilities. 

The final result is this responsive app that works on any device or desktop. This example below will walk you through an Online Retail store and some of rules a client may want to see.

Auto Suggest State

User sorta knows what they're looking for. They start to type in "San" and boom! Machine learning comes to the rescue and suggests a few queries the user might like. It's kinda like magic. The information just appears and works. Simple, but oh so complicated. While designing this, I would work with the team and figure out what information is displayed in the backend then figure out what needs to be shown on the front end. Then ask every "W" question in the book. Why does this need to be shown? Which order it needs to come in? How does this work? Why does the user need this. Then design from there. 

Loading State

Being a utilitarian product, some things need to come across human. Without that human touch the user is basically communicating with a robot. Sad part is, we are so addicted to this interaction, we kinda are robots at this point. To ease this process, I designed a loading state to notify the user that some sort of data will be displayed here shortly, as well as the loading bar up top.

Ideal State

This running demo shows this clients ideal state. The search query "SanDisk 4GB" brought up a ton of relevant data that is curated to this user (me!). Lets dive a bit further because this search result acts like any other Google or Amazon search. That's because it is, but this time, it's on your own site and utilizes all of your data in a meaningful way. 

First off, this ideal state is quite ideal. It brought up everything the user wanted to see: Title, description, price, and reviews. This is because the engineer setting up the demo turned on these features. Once on, relevant data gets pulled in and brought to this page. It's awesome.

Suggested Results State

What if the user spells the query wrong? What if they don't choose from the AutoSuggest and just clicks enter? Back in the day, this would just bring up a 404 error message and the user starts all over. With Solr and Fusion, this utilizes the data and suggest relevant information the user may find useful. This scenario, the user types in "SanDiskzzlk". They were probably just trying to search "SanDisk". The design challenge was where and how the user would see this message. Did it need a modal or should it just add a line of text? We opted for this route. If the user liked our suggestion, they could easily click on that and get a deeper, more refined search rather than the generic results we displayed. 

Faceting State

What could the user facet on within the app? Maybe the AutoSuggest wasn't enough for the user to find what they are looking for. Maybe they want to see up front what the store has to offer without typing any search query. Faceting solves this in many ways. We needed a way to show a lot of categories without sacrificing too much space. This solution was the accordion effect, as well as a filter within each category. This was a test round and I was not around to see this implemented for trial and error.