Report Library

Redesigning a mature reporting ecosystem's discovery layer

Context

Reporting at athenahealth was embedded inside the main product customers used every day. Users didn't navigate to a separate destination — they accessed reporting from within the product they were already working in.

The ecosystem was mature. Legacy reports on an older data foundation coexisted with newer reports on a modernizing data platform. Customers depended on both. Reporting had accumulated across years of releases, and the surface for finding, understanding, and using that content — the Report Library — had accumulated with it.

The design brief for Report Library 2.0 was not to replace the ecosystem. It was to build a coherent access layer across the transition — one that let customers find, understand, and manage reporting content at the scale it had reached.

Role

Lead UX/UI Designer, sole designer on Report Library. Product ownership sat with Product Management. My role went beyond receiving requirements — research, problem framing, experience direction, RITE-based validation, and MVP prioritization all flowed through my design work. My manager was a thinking partner and alignment support. One PM owned the broader analytics space, of which reporting was one part.

Report Library 2.0 was a full UX rebuild. Enhancements continued in parallel on the legacy 1.0 experience.

The problem, as first framed

The initial framing was straightforward: a large, aging reporting library with weak search, accumulated categories, and users complaining about the friction of finding things.

The natural design problem was better search, better filters, better metadata. Ship a redesign that made finding a report easier. It sounded like a well-scoped project.

It wasn't.

Research changed the problem

I ran generative research using three concept stimuli — an approach I've come to describe as concept-led generative discovery. The purpose was not to validate a predetermined solution. It was to test whether the problem I thought we had was actually the problem.

Approximately six customer-facing participants worked through the concepts. Their reactions did most of the work.

What surfaced was not primarily about search. Users described three related struggles:

• Confident reuse. They struggled to reliably return to reports they had used before.
• Trust. Even when they located a report, they weren't always sure it was the right report for the question they were trying to answer.
• Loop closure. They struggled to close the loop between running a report and using its result — particularly for recurring reporting that ran on a schedule.

The reframe I ended up with was more useful than the one I started with:

From: "How do we improve Report Library search?"

To: "How do we help users discover the right reporting content, understand whether it's relevant, return to what they use repeatedly, and manage that content over time?"

That reframing looks small on the page. It isn't. It's the difference between a search-box project and a lifecycle project. Everything downstream — design principles, RITE scope, MVP prioritization — followed from it.

A counter-intuitive systems insight

The most useful thing the research produced was an observation I would not have arrived at from behavior data alone.

When users couldn't confidently find or trust an existing report, they sometimes solved the immediate problem by creating another one. A one-off ad-hoc report. A saved query. A quick copy-and-modify. Sensible for the individual user. At scale, a problem.

Each new report made the library larger. A larger library was harder to navigate. Because it was harder to navigate, users had more reason to create new reports rather than search through the existing ones. Because there were more new reports, the library grew larger still.

The loop reinforced itself.

The design implication changed the shape of the work. Making report creation easier would worsen the underlying problem, not solve it. The work had to reduce the friction of finding and confidently reusing existing reports so that the incentive to create new ones dropped. Not by blocking creation — users had legitimate custom needs — but by removing the pressure that made creation the easier path to what were, in many cases, reuse problems.

Discovery, comprehension, and lifecycle became joint problems, not separate ones.

Four experience principles

The design surface was broad — search, categorization, metadata, faceted filtering, sorting, descriptions, favorites, pinning, scheduling, admin governance. A feature-by-feature prioritization conversation wouldn't have held together.

I organized capabilities around four experience principles so stakeholders could reason about why different capabilities mattered before deciding which belonged in the MVP.

These were not a formal, company-endorsed framework. They were how I organized the design conversation, and they later held up as a way to structure the cross-functional MVP prioritization workshop.

Design direction

Report Library 2.0 became a full UX rebuild of the discovery and access layer. The interaction foundation was preserved where users had strong prior mental models (the table/list foundation for browsing a large inventory). Behavior around discovery, comprehension, personalized organization, and lifecycle was substantially redesigned.

Findability. Stronger information architecture and category-based browsing. Faceted filtering across Type, Owner, and Tags — within-facet OR (multiple selections in the same facet broaden results) and cross-facet AND (selections across facets narrow results). Improved sorting and grouping across the report list.

Comprehension. Report descriptions and richer metadata surfaces (owner, last-run, tags). Query configuration exposed so users could evaluate what a report contained before running it.

Frequent-use access. Constrained pinning — up to approximately six reports pinned to the left navigation for immediate access. Distinct from the broader Favorites collection, which was preserved.

Lifecycle. Scheduling improvements including recipients configuration. Retrieval of scheduled outputs through an Inbox / result experience. Admin capabilities for identifying stale content, archive/housekeeping policies, and lifecycle governance.

How I defined "done"

Design direction gave the shape of what to build. Acceptance criteria gave the shape of what "done" meant per principle — the observable conditions that would let the team see whether the design was working, not just whether it existed. These sat alongside the design as a working document, referenced during iteration in RITE and used to frame the MVP prioritization workshop.

Reconstructed here at the level of intent, not the exact wording of the working document.

RITE validation

Validation happened through RITE usability testing with approximately 6+ end users — a largely fresh cohort, with only one participant overlap from the earlier customer-facing participants who had joined the generative research. Different research phases benefit from different participants: discovery benefits from breadth of perspective; evaluation needs the actual users.

