Case study

Designing a safe documentation publishing workflow

How we transformed publishing from a single high-risk action into a controlled workflow.

Role
Product Designer
Context
Timeline
2024
Status
Shipped

The challenge

Publishing documentation was an all-or-nothing action. When multiple editors were working simultaneously, publishing one finished update could accidentally expose unrelated work in progress.

Editors had to coordinate manually or hide new pages as a workaround. But hiding only protected new pages — it didn’t prevent unfinished edits to existing public pages.

There was also no page-level review or approval state.

The "before" publishing flow.

The key insight

We needed a way to distinguish unpublished changes from published content without creating separate copies of every page.

I reframed the experience around a simple principle:

Every unpublished page change is a draft.

A page became a draft when it was added, updated, hidden, or deleted. If it returned to its previously published state, it was no longer a draft.

This allowed people to keep collaborating on the same pages, comments, and content without introducing separate “live” and “draft” versions.

A page becomes a draft when any change is made to the content.

From all-or-nothing to selective publishing

With a clear draft model, I redesigned publishing as a controlled selection rather than a single action.

Editors could:

  • See which pages had unpublished changes
  • Select only the changes ready to publish
  • Preview the selected changes
  • Confirm before publishing

The goal was to make selective publishing feel simple while keeping the underlying system predictable.

The updated publishing dialog.

Designing around structural dependencies

The biggest challenge was that page content and documentation hierarchy weren’t completely independent.

For example, renaming a group could change the paths of every child page. Ungrouping could move several pages at once, while deleting a group could affect its contents.

I mapped these edge cases with Engineering and separated content changes from hierarchy operations:

  • Content changes: Explicit selection and approval before publishing.
  • Hierarchy changes: Applied as atomic operations to prevent invalid navigation.
  • Conflicting operations: Hierarchy took precedence.

This gave editors meaningful control over what they published without exposing them to the technical dependencies underneath.

A diagram explaining the hierarchy/content relationship.

Extending the model into governance

Selective publishing solved the immediate problem of keeping unfinished work private. Enterprise customers also needed a way to review changes before they went live.

I extended the draft model with page-level review states. Editors could request review, preview pages in different states, and see the current status while editing and publishing.

When approval workflows were enabled, only approved pages could be published.

Review and approval states.
The publishing dialog with approval workflow enabled.

The result

Publishing changed from a single high-risk action into a controlled workflow that supported collaboration, selective release, and approval.

The same underlying draft model became the foundation for both everyday publishing and more structured governance workflows for Enterprise teams.