Reporting & Analytics at athenahealth
A mature reporting ecosystem, designed as an ecosystem — not a set of features.
Reporting was one of the most-used and longest-lived capabilities in athenaOne. Customers depended on it to understand and operate their practices — running standard reports, building their own, managing schedules, and finding what they needed inside a library that had grown for years.
I led the UX/UI design work across the reporting product line: the discovery layer users engaged with every day, the self-service query experience they used to build reports themselves, and the operational tooling that governed how reporting content was published and maintained.
The pieces below are focused stories on individual surfaces of that ecosystem. They connect — they were designed to. Reading them together shows how a mature reporting ecosystem behaves when it's treated as a system rather than as a set of features.
Focused case studies
Each story stands on its own. Read them together for the ecosystem view; pick one to see a specific dimension of the work.
Report Library
How generative research reframed a search problem into a lifecycle problem, how four experience principles held together a broad prioritization conversation, how RITE testing across three lifecycle scenarios validated the direction, and why validated but not shipped is a legitimate design outcome.
Read the case study → Try interactive prototype ↗ Password requiredQuery Builder
The self-service reporting experience on the newer data platform. Interaction design for reasoning-in-context, complex filter interactions that needed to accommodate real domain differences without flattening them, and adapting the design pattern through an organization-wide platform shift.
Read the case study → Try interactive prototype ↗ Password requiredThemes across the ecosystem
A shared user model. The people using Reporting were experienced, high-frequency users of a mature product. They had years of muscle memory. They weren't looking for novelty; they were looking for less friction in workflows they already knew.
Lifecycle over feature framing. Reports don't end at creation. They accumulate, get scheduled, get shared, get abandoned. The design work across the surfaces consistently treated content as having a life over time, not as one-time deliverables.
Consistency in the mental model, not in the pixels. Different reporting surfaces had different domain needs. The design work aligned on what users should be able to predict across surfaces without forcing every implementation to be identical.
Willingness to question scope. The most valuable design decisions in this work were often about whether a thing should exist at the level being asked, not just how it should be built.
Additional stories in the cluster
One additional story is scoped but not yet published:
- Designing Through a Platform Shift — a shorter Thinking piece on adapting the reporting experience when the underlying analytics platform strategy changed. Touched on briefly in the Query Builder and Publishing case studies; deserves its own treatment.