Mayank Khanna

Ignite 2.0 Search 🔍

Project Background

After completing the role-based access control capability for Ignite 2.0, the next major feature in the product timeline was the search capability for our users.

Considering the wide range of objects in the system and the nested hierarchies between those objects, the search capability was supposed to solve some major navigation related pain-points for our users.

In addition, the search feature also had to be role-based wherein depending on the role of the user, they would be able to see specific object types within the search results.

Learn more about Cloudistics Ignite here.

For a background on RBAC

Establishing the vision and prioritizing User Goals:

The search feature was in discovery phase during different stages of the product lifecycle and the future roadmap. The changes in the above two factors had a major impact on the requirements and assisted the team in determining which parts of the functionality had to be prioritized for our users.

In order to account for the unpredictability of the product roadmap, I brainstormed different ways the search functionality could be useful for the users. After discussing different use-cases with the product stakeholders, the following themes/use-cases were prioritized during the discovery phase:

  • Navigation: Considering the system objects had nested relationships and different namespaces, the users found it tough to navigate to a particular object in the system until they completely understood those nested relationships. In addition, several of these objects did not have direct navigation links on our side navigation. Hence, search could help our users understand the parent of a particular object and could reduce several clicks to navigate to that object.
  • Discoverability: Due to the nature of the product, an object in the Ignite ecosystem could have properties than identify the object more uniquely than the object name. Some examples of these properties would be MAC address and IP address. Allowing our users to search objects by such properties would empower them to solve their tasks in a more productive manner.
  • Identifiability: As mentioned earlier, the objects in the Ignite ecosystem had different namespaces and two objects with different parents could have the same name making it tough for the user to identify the result they are looking for. Hence, prioritizing such information in the search result by default would act as a stronger search surrogate for a result.
  • Action Shortcuts: Considering the user interface for Ignite is interspersed with user actions to create new objects through modals or forms, search could act as a single source to trigger such actions. This could be thought of being similar to the floating action button experience within Google's material design but with search.
  • Triggers: The Ignite UI also has special modes that could enable the entire system to function in different ways. These actions are not always present in the UI and if present, are purposely tough to access on the UI. Special codewords could be established within search to enable such triggers.

Interestingly, during the final design phase we decided to re-prioritize certain capabilities to account for the development effort required and to keep the footprint of the functionality low.

Identifying the primary relationship between objects

In order to satisfy the user needs/themes that were established, the first step for us was to structure our product schema and identify the primary relationship between the objects among the multiple relationships they shared across objects.

This would help us:

  • Identify the primary parent for an object.
  • Guide the landing destination for the particular object's search result.

After this exercise, it was established that the namespace hierarchy was the most favorable for us to strive towards since it would help the users distinguish two objects with the same name within a list of search results. In this case, the namespace acted as an attribute to establish uniqueness within the individual search result.

Determining all the searchable properties of the objects

The next big step for us to determine the size of this project from a design and technical perspective was to determine all the properties by which the user should be able to search a particular object. This helped us determine the type of search text we could expect the user to enter for building a search query. It also helped us determine the number of variations we could have per search result match and the size of the interface we would have to dedicate per search result to accommodate these variants.

Interestingly, this was one of the most challening tasks to accomplish coz the expectations from the product stakeholders kept on changing as we iterated on the designs. New properties were added and removed as the product evolved and our expectations from the search funtionality changed with that product evolution.

I, intially started maintaining all the objects and properties within excel sheets but finally was able to migrate it to the fabulous product Airtable. Maintaining it in this manner ensured that the changes were easier to manage and gave me the flexibility to quickly chnage things as we iterated and focused on the information architecture and design of the search results. It also helped in evolving it to the role-based search experience eventually.

Designing the search results for all the objects and it's variants

There were several iterations done to improve the information architecture, structure and the scannability of these search results. Each iteration was applied to all the object and property combinations to ensure if all the scenarios were being satisfied with the particular pattern.

I can talk through the various ways in which they were improved and how we achieved the final results. Using symbols in sketch made this very easy and time efficient. 🙌

Presented below are the final designs for all the objects and it's variants. There were several iterations done to improve the information architecture, structure and the scannability of these search results. I can talk through the various ways in which they were improved and how we achieved the final results.

The Interaction Elements

After determining all the the variants for the object results, I had to focus on all the interactions the user will do in order to find the search results. We identified the ways the search algorithm would work and how certain objects would be priortized over others when listing them together.