Quick Search
Quick Search is a data retrieval tool that allows engineers to use natural spoken language, instead of complicated queries when interacting with their control systems.
Challenge
For the past 25 years, plant engineers have relied on programming languages such as SQL to query their databases in order to retrieve information.
Our goal was to reduce the amount of time and required skill level for engineers by simplifying the searching experience.
Approach
Quick Search is an entirely new concept for the company, so we sought to design an application that was familiar to the user- but also transformative and innovative.
To ensure we were designing within the comfort levels of our customers, Quick search underwent usability testing and iterative design changes based on customer feedback.
Outcome
Throughout this project, we have remained flexible and received continuous feedback from different sources to influence our direction. We now have a validated prototype that is supported by customers, marketing, and upper management.
My Role, Contributors, & Tools Used
I entered this project after the first round of remote usability testing had been conducted. I was involved in interpreting and organizing the usability testing data into key findings. We would then take those key findings and convert them into features, that provided solutions for our customers. Afterward, I was then responsible for implementing those features into the UI.
Duration: 2 months
Contributors
An additional UX Designer
Research Engineer
Product Marketing Manager (PMM)
Tools Used
Mural
Adobe XD
Microsoft Teams
Google Material Design System
The Design Process
1) Affinity clustering from usability test findings
Version 1 of the Quick Search prototype had just undergone remote usability testing, and the next step was to organize the received feedback.
The usability test was organized by four topics:
Launching the application
Building & saving queries/searches
Displaying results back
Usage of results
Inside of each topic, there were a number of related tasks for the user to perform.
We used the Affinity Clustering method to group feedback under each task by like ideas. We then created titles for these groups, to better understand the high-level messages that were being communicated.
2) Key take-aways
My team and I used the affinity cluster titles to pull key findings from the usability test.
For example, one of the groupings focused on exporting search results. Although each note in this group came from different users and they were not all the exact same, the main idea was that users wanted the ability to export search results regardless of their reason.
We were able to extract this key finding, and because it fell under the topic of “Displaying results back”, we were easily able to identify where this change would need to take place.
We pulled a total of 2-5 key findings from each topic.
An example of the key take-away workspace.
3) Feature Creation
The team and I involved the Product Marketing Manager (PMM) assigned to this project, where together we discussed how we would convert the key findings into solutions.
We ideated on solutions while considering business goals, user demand, priority, impact, and feasibility. Those five constraints lead us to a consolidated list of features we’d be adding to the prototype.
The ability to apply filters to queries (timeframe, area, etc.)
The ability to create and organize tabs, similar to a web browser
The ability to share queries with colleagues
4) Prototyping
I created version 2 of the prototype by implementing the new features into the UI while utilizing the Google Material Design System.
Feature 1: The Ability to Apply Filters to Queries
I added two methods for filtering.
The user has the option to apply “Default Settings” to their queries, and each returned query automatically adopts the pre-defined filters.
The user also has the option of altering the filters on a specific query. For example, in the mockup, the user is changing the timeframe for a query. This change will only affect that specific query without affecting previous or future queries.
Feature 2: The Ability to Separate Queries with The Use of Tabs
“Conversations” between the user and their control system can be organized with tabs. For example, plant engineers may want only want to view data that falls within certain plants. With the use of tabs, they are able to organize each conversation by plant.
In order to prevent the top bar from becoming too crowded with tabs, the user may minimize a tab. Minimized tabs are stored in the ellipsis menu to the right, and are always available.
Feature 3: The Ability to Share Queries
By default, recipients will not have permission to edit the original query. This is done for quality control purposes, but if the sender allows the recipient to edit the query, changes are overwritten on the original query.
