Putting a raw query into a data explorer

Designing a tool for engineers is gnarly

Startups move fast, and often as designers we have to adapt our methods to fit the timeline. There are moments when we have a little more time to explore and dig deeper. This is a great example of one of those time where I was enabled to utilize an end-to-end process and bring a product to life from nothing. Before we get started, here’s the lowdown.

My role was lead product designer, user researcher, UX, and UI. I collaborated with the CEO, engineering, support engineering, and sales on a team with 3 full-stack devs. We also had another product designer focussed on UI/HTML integration. We had about 6 weeks end-to-end from concept to implementation.

Goal: Build a query tool to shorten time to insights.

Brief summary

Faced with the knowledge there was a product gap, I spent time collaborating with the co-founders to talk to users, and figure out what to build with open-ended discussions, explorational wireframes and prototypes. I proceeded to ideate on fitting our query language into an interface and created mocks, specs, and prototypes of interactions. Once we built our alpha, I worked with engineers to iron out the kinks (and there were many) I then conducted some usability tests to catch issuses, discovered a big issue with the raw query flow and designed a fix before we eventually shipped.

I feel really proud about shipping this product and it was recieved well. Catching usability issues early helped a lot. If I could of improved this, getting more data around how users wanted to use it would of helped.

The backstory

So one of the most difficult things about working at InfluxData, is probably how hard it is to understand your user and their needs.

So one of the most difficult things about working at InfluxData, is probably how hard it is to understand your user and their needs. They are devops engineers with needs that seem like an endless feature set of highly technical requirements. They span across every industry: transportation, banks, commerce, security etc. Our users need access to lots of data and fast. This is where Influx comes in, we provide (relatively) easy-to-use tools for engineers to work with time data.

Why are we doing this?

This is probably one of my favorite questions to ask. Often times it’s the most obvious question that no one asks that brings out new revelations. So why are we doing this? Well there’s a few reasons why we are making the Data Explorer.

  1. Business goals — It’s our goal to make working with data absurdly easy, we offer free tools that get users up and running with our data suite ASAP.
  2. We identified a product gap — Previous user research I conducted found that when users were writing queries it could take up to fifteen minutes, that’s a lot of time. Imagine if you were on google spending fifteen minutes trying to find what you’re looking for. The trouble for users was that building great queries takes time, and that the current tools were OKAY at doing their job.

Meet the raw query

What is a raw query you ask? Influx defines a raw query as a string of text that is normally entered into a command-line-interface (CLI), it’s a query and it returns data typically in a graph. Our users have a varying degree of familiarity with InfluxQL which is entered into the CLI.

Example of a raw query with the commands highlighted.

Our users highly technical, but their familiarity with our query language, InfluxQL is varying. We have power users who use InfluxQL all the time, and newbies who may have just installed Influx for the first time and not be aware of how to use it. Our tools are designed to work for both experts and newbies, hopefully making it easier for newbies to get started and also power users to get what they need from it. A requirement of the product is to enable raw query entry for ours users and make it easy to use.

With the raw query there were three opportunities to explore for users

  1. Make it really easy for users to get into raw query mode.
  2. Make raw query mode powerful to add a batch of queries, and manipulate graphs via the raw query method.
  3. See if there’s a way to educate newbies about raw query via the automatic building of queries.

What is the relationship between the raw query and everything else?

This idea combines an explorer idea and raw query into one. You can type/create.

One of the first round of ideas that stuck is above. The idea is to make it easy for users to write queries automatically in a raw query format by typing and getting auto-complete options to fill in the gaps. It has the benefit of educating users, being quick to work with and familiar with power users. The drawback to this concept is that there wasn’t much space for revealing data and also technically difficult to integrate.

This idea expands on the previous, with an explorer pane on the left that revealed lots of data. The raw query informs the explorer what to show. This way, you can type along in the raw query and then make some selections as you get there to narrow your results. While it could be easy to write a query this way, I learned later it oversimplified the complexity of building queries.

Multiple graphs becomes a thing

Through-out the process I used sketches to throw up ideas of how the relationship between the raw query and explorer might work. Some explorations later, our founder felt strongly about moving forward on letting users create multiple graphs within the explorer, this went from a possibility to a prioritity and made the level of interactions of information heirarchy more complex because the raw query and explorer had to be repeatable across multiple graphs.

This idea simplifies query entry by placing what looks like a CLI into the view. That would be familiar with power users, and newbies would understand what it was. The divided explorer and graphs tabs put the raw query front and center. This could work, but what was most important to our users to easily see? I had to investigate and talk to users.

Similar to the previous, this expands the level of depth you can see in one view of your data. Some of the UI just wasn’t technically feasible like the sparkline queries and the explorer took up too much space.

This expanded on a tabular idea to add tabs to switch between the table and Raw Query (labeled CLI). After some investigation, the table is indeed useful, but more useful in the context of switching between graph and table. I combined those in future ideas.

