Patterns
Page patterns and composition rules
Patterns explain how approved tokens and primitives combine into complete pages. They are less about visual novelty and more about preserving the reading rhythm of the system.
Docs page pattern
| Region | Role | Notes |
|---|---|---|
| Top rail | Primary navigation across docs areas | Stays compact and muted |
| Local anchor rail | In-page orientation for long documents | Sticky on desktop, stacked on mobile |
| Article column | Primary reading area | Keep width narrow and predictable |
Article-like content page
When a page reads more like an essay or deep technical note, keep the title compact, the metadata muted, and the body close in scale to the heading. The page should feel editorial, not promotional.
Overview and index page
Index-like pages should summarize the system without pretending to be a product landing page. Favor short sections, quiet tables, and brief guidance that points engineers to the deeper docs pages.
- State what the system is for.
- Explain how to consume it in code.
- Link to the deeper pages that hold the real detail.
- Keep promotion copy out of the overview.
Promotion pattern
Patterns become real only after they survive comparison in the lab and then get documented here. The promotion path should stay the same even as the visual language evolves.
| Step | Owner | Result |
|---|---|---|
| Explore in lab | Design or engineering | Candidate pattern |
| Extract shared parts | Engineering | Reusable primitive or token |
| Document usage | Engineering | Stable docs entry |
| Adopt in product | Product code | Production page or feature |