Query Builder

Self-service reporting on a modernizing data platform

Context

Query Builder was the self-service reporting experience for the newer, modernizing data platform at athenahealth. Where the legacy reporting library gave users access to standard and saved reports, Query Builder gave them the ability to construct reports themselves — selecting the data fields they wanted, defining the filters that narrowed the view, and running the resulting query.

The users were experienced with reporting but not with data platforms. The design had to make constructing a query feel like a reporting activity, not a database activity.

Query Builder was one of my first pieces of work on the reporting product line. It also became the surface where cross-team design collaboration with adjacent product-line teams shaped the direction.

Role

Lead UX/UI Designer, sole designer on Query Builder. Product ownership sat with Product Management. My work went beyond receiving requirements — SME conversations, problem framing, interaction design, cross-team alignment, RITE-based validation.

My manager was a thinking partner and, during the later platform-adaptation work, a co-explorer as we both learned the newer platform's capabilities and constraints.

Starting point — a direction I wasn't convinced by

A design direction for the query-configuration experience existed before I joined. I wasn't convinced by it. I spent time with subject-matter experts, my product owner, my manager, and existing research to understand the actual pain points around constructing queries. The problems users described were more specific than the prior direction was addressing:

• Understanding data definitions well enough to know which fields to select
• Building a query quickly, without having to hold too much in memory across steps
• Being able to preview the data result while configuring the query, to verify the query was returning what they intended
• Saving ad-hoc queries with configured columns and filters
• Sharing configurations with colleagues
• Scheduling recurring runs

The through-line was reasoning-in-context. Users wanted to construct a query and evaluate the result within the same experience — not build a query, run it, discover it was wrong, and start over.

I developed a different interaction direction around that reasoning.

Interaction direction

The core pattern:

• A configuration surface on the left for selecting fields and defining filters
• A main workspace on the right where selected/active configuration was represented and could be manipulated in context — including the ability to see the query result inline
• Contextual actions on selections — show/hide columns from the configuration itself, adjust filters against the active view

The mental model was: configure on one side, see the effect on the other, iterate against the live view. The pattern kept users' attention on the reporting question rather than on the mechanics of query construction.

Complex filtering and configuration

Filtering was where the interaction design got hardest — and where a single, uniform control would have been the wrong answer.

Some filter needs were simple: pick a value, apply a filter. Others were substantially more complex — different attribute types require different configuration controls to be usable. A date range needs a period selector. A categorical attribute needs a multi-value selector. Forcing every filter into one uniform control would either flatten these into an unusable lowest common denominator or force users through configuration steps that didn't fit what they were trying to do.

The interaction foundation was the same — searchable, categorized filter attributes on one side; configured filters on the other; results below — but the specific control used to configure each filter adapted to the type of attribute.

The reference shown here includes two of the control patterns that emerged from the design work: a period selector for a date attribute, and a categorical multi-select for taxonomies with a manageable list of values. Adjacent product teams later needed variations of this — including more complex Boolean-style composition, and a hierarchical multi-select for a domain-specific measure taxonomy with a much deeper tree structure. Those variations shared this same interaction foundation but used control types fitted to their domains.

The columns-versus-filters reshape

The most useful design realization came from working with adjacent product-line teams whose users had different data requirements from the reporting team's users.

My initial model had assumed the attributes users needed for output columns and the attributes they needed for filters came from largely the same set. It's a tidy assumption. It turned out to be wrong.

Some attributes were meaningfully filterable but not useful as output columns — they were how you narrowed the data but not what you wanted to see. Others were useful as columns but not as filters. Forcing them into a unified configuration model would have produced two subtly wrong experiences instead of one right one.

The design evolved. Column selection and filter selection separated into distinct workflows, while the broader interaction foundation — the configuration-to-workspace pattern — stayed intact.

That specific realization was the concrete instance of a broader shift I had to make in my own thinking: from "Query Builder is one unified configuration workflow" to "Query Builder is a coordinated set of distinct configuration workflows that together form one coherent experience."