This was the first take on getting in higher fidelity and seeing how we could break the graphs and queries into tabs with all data in a scrollable container on the left. I made the graph primarily because there could be a lot of data and added the table/raw query section below. This idea was the jump-off for another round of iterations.

Honing in

Users indicated that they often want to look at the graph as they create queries.

Users indicated that they often want to look at the graph as they create queries. Since the explorer and raw query weren’t used at the same time we didn’t need to display both at the same time. It felt logical to be able to switch between the two. The raw query view would enable power users to punch out long strings of queries. The explorer view would be used by the more newbie users.

One thing you’ll notice is there’s a global query line at the top. This is to show the current active query that’s being worked on. It serves the purpose of providing feedback and also can teach newbies how to write InfluxQL as they render out a query in the explorer. If they want to edit it, they will be taken into the raw query tab to edit it.

Explorer view if you click the raw query it takes you to the raw query tab

Here you’ll notice I moved the raw query preview into the graph. This created the proper visual hierarchy:

Explorer Tab > Graph > Query > Raw Query / Explorer.

The flow for entering raw query has two routes.

  1. User clicks on the raw query tab
  2. User clicks on the raw query preview in the explorer

Keeping it seperated

Raw query view after coming from explorer view.

I considered to putting the raw query directly inside the explorer but because the team and I felt power users would want to work mostly in raw query mode, and there were more raw query features expected, I felt it best to keep the Explorer and Raw Query modes separate. So as we expanded on them they could continue to be distinct. There were further iterations especially around the explorer but this is the raw query / explorer relationship we ended up building.

Raw query usability issues

Usability testing showed great results concerning the explorer, but the transition to raw query mode was difficult for users. I was very surprised to see even power users tripping up on raw query mode.

It could be summed up like this:

  • Users were unable to successfully complete a raw query without running into errors.
  • Users were forgetting the data they had to work with so they couldn’t complete their query without opening another explorer query.
  • Users were disoriented when switching to the raw query tab from the explorer because they expected to be able to edit directly in the explorer view.
  • Users were surprised when they couldn’t go back to edit their explorer queries once they created a raw query.
“I don’t like that the explorer and raw query are separated. Could they be unified?”

This quote is a great example of how the raw query tabs didn’t match the mental model of our users. We assumed that power users would mostly use the raw query mode and want to create the bulk of their queries there. However, testing revealed that even power users preferred using the explorer mainly. They were prone to errors in raw query mode too and a lot of these errors were related to spelling the correct data types.

Fix all the things

While I expected some newbies might have trouble with the raw query mode, I was very surprised that even power users had a hard time. After all, they were used to working in the CLI, and this wasn’t any different and in fact had more information to help them. I concluded that it wasn’t writing a raw query that was the problem (that’s difficult anyways) it was how users entered raw query mode.

With the timeline nearing an end for shipping the product, I mocked up some options for how we could fix this issue.

There were two things learned from testing that had to be in the next design.

  1. The explorer should be accessible even when in raw query mode since users were misspelling data points making it really helpful.
  2. Bring the explorer and raw query together because it fit all user’s mental models. This meant we had to scrap a lot of features we expected for raw query mode.

Some options to re-design the raw query mode

Option 1 — Here the user selects a mode of writing a query before building it. Raw and Explorer are distinct seperate modes that have no cross-over. If you want a raw query from an explorer query you must copy and paste into the other. The benefit of this interface is it keeps a clear distinction between modes but that distinction also obstructs flow if you wanted to move fast.

Option 2 — This option is the simplest and most straightforward solution. Only one chage here making the raw query preview into the raw query editor. Easy for power users to simply click to edit, and easily fits expectations with an added UNDO to reverse changes. The explorer stays and seperates from builder.

Option 3 — A riff off the previous two ideas, queries start as explorer queries and can be converted into raw queries. This gets the user to “opt-in” for changing into raw query mode so no accidental clicking.

Option 4 — I really like option 3 but I thought it could be even more explicit. In the fourth option, I made it extra clear what was happening by turning a hover over on and added space for some copy to tell the user what was going to happen before they did it.


Option 4 struck a great balance between educating the user and setting expectations. It also kept workflow pretty smooth by making it simple to get into raw query mode.


The final product we shipped with.

I was really surprised by our users in the raw query experience. Despite being highly technical and used to complex interfaces I guess sometimes you just can’t beat simpler designs. With usability testing underway, I had enough evidence to see that it was more beneficial to scrap the features tied to raw query so we could bring everything together to match user’s expectations and how they liked to work.


By our measure the launch of the Data Explorer was a big leap forward. The product deepened our relationship with our users providing a tool they couldn’t get anywhere else. We saw from a batch test of users that when making CPU queries, they were able to get to a finished graphs about 3X faster compared to the tool of choice, Grafana. Our confidence was so high that we decided to move the Data Explorer to open-source to give the community access. Since release, the data explorer has beat all previous releases of our data visualization tools and has increased weekly active users tremendously.

Show your support

Clapping shows how much you appreciated Ash Adamson’s story.