Complex queries.
A more familiar way to work.

01The DevOps problem

Developers needed a clearer answer about their services.

A digital product is made up of services: individual parts that do jobs such as signing someone in or processing a checkout. DevOps teams help build, run and keep those services reliable. They use metrics, or measurements of activity and performance, to understand what is happening.

For services created natively in DevPortal, Intuit already supplied Base Metrics. When developers needed a more granular answer, they could build queries on top of a Base Metric, adding filters and calculations. The result is a Custom Metric.

DevPortal did not yet support that creation journey. Developers used Grafana or Wavefront, or wrote PromQL, a query language, in YAML configuration files. In the configuration route, feedback arrived after the changes were applied. Developers unfamiliar with PromQL sometimes skipped Custom Metrics setup and published service data to Wavefront instead.

Many DevOps engineers were already comfortable with Grafana and Wavefront. The challenge was to give them a compelling native experience without asking them to relearn familiar work, while making the capability more approachable for those who needed guidance.

02Learning the domain

Before designing for engineers, I learned how they worked.

I joined without prior knowledge of the domain or product. I spent several weeks learning how developers worked, why services needed Base Metrics and Custom Metrics, and how the existing tools supported that work. Building this understanding was essential to designing a credible DevOps experience.

I started with the brief from Product and Engineering and the foundational interviews conducted by Product. I worked through the current journey, clarified dependencies with the team and translated technical requirements into decisions a user would need to make.

My responsibility covered experience and interaction design, prototypes, usability testing, refinements and handoff. Product and Engineering shaped priorities and feasibility; design leadership and the wider team collaborated on direction and review.

03What users needed

Familiarity became the adoption strategy.

We needed more than another query editor. The experience had to address workflow fragmentation, the knowledge required to get started and the delay between making a choice and understanding its effect.

I used familiar building blocks: Base Metrics, Operators, Labels, a code editor and a graph preview. That reduced the amount of new vocabulary engineers needed to learn. Native integration then added the value: the engineer could work within the service’s context and manage the Custom Metric where the rest of that service already lived.

I initially considered users with different levels of PromQL familiarity. Testing later showed why that should inform coverage without turning into a rigid novice-versus-expert split: experienced users also valued the Visual Query Builder.

04Customer journey

A complete lifecycle, from first query to recovery.

The journey begins with a question the Base Metrics cannot answer on their own. It ends with a Custom Metric the team can find, understand and maintain. I mapped the entire lifecycle to connect creation decisions to later use.

Customer journey · from a service question to a useful Custom Metric

Open full diagram

A home for the whole Custom Metrics lifecycle.

I introduced Metrics within the service’s IKS Alerts and Metrics area, labelled “IKS AIR metrics & alerts” in the interface. The landing page supports discovery and CRUD (create, read, update and delete), alongside edit history and promotion from a lower to a higher environment.

Error prevention and recovery were part of the lifecycle. Management needed to support changing needs and give engineers control when they made a mistake. Delete used a 30-day recovery window: a deleted Custom Metric was archived and could be restored during that period. After 30 days, it was removed from the user’s view while its history remained in the backend. Promote made the Custom Metric available in a higher environment, where engineers could work with more data points.

The row actions keep routine management near the relevant Custom Metric. Edit history gives a returning engineer context about changes. This matters because a successfully created query is only useful if someone can confidently return to it later.

05Design decisions

A familiar workflow, connected from setup to publish.

1. Establish the right context.

Creation starts with the service’s workload. During testing, the environment is locked to QAL; the user selects a Workspace and Region, US West or US East. The Visual Query Builder subsequently launched in the live environment, after the initial code-first MVP. The QAL lock was a testing constraint. Establishing the environment, Workspace and Region first makes it clear which data the query will address. Progressive disclosure keeps the sequence focused: establish context, build and inspect the query, then add the details needed to recognise and reuse it.

2. Build on a Base Metric, with the right level of control.

sum by (cluster) (
  rate(demo_http_requests_total{
    env="qal", workspace="payments", region="usw2"
  }[5m])
)

3. Combine queries when one is not enough.

“Add more query” lets an engineer build another component query, such as Query B alongside Query A. Nesting connects those components into one expression for the final Custom Metric. The first visual release was scoped to one nested query group, a deliberate boundary agreed with Product and Engineering so the capability could scale gradually.

That limit applies to the visual interaction. Build with Code provides a route for DevOps experts who need more complex nesting. The UX challenge is making the relationship between the components and the final output understandable before the user publishes.

4. Make the result recognisable, then publish.

After inspecting the preview, the engineer gives the Custom Metric a name and description. Additional custom labels identify the resulting Custom Metric; these are different from the query Labels used to filter a Base Metric. Contextual help explains the default workspace and region labels.

The optional “Send custom metric data to Wavefront” control is important: the goal was to bring creation and management into DevPortal. It did not require removing every external destination for the resulting data.

User flow · create, inspect, publish and return

Open full diagram

06Scope & trade-offs

When feasibility changed, I protected the core task.

The delivery direction changed during the project. We began with a native DevPortal experience, were asked to explore embedding Grafana and completed that direction within a week. Engineering’s feasibility review then ruled it out. I returned to the native journey with a narrower first-release scope.

Once scope stabilised, we delivered the code-editor designs within two weeks. Build with Code launched first; the Visual Query Builder followed and became available in the live environment after testing. I preserved the core task through those changes: establish context, build the Custom Metric, inspect its result and manage it in DevPortal.

There was a second scope boundary in the Visual Query Builder: one nested group for the first release. That constrained the interaction we needed to support immediately, while the code route retained greater expressive flexibility. It was a scope decision to communicate clearly, not a reason to hide a limit until the user encountered an error.

07Testing & refinements

Testing changed my assumptions about expertise.

I tested the experience with nine participants through moderated and unmoderated sessions, including in-person and remote testing. Different levels of PromQL familiarity helped us examine both the effort of getting started and control over more involved tasks.

Trace the findings to the design decisions

Research to design · observation, interpretation and response

Open full diagram

08Delivery & impact

From code-first adoption to a live visual workflow.

What the code-first MVP demonstrated.

The pilot included DevOps engineers and managers across QuickBooks, Credit Karma, Mailchimp and other business streams. These measures reflect the code-first MVP: 60% of the pilot group actively adopted creation in DevPortal. The MTTR improvement was a shared programme outcome across design, engineering and operations.

The study recorded an average creation time of approximately 5 minutes 23 seconds. This provides a task-completion benchmark for the tested journey, rather than a before-and-after speed claim.

The work established native Custom Metrics creation and management, with both routes ultimately available in the live product. It gave Intuit ownership of the experience and a foundation for reducing dependence on external creation workflows. The adoption and MTTR figures above are the measured outcomes; they do not represent quantified external-tool savings.

09What I learned

Clarity is how I design for complex domains.

I entered the project without DevOps expertise and learned enough to structure the work, ask better questions and make informed interaction decisions. The same discipline applies across enterprise products: understand the domain deeply, then introduce its complexity at the moment the user needs it.

Familiarity did not mean copying another platform wholesale. It meant respecting the engineer’s mental model while using native context to reduce effort. And simplification did not mean removing control; the visual and code routes gave users different ways to reach the same goal.

Two creation routes. One service workspace. A launched experience that made Custom Metrics easier to create, inspect and maintain.