Sumo Logic Unified Logs and Metrics

In 2015, Sumo Logic, Inc. already a leader in the world of Logs, embarked on a new challenge of adding Metrics capabilities into Sumo Logic’s already existing Logs platform, creating an industry-first Unified Logs and Metrics solution.

“Create Sumo Logic’s industry-first Unified Logs and Metrics solution.”

The Challenge

Empowering users to analyze their Metrics data required enabling them to query the system data in which they were interested and visualize that data on a graph. Once graphed, equipping them with tools to examine their data, detect outliers, compare behaviors with other systems, and cross-reference with Logs would provide them full visibility into their systems.

 

Background

At Sumo Logic, a cloud-based log management and analytics service for machine-generated data, we set out to introduce the industry’s first-ever Unified Logs and Metrics solution.The Guidebook Tours app would provide a highly interactive walking tour experience, serving individuals and families who visit prospective campuses on weekends, holidays, or simply cannot make a scheduled tour.

 

What is Sumo Logic Unified Logs and Metrics?

My Role 

I led the design of the Unified Logs and Metrics query solution. I collaborated closely with our cross-functional team of backend engineers, developers, visual designers, product manager, and another interaction designer. The project commenced in November 2015 and shipped in July 2016.

Product Definition

I worked closely with our project manager to define the product, prioritize and negotiate features, and establish the vision for launch and beyond.

User Research and Experience Design

We introduced user research and testing, which we used to inform the journeys, wireframes, prototypes, and design specs I created.

Leadership

I presented my designs to earn buy-in from executives and stakeholders throughout the project lifecycle.

The Approach

Agile

We followed an Agile process, with daily stand-ups every morning.

Design in Parallel

I collaborated daily with another interaction designer to ensure our individual designs were always informed and in sync.

Design Work Sessions

This project required a high level of cross-functional collaboration: developers, backend engineers, product management, and design. I led highly collaborative design-focused work sessions multiple times per week throughout the project lifecycle. This fostered frequent communication and feedback, stakeholder buy-in, and evangelization of design ideas and concepts.

Top-Down Design

We started with the high-level user goal and vision before drilling down into the lower-level interactions to keep focus on the primary design solution before addressing smaller design details.

Rapid Prototyping and User Testing

We created rapid prototypes and introduced user testing after every major iteration throughout the project lifecycle.

Closed Beta

We hosted a closed beta to test the functionality and usability of our designs without the guardrails of a user testing session. User feedback was invaluable.

The Discovery

Existing Research

For this project, we were designing for 2 personas that the had been defined at the company, Clayton and Samantha.

Our storyboards captured Clayton and Samantha’s goals, emotions and pain points within their Sumo Logic user journeys:

Previous research had also shown that our users are very keyboard-driven. Keyboard navigability was of the upmost importance in the query builder design.

Product Education and Inventory

Learning the Metrics Query Language

The query syntax in the product was created by Sumo Logic. It is powerful and complex. Before beginning to design solutions to help our users build a metrics query, it was essential that I learned the ins and outs of the language.

Learning the Existing Log Query Language

Additionally important to maintaining a holistic user experience, I also educated myself on the existing log query language, a language our users were already educated on and using regularly. At its simplest level, it looks like this:

The existing logs query language was more complex than the Metrics query language that we were about to introduce. It required a high learning curve and many users found it difficult to learn.

A Land of Two Languages

Although we were about to build it from the ground up, it was important that the metrics query didn’t feel like an entirely different product. By understanding what was existing, we equipped ourselves with the knowledge necessary for efficient innovation. Creating common patterns that were well-suited for both Metrics and Logs queries would enable us to later improve the Logs query experience that users currently found difficult, and create a consistent user experience.

Research and Inspiration

We looked at the autocomplete user experience of numerous IDE’s, as they solved a similar problem to the one we were solving for: how to help the user construct a string while following strict syntax rules. As Clayton and Samantha both have engineering backgrounds, this would be a familiar experience for them.

 

Building a Query

Now fully educated on the landscape, we drilled down into the individual user tasks that a user would need to complete within the use case of building a query:

The Vision

To provide Samantha a highly interactive, easy-to-use, keyboard navigable query-building solution, with autocomplete and contextual help at every step. By designing for Samantha, a less tech-savvy user than Clayton, we ensured that both Samantha and Clayton would be able to learn how to build Metrics queries.