Cross-team collaboration

The query-configuration problem existed across multiple product-line teams at athenahealth, and organizational awareness of that overlap pre-existed my involvement. I co-led a cross-team design collaboration with a designer from an adjacent product line — both of us officially designated as design co-leads for the effort. We pair-owned the design direction, worked through UX-level frictions between ourselves before they surfaced to the wider group, and informed the broader cross-functional team.

We aligned on a shared interaction foundation for query configuration. We also deliberately chose not to standardize everything — three specific capabilities (Boolean-style filtering, hierarchical multi-select, and different entry points into the query experience across each product surface) were preserved as domain-specific by explicit agreement rather than by drift.

The deeper discipline this work asks of designers — the judgment about when to align, when to preserve difference, and what to reshape in your own solution — I've written about separately in Your Users Don't Care How Your Teams Are Organized.

For this case study, the outcome that matters most is that the interaction foundation was designed to hold consistency across surfaces without flattening the domain complexity each surface required.

Adapting through the platform shift

Partway through the work, the organization's analytics direction shifted toward a newer analytics platform. Rather than treating this as a rebuild, we made a deliberate design choice: the platform would be embedded within the athenaOne experience so that customers didn't have to leave the product they used every day to encounter reporting. The platform change would be technical, not experiential.

For Query Builder, this meant translating the interaction direction into the newer platform's capabilities. That translation was not free. The platform had strengths but also constraints — some interactions we had designed for could be achieved directly, others required working within the platform's out-of-the-box control set, and some required conversations with the platform vendor's technical team to identify how specific interaction needs could be met.

The technical collaboration I remember most concretely:

• Working with the platform vendor's support team on specific capability gaps — for example, how to surface all currently active filters in a way users could scan, and how to make clearing applied filters a fast, deliberate action rather than an incidental one. These are the small interactions that make configuration usable at scale; they're also the interactions that are easy to lose in translation across platforms.
• Working with my manager to think through how our design intent could be realized within the platform's control model. Some of this was collaborative discovery — we were both learning the platform.

The design pattern held through the translation. What changed was implementation, not the underlying interaction model.

RITE validation

We tested the Query Builder direction through RITE usability testing.

The core interaction — the configuration surface, the workspace, the live-preview logic, the separated column/filter workflows — held up in testing. Refinements after RITE were mostly small: layout and spacing decisions to expose more filter controls within a single viewport, and adjustments that made the active-filter state easier to scan.

The design didn't need to be rethought. It needed to be tightened. That's what post-RITE iteration usually looks like when the underlying model is right.

Additional design context

Query Builder was also the surface for a specific user flow that connected reporting into the broader product experience: a user could land on an insights page, click a metric in a visualization, drill down into the underlying data, and open the drill-down result in Query Builder to refine the query further. The drill-down flow shipped first; the standalone from-scratch query-building experience followed.

The pattern was: reporting is not a destination users go to; it's a set of capabilities users reach for from wherever they are in the product. The Query Builder pattern needed to hold together whether it was reached from a metric drill-down, from a saved query, or from the standalone experience.

What I took from this work

• Reasoning-in-context is a real UX pattern for data experiences. Users are much better at judging a query when they can see its result as they build it. Isolating configuration from result forces users to hold too much in memory.
• A shared interaction foundation can accommodate real domain complexity without flattening it. The columns-vs-filters separation is the clearest example. The complex filter interactions are another.
• Platform shifts are translation problems, not redesign problems, if the interaction direction is sound. The design pattern held through the shift because the underlying model was tied to how users reasoned about queries, not to platform specifics.
• Cross-team collaboration, done well, reshapes your solution rather than replacing other teams'. The columns/filters realization came from other teams' domain requirements pressuring an assumption I hadn't examined.

Query Builder didn't have the same validated-but-not-shipped arc as Report Library 2.0 — the interaction direction carried forward into what production actually built on the newer platform. What survived was less the specific screens and more the reasoning-in-context pattern, the columns-vs-filters separation, and the cross-team consistency work.