Report Publishing
Reframing an engineering-framed workflow around the report as the primary object
Before and after — the strategic frame
Before. Engineering had built a functionally complete workflow around the technical steps: one screen for pulling and retrieving the report, another for publishing it to staging, another for publishing it to production. Functional requirements were met. The UI mirrored the underlying system operations more than the user's goal. A person trying to move one report through its lifecycle had to navigate across separate screens and complete a long sequence of steps, holding the technical operations in their head as they went.
After. The experience reframed around the report as the primary object. The lifecycle became a coherent workflow rather than a series of screens for underlying system operations. Promote, publish, and related lifecycle actions became contextual operations around the report — not sections a user had to navigate to.
The strategic move underneath: fulfilling all of the individual functional requirements does not automatically create a coherent product experience. The design contribution was recognizing the fragmentation each requirement introduced when it lived on its own screen, and reorganizing the experience around the user's actual job.
Context
athenahealth's reporting product line was moving toward a new lifecycle for reporting content — workbooks deployed and published to customer-facing tenants through a controlled workflow. Reporting was one of the most-used and longest-lived capabilities in the platform.
Engineering had built a proof-of-concept app to manage the workbook lifecycle. The app existed and was functional. The lifecycle it supported was technically real — deploy the workbook to a destination tenant, grant access, maintain over time. What it lacked was product and UX definition: no requirements, no approval gates, no scope rules governing how the tool would work as more teams began using it.
The core business requirement, brought by the PM Director, was concrete and high-stakes: publish reports to production after necessary testing. Every downstream design decision would eventually connect back to some part of this line.
The reporting product line lead asked the analytics-side lead to define requirements and user stories retroactively — cross-team visibility when a report goes live, safety around escalations, before the tool rolled out further. That retroactive definition became the design scope.
The problem, as first framed
The initial framing — the one I received — was that this was primarily an engineering problem. A tool existed. Requirements needed to catch up with it. Publishing to production needed the right gates. Read as an engineering-first framing, the natural design work would have been: make the existing app look better, add the missing screens for approval gates, and document the workflow.
Engineering had produced something that met the functional and technical requirements. My contribution was recognizing that satisfying each requirement individually had resulted in a fragmented end-to-end experience.
That recognition — that the framing itself contained the design problem — was the pivot the rest of the work is built around.
What the engineering framing was hiding
The gap between "functional requirements met" and "coherent product experience" took a specific shape.
- One end-to-end workflow was fragmented across multiple screens. A single user goal — move a report through its lifecycle — had been split into as many screens as there were underlying operations.
- Users had to know where each technical operation lived rather than being guided through the lifecycle of a report. The UI's mental model was the system's structure, not the user's task.
- The number of navigation and interaction steps made a relatively coherent task feel long and complex — cognitive load scaling with system complexity rather than with user intent.
Underneath these three, one recurring pattern: the platform's terminology and mental model had leaked into the workflow. The platform's own "publish version" concept, and its tenant / deployment / replication vocabulary, were being surfaced to users who did not need to understand the platform to do their job.
The reframe
I reframed the experience around the report as the primary object, bringing the lifecycle into a more coherent workflow rather than making users navigate separate screens for each underlying system operation. Promote, publish, and related lifecycle operations became contextual actions around the report.
The report — not the environment, not the deployment policy, not the workbook version — became what the workflow was organized around. From the report, a user could see where it was in its lifecycle, and take the next appropriate action. The system operations became verbs on the report, not sections a user had to navigate to.
Two secondary reframes came alongside this:
- Deploy and publish are separate concepts and need to stay separate. Deployment copies the workbook into a destination tenant; publishing grants access. A workbook can be deployed and still invisible. The design needed to make this distinction visible without exposing the platform's mechanics.
- The platform's terminology should not be the user's terminology. The platform's native "publish version" language was intentionally not surfaced in the app. Terminology worked out with the team: Promote for moving a tagged version to an environment; Publish — later proposed as Release — for granting access, to avoid conflict with the platform's native vocabulary.
How the design actually ran
It was not simply requirement → design → validation. Understanding the technical workflow exposed experience problems; designing the new workflow raised further questions about the system and constraints; those discussions then informed subsequent iterations.
The shape of the process was closer to a loop than a line:
understand the technical model → identify experience friction → reframe → prototype → discuss → refine
Time went to understanding the existing technical workflow, framing and reframing the problem, and working through the information architecture and interactions in the prototype.
Prototyping was a tool for understanding, not a presentation. Building and iterating the prototype exposed gaps and questions that discussions with engineering then closed. Prototypes were how I learned the workflow well enough to redesign it.
Timeline. The compressed design pass ran over roughly two weeks in late July and early August 2026, with a heavy pairing cadence with the engineering lead — multiple walkthrough sessions in the final week alone.
What validation did — and did not — include
- Engineering walkthroughs. Multiple recorded sessions with the engineering lead reviewed feasibility, terminology, and the prototype's proposed workflow.
- Written engineering next-step planning. After a key walkthrough, the engineering lead wrote four next-step requirements framing forward work. The direction was informing engineering's forward planning — not a formal adoption commitment, but movement.
- Reporting strategy scope reply. The reporting strategy lead replied with MVP scope guidance, including alternatives for the approval-gate model (an existing tracker-based approval rather than an in-app pipeline).
- User usability testing. Did not happen inside the scope of this workstream. Reflected below in What I'd do differently.
Design decisions and attribution
Being precise here matters. The conceptual reframe is honest to claim as mine. The specific interaction decisions that flowed out of it were shaped through walkthrough discussions with the engineering lead and worked out with the team.
| Decision | Attribution |
|---|---|
| Report-as-primary-object reframe; lifecycle-centered workflow | Mine |
| Specific implementation of the reframe — Promote / Publish becoming contextual actions on a selected report | Collaborative — worked out with the engineering team through walkthroughs |
| Terminology split (Promote / Publish / proposed Release; platform-native vocabulary not surfaced) | Collaborative — terminology was still iterating in the last documented proposal |
Explicit production gate (typed-PROD confirmation for higher-risk actions) |
Collaborative |
| Distinct visible state for partial / failed lifecycle transitions | Collaborative — grounded in a failure mode called out during engineering review |
| Activity log as a first-class navigation surface | Collaborative — grounded in an audit-trail gap flagged in project documentation |
Attribution held honestly. The reframe was the design contribution I initiated; the interaction details were shaped through cross-team walkthroughs where more than one person contributed thinking.
Requirements alongside design — the retroactive spec
Alongside the interaction work, I authored the retroactive product and UX specification. This was a distinct scope from the prototype and worth naming as its own contribution.
- The retroactive spec. Problem and motivation, glossary, current-state analysis grounded in direct code review of the engineering proof-of-concept, current architecture, draft requirements pending sync, decisions log, and approximately twenty open questions structured as the agenda for cross-team alignment.
- The end-to-end workflow synthesis. A companion research document walking eleven cross-team open questions and closing each against internal documentation and code. The synthesis surfaced an authoritative SDLC / RACI in a platform space that no participant in the workstream had previously located, and resolved a longstanding infrastructure question about how to publish content to tenants matching specified criteria.
A strategic leverage point
The end-to-end synthesis surfaced one question that gated several downstream ones: stay platform-native with zero new Athena-side infrastructure, versus accept a minimal purpose-built metadata table. The synthesis explicitly recommended resolving this first, before specifying the dependent questions.
This is where the design scope reached beyond UI. The valuable contribution wasn't answering the infra-fork question — it wasn't mine to answer. It was recognizing that the fork existed, naming it as the leverage point, and holding it out so the right people could resolve it before more work built on either branch.
Cross-team engagement — how the direction moved
- Engineering lead pairing. Multiple walkthrough sessions established shared understanding of the system, surfaced the friction I was seeing, and pressure-tested the reframe and the prototype.
- Engineering next-step email. Four next-step requirements written by the engineering lead after a key walkthrough suggested the direction was informing engineering's forward planning — though not a formal adoption commitment.
- Reporting strategy scope reply. MVP scoping and alternatives for the approval-gate model — collaborative shaping of scope rather than final decisions.
- Cross-team alignment sync. Scheduled, with the proposal's ~20 open questions as its agenda. As of the last documented iteration, the sync had not concluded.
Outcome
A well-developed proposal and working prototype that established a clearer direction for the reporting SDLC. As of the last documented iteration, the direction was informing engineering's stated next-step planning, and the reporting strategy lead was replying with scope guidance. The proposal itself was in draft, with approximately twenty requirements-level questions listed as the agenda for an upcoming cross-team alignment sync. Between then and my departure, further alignment activity likely occurred; I do not have documented evidence of that period, and this case study reflects only what the artifacts support.
Words this outcome deliberately does not use, and why:
- Shipped, adopted, implemented — no artifact evidence.
- Validated with users — user testing did not happen in the scope of this workstream. Stakeholder review is a separate thing.
- Any quantified metric — no fabricated numbers.
Words this outcome does use, and why:
- Proposal — the specification document itself supports this.
- Working prototype — the mainline prototype supports this.
- Direction informing engineering's next-step planning — the engineering lead's next-step email plus the strategy lead's reply support this.
- Pending cross-team alignment sync — the proposal's own status line supports this.
Reflection
The main takeaway for me was that fulfilling all of the functional requirements does not necessarily create a coherent product experience.
In this case, the technical operations existed, but they were represented as separate screens and steps. My role was to look beyond those individual requirements and understand the user's larger goal — managing a report through its lifecycle — and then reorganize the experience around that mental model.
A second takeaway was the value of prototyping while understanding the system. For a technically complex workflow, I wasn't simply designing after all the requirements were settled. Building and iterating the prototype helped me understand the workflow, expose gaps and questions, discuss constraints with engineering, and progressively simplify the experience.
What I'd do differently
With more time, I would want to take the proposed workflow beyond internal and engineering review and validate it with the actual people responsible for managing and publishing reports. In particular, I would test whether the report-centered lifecycle model was understandable without explanation, whether users clearly distinguished moving a report between environments from making it available to customers and end-users, and whether the safeguards around higher-risk actions provided enough confidence without introducing unnecessary friction.