RITE covered three scenarios that together tested more than any single-screen redesign would have.

Scenario 1 — Find, understand, and run a report

Users could locate the target report. The more interesting behavior wasn't where they clicked — it was what they relied on to confirm they had the right report. Description, metadata, and query configuration mattered as much as location. Search behavior showed users expected forgiving retrieval: they used terms like "denial" and expected relevant reporting content to surface, rather than remembering exact report titles.

Scenario 2 — Scheduled reporting lifecycle

Not just creating a schedule. Configuring a recurring report with recipients. Locating the resulting scheduled report. Accessing the most recent result through the Inbox / result experience. Downloading it. Returning to manage the schedule, including pausing it. The moderator probed users' expectations for where edit and delete controls should live. The design treated scheduling as an ongoing relationship among three objects — report, schedule, and generated output — not as a one-time action.

Scenario 3 — Housekeeping and governance

Users identified stale or potentially unused reports using signals such as ownership, last accessed/run, and modified/updated timestamps. Follow-up questions moved into generative territory: how should administrators handle stale, orphaned reporting content? What signals do they need before taking action? RITE wasn't used only for UI validation here — the session became an opportunity to deepen understanding of the reporting lifecycle.

Retrospectively, the three scenarios fit a lifecycle framing:

Discover → Understand → Run → Schedule → Retrieve → Manage → Govern

This framing was not something the team formally named at the time. It's a retrospective synthesis. That the framing holds up in hindsight is itself evidence that the redesign was doing lifecycle work, not screen work.

Validation summary. Participants completed the core workflows across the scenarios and showed repeated patterns in how they interpreted the experience. RITE surfaced issues — terminology, action discoverability, expectations about where certain functions should live — that we iterated on during the study. The underlying mental model and workflow held up. Refinements after iteration were mostly at the level of labels, placement, hierarchy, metadata, and interaction detail — not conceptual rework.

Usability validation of the overall direction, with identified areas for refinement. Not a claim that every proposed capability was fully validated or ready for implementation.

MVP prioritization

A cross-functional workshop was run after RITE — with the PM, the Director of the product line, my manager, and designers working on related product areas.

I did not want the workshop to become a flat feature-ranking exercise. I structured it around the four experience principles so stakeholders could understand why different capabilities mattered before deciding which belonged in the MVP.

The framing shift was deliberate:

From: "Which features do we want?"

To: "Which value areas must the MVP adequately support?"

The framework I brought to the room

I opened the workshop with a working matrix. Capabilities were grouped by which of the four principles they served; each was weighed on the research signal supporting it, expected user frequency, and implementation complexity. The point wasn't the numeric roll-up. It was a structured surface where trade-offs became visible instead of implicit, and where a decision to defer wasn't a rejection — it was a claim about which value areas the MVP had to adequately cover before it earned the right to ship.

Prioritization decisions were collaborative. I did not independently own the roadmap. What I contributed was the framework that structured the conversation, the user-story-level detail that translated the direction into scoped work, and the design judgment on what needed to hold together for the experience to remain coherent.

When the context changed

The validated Report Library 2.0 direction did not ship in the form it was designed. The organization's analytics priorities shifted toward a newer analytics platform, and the higher-priority reporting investment moved with it.

I want to be precise. The design was not deprioritized because it failed usability testing — it didn't fail; it was validated. The design was deprioritized because the strategic direction of the platform changed and the newer platform's reporting capabilities became the more valuable investment. Those are different reasons, and only one of them says something about the design.

Validated but not shipped is a legitimate outcome in a mature product organization. The reasoning, the research findings, the experience principles, and the design judgments carried forward where they were applicable.

The mistake to avoid in this situation is defending the work as if reprioritization is a personal or design failure. It usually isn't. Treating it as one leads to worse decisions later — protecting solutions past the point where the underlying problem framing is still right.

Strategic exploration — questioning the top-level model

As the reporting requirements continued to evolve and the newer platform came into scope, I started asking whether Report Library should remain the top-level destination at all. There was a case for a broader hub experience in which reporting became one layer within a larger analytics and insights environment.

This was strategic exploration, not an approved strategy. I raised it, discussed it, sketched around it. It was not endorsed as an organizational direction. It was not built.

The willingness to ask the question is what this section is about. Instead of protecting the Report Library 2.0 direction because I had invested in it, I asked whether the ecosystem was best organized around Reporting as the top-level model given how the platform and its users were evolving.

What I took from this work

• When a user behavior looks like a demand signal, check whether it's a symptom. Ad-hoc report creation looked like feature demand. It was a discovery failure feeding itself.
• Lifecycle framing beats feature framing for content that accumulates. Products where users create things over time have a lifecycle problem that initial design usually underweights.
• Experience principles hold up better than feature lists for prioritization structure. They let stakeholders reason about why something matters.
• Validation is an outcome. Shipping is a different outcome. Both are legitimate. Neither is the whole story.
• Willingness to question the problem scope matters more than defending the solution.

The Reporting ecosystem I redesigned did not ship in the form it was validated in. What survived — the research, the principles, the lifecycle framing, the strategic questioning — is the part I would carry into any similar problem. Not because the specifics transfer. Because the intellectual shape of the problem usually does.