The Concepts

Wireframes

To add structure and guidance to the metrics query syntax, we decomposed the metrics query input into a series of three specific input fields, simplifying the process into bite-sized pieces. To further guide the user and offer them contextual feedback, we designed dynamic type-ahead and auto-complete behavior that updated based on what the user had typed, and provided visual feedback for completing blocks of text such as tag-value pairs and functions.

User Testing

We pioneered user testing at Sumo Logic, introducing user testing as a new step to this and all future design processes.

Rapid prototypes received positive user feedback and informed a series of minor design iterations.

A Clayton Solution

Although the structured Samantha-centered design received positive feedback from Claytons, some users still wanted the optional comfort of a single input field that they could type in:

“Sometimes, I just want to be able to type.”

To accommodate our advanced Claytons and allow them to access some less common operators and override defaults that we weren’t exposing to Samantha, we provided an “Advanced mode” that displayed a single input field where the user could type freely without the guardrails of prescribed input fields.

UX Specs

After incorporating user testing feedback, I created final specs for the closed beta implementation.

The Closed Beta

We released a closed beta. And learned a lot.

Sumo Logic Unified Logs and Metrics Closed Beta Demo

Users in the Wild

Once users were able to experience the query builder on their own, they were stuck:

“I don’t know what to type”

Although the query builder guided the users who were familiar with the naming conventions of their organization’s data, it did not direct users who were unsure what their data was called or how their data was structured. They didn’t know what items to pick from the dropdown.

The Pivot

“Create the solution for Clayton.”

Unrelated to the feedback, during the closed beta there was also an executive business decision to pivot: design for the query-driven power user Clayton, not Samantha, whom we had centered our designs around.

Additional Requirements

In addition, we received requirements to accommodate a new format of data that hadn’t been a priority at the start of the project. We had designed for tag-value paired data, but we now also needed to accommodate what is known as Graphite formatted data:

Three New Challenges

The combination of the pivot and the beta user feedback gave us three new design goals:

  • A query mechanism for Clayton that allows him to type freely but still provides contextual help as he types his query.
  • Design a solution that helps Clayton understand his data such that he knows which of the available items in the dropdown is the one he’s looking for.
  • Display both Graphite and tag-value pair data formats

The Second Discovery

More User Research

What was preventing users from finding their data?

We spoke with users to understand the root of their issues, the obstacle that was preventing them from getting started typing in the query. We discovered that many of our users did not know how their organization’s data was labeled, structured, nor organized. It was difficult for them to immediately start querying data without first knowing their data landscape.

While the current design helped them to enter a query so that they may graph, visualize the data, and apply functions, it did not help them with that initial step of seeing all the data that was available.

User Journeys and Mental Models

Our user research helped us to understand our users’ mental model when first searching for their data. We mapped out the user journeys to identify where we could reduce their greatest pain points and provide a solution:

Brainstorming Solutions

Users seemed to need a way to be able to peruse all their data first before adding it to graph, a 10-feet-up view of their existing data. We thought through all the additional benefits that type of view could provide.

Increasing Focus, Reducing Scope

After a few iterations of quick-and-dirty wireframes and rapid prototypes, we concluded that we were attempting to solve too much. We needed to ensure we were focusing on and solving the main user pain point well:

Users didn’t know what to query because they didn’t know what data existed

We quickly got ourselves back on course and regained focus.

The Second Vision

Create an input for Clayton that allows him to freely type his metrics query. Provide contextual help that enables him to explore his data and what is available, in addition to syntax guidance.

The New Concepts

Wireframes and More User Testing

Equipped with an understanding of our users’ mental model when looking for and graphing Metrics data, we explored different concepts for a metrics input field that gave users better visibility into the structure of their data as they decided what to type. Supporting multiple data formats required a flexible layout to achieve this.

In user testing, participants connected with the new concepts immediately. We utilized their feedback in selecting and refining the “winning” concept.

The Spec

Through multiple rapid cycles of user testing, working through the concepts with our team, iterating, and repeating, we discovered a solution that both worked for our users and was feasible for development within our now aggressive original timeline.

High-Level Spec

Detailed Specs

The Launch

We shipped on our original release date, overcoming an unexpected pivot midway through the release. Sumo Logic was the first tool on the market to enable monitoring, troubleshooting, and root cause analysis with Logs and Metrics.

The feedback from users has been fantastic.