Project Name: Search
Role: Sr Product Designer
Challenge: Redesign the IA and Query Builder
Duration: 7 Months

In the summer of 2019, I joined the product team at Quantum Metrics — an analytics platform for managing product experience. It was a chance to build and develop products that encourage design thinking for our users embedded in product teams within large enterprise companies.

My first week I hit the ground running, and was assigned the Search redesign as my first project. There had been previous attempts to redesign the IA around Search and Query building.. and it needed attention.

To start working on something so large and complex as someone new to QM, I needed to first learn more about the product, who our users are, and how they use it. I shadowed my PM and CS on client visits and was able to ask questions around their search behavior. With my product manager we created and formalized user personas, journeys, reviewed insights, and personas. This provided some insight on the current state of our search interaction.

Planning Phase:

Looking into our pivot data that only 20% of our customers were considered power users (someone who performed multiple term complex queries).

Our current implementation required a deep understanding of SQL syntax and proprietary terminology. If you were new to our system then it would require a power user or webinar to build the language and correct terms just to perform a simple search.

We set our north star to create a super simple flow for the other 80% of users who are performing 1–2 simple predicate queries.

As I got more familiar with the behavior of query building with the team, internal reviewers, and user interviews I was able to form a plan around common paths of how users form a query and a preferred workflow, how our IA should be structured, and hypothesis around key elements that would help improve the overall usability. The usability audit was then shared with the team to begin scoping out priority.

I created a charter and design roadmap to discuss how and when we wanted to test with internal reviewers, external users, the project phases and timeline, the risks, and touchpoints with engineering.

Explore Phase:

I began building prototypes around a few paths and early explorations that had been working with our internal reviewers. We invited a few customers to a round of early user testing to see how they could perform a few query building tasks and then give each task flow a score from 1–5 (1 easy peasy/ 5 too complex).

Her are some early explorations and scenarios:

Once we had some high level concepts we could then start to work on each section of the new components and test A/B options with our internal and external users.

Here is just one example of a smaller hypothesis that might help our users run frequently used searches:

Problem: A customer needs to see all sessions that occurred today on mobile devices and monitor the general health and performance of the mobile experience before a meeting with the team. Users need to get in and get out fast and don't have time to build a large query. They navigate to the mobile dashboard and add a quick filter to the query builder.

Hypothesis: If we were to place a quick filter link for most used predicates, then we could save users time and energy while building their query.

The Process: We provided a few clickable prototypes and invited 5 external customers to participate in a moderated session. First we asked our participants if they would prefer to have them all separated out or in two simple quick filters (one for saved segments and one for pre defined popular searches). After a review with our users and with engineering we determined that the best solution would be to consolitate it into one or two quick filters.

The next question was how should these micro interactions flow?

Hypothesis #1: Should Filters be complete and just run the search? Prototype V1: https://invis.io/W7VCGHHJDMF#/398584394_11

or

Hypothesis #2: Should the quick filters have just the parent predicate and open the builder to allow users to enter their value. Prototype V2: https://invis.io/Y6VCGH4SHZK#/398593378_11

The Results: Our users found it too redundant and not that valuable when they could perform the same task from the dropdown panel. It felt confusing and wondered if the list was subscription specific or if they could personalize the list themselves. Although this feedback was driving some great discussions around possibilities of personalization.. it did not meet our intended goal of providing a list of most used out of the box searches.

The direction we chose:

We chose to apply the valid search logic from v2 to a saved segment quick filter in its place. This fulfilled the request for a personalized list of repeatable segments that users could build, save and run quickly.

Why were these the right decisions for your product, user, and business?

From these early tests, we learned from these moderated user tests with these lofi prototypes that users wanted more access to repeatable searches and saved segments. We began to shift our north star towards promoting repeatable search behavior for our users.

Check out the final results:
https://vimeo.com/429749886