Adaptive content at scale

The challenge

GitBook docs had always been one-size-fits-all which was limiting for enterprise customers who needed to show different content to different users.

These customers wanted to hide pages, swap examples, or localise content without duplicating entire sites. The solution had to balance enterprise power with everyday usability.

For example, one customer preparing a German-only launch needed to show new product docs exclusively to that market. Without adaptive content, their only option was to spin up an entirely separate site, doubling the work and duplicating effort.

What I did

Switching perspectives

I redesigned the editor header to add a segment switcher, letting authors preview docs exactly as each audience would see them.

Selecting a segment (e.g. beta users) instantly updated the page to show the personalised view. This gave authors confidence in their setup, making adaptive docs predictable before publishing and cutting down nervous “publish and pray” workflows.

Conditions at every level

Conditions could apply to pages, groups, or individual blocks — giving authors control over how far to personalise, from light tweaks to full forks.

This avoided messy duplication while keeping the end-user’s view clean and relevant. For teams managing multiple regions or customer tiers, it meant one doc base could flex to cover all use cases without fracturing into separate sites.

Building the condition builder

The builder was key, letting authors define who sees what. I designed it to feel approachable while handling complexity under the hood.

Rather than build a second drag-and-drop query system, we went with one consistent, code-based flow — softened with inline popovers, error handling that suggested fixes, and a test mode so that users could validate rules with real data.

Testing with sample data

I added test segments so authors could simulate conditions with JSON snippets or pick from auto-detected segments.

This made previews reliable — no guesswork and no need to publish just to check. Authors could even test tricky edge cases, saving support teams from “why can’t I see this?” tickets later.

Outcome

The feature launched in July 2025 on GitBook’s enterprise tier. For authors, it turned a once-impossible request into a core workflow. For end-users, it meant docs that finally felt written for them.

The design struck a balance: flexible enough for engineers, approachable enough for less technical teams.