All work

CS/01 · Case study

Nothing to publish

How AI-built reports get saved, shared and found again: a three-step publish wizard became one share dialog, and most of the design turned out to be vocabulary.

Details generalized under NDA. Every visual is recreated with fictional data.

Role
Product designer and design engineer
Scope
Report lifecycle: save, share, find again, update
Context
AI reporting assistant for a government data platform, in beta
Year
2026

The problem

Staff at public agencies (cities, counties, state agencies) describe the report they need in plain language, like “run the monthly overtime report for June.” The assistant finds the right datasets, writes and runs the query, and builds the report on a canvas next to the chat.

Before the assistant, making a report meant knowing the data catalog, the query language and a manual drag-and-drop builder. Most staff who need reports know none of that. Once the assistant could build a report, the next question was what happens to it: how it gets saved, shared, found again and kept up to date.

My role

I owned the UX of the report lifecycle from concept to prototype to beta handoff, designing in code against real data and the live agent. The services and storage belonged to engineering. I treated them as context and left those decisions to the engineers on purpose.

Decision 1

Drop “publish” for always-saved reports

Considered
  • A three-step publish wizard (Details → Access → Review), which I built first
  • Live-document sharing, where recipients see edits as they happen
  • Named versions
  • Always-saved reports, where sharing hands over “the last shared version”
Chose
Every report saves automatically and stays in your library. It’s private until you share it. Sharing is one dialog, modeled on Drive, and later edits show up as “Unshared changes” with one action to update the shared version.
Why
Publishing added ceremony, and a lifecycle people had to understand, for no real benefit. One shared copy that gets replaced keeps what recipients see stable, and leaves room for versioning later.
Fig. 1Before and after. Three steps and a “published” state became one dialog that only asks who can see the report.

A related call: every report is listed in the library. No “only list it if you save it” threshold. A threshold is really a second lifecycle state, which means more engineering, and unlisted reports are effectively lost. Clutter is handled with quality instead: AI auto-titles, newest-first ordering and one-click delete.

Same wires, new words

The main pushback was that we should use the platform’s existing publish process. So I mapped every step of the new UX onto the existing publish-and-permissions machinery, in a two-lane diagram: user actions on top, the unchanged platform operations underneath.

Fig. 2The two-lane diagram, simplified. Nothing underneath changes; only the steps and words people see do.

Decision 2

Three statuses: Only you, Shared, Unshared changes

Considered
  • Private
  • Restricted
  • Draft
  • “Shared · newer edits”
  • “Snapshot”
Chose
Only you, Shared and Unshared changes, plus “the last shared version” for what recipients see. The UI never says publish, draft or snapshot, and the attention color is reserved for the one state that needs it.
Why
Each rejected word taught the wrong model. I settled the wording in a workshop, borrowing the “unpublished changes” pattern people already know from other tools.
Fig. 3The vocabulary board: the words we dropped, why, and the three statuses that replaced them.

For reference I studied how Google Drive, Google Sites, Looker Studio and Claude’s artifacts handle saving, sharing and unpublished changes, and borrowed their vocabulary wherever people would already know it.

Constraints

  • The backend wasn’t ready for the ideal flow. Every publish created a brand-new asset, so there was no path to update a shared report. I designed the UX against a small fake store and wrote the adoption gaps down for the engineers, instead of proposing storage myself.
  • There is no “public”. These sites require sign-in, so sharing became named people, with an optional whole-organization toggle.
  • The design system had a gap. There was no access-control row (person, role, revoke). I hand-built one for the prototype and sketched a proposed component, but left building it as separate work.

Outcome

  • The design team adopted save-and-share over publish. Developer feedback shaped the final model: private by default, and one shared copy.
  • Engineering accepted the storage direction: every report is a private asset from the start.

What I learned

  1. Words carry the model.

    Most of the sharing design was vocabulary. Getting “Unshared changes” and “the last shared version” right did more than any layout change.

  2. Map new UX onto existing machinery early.

    The two-lane diagram settled the pushback faster than any argument.

  3. State directions; don’t hedge.

    A side-by-side comparison table read as if we were still proposing the option we’d dropped.