Skip to content

Latest commit

 

History

History
46 lines (29 loc) · 3.72 KB

File metadata and controls

46 lines (29 loc) · 3.72 KB

Product

Register

brand

Users

Axiom Docs serves developers, platform engineers, observability practitioners, and technical operators who need to understand Axiom, write APL or MPL queries, integrate APIs, and troubleshoot production systems. Readers range from first-time evaluators following a guided setup to experienced users scanning dense reference material under time pressure.

Product Purpose

Axiom Docs is the authoritative, self-hosted documentation experience for Axiom. It combines product guides, query-language reference, REST API reference, search, and a grounded documentation assistant in one coherent, fast, linkable application.

The product should preserve the depth of the existing documentation while making long technical pages easy to scan and comfortable to read. It must feel native to Axiom, support the distinct needs of documentation, query reference, and API reference, and provide a durable foundation for Axiom-owned components, analytics, and future documentation features.

Brand Personality

Precise, technical, confident.

The voice is direct and useful without becoming sterile. The interface should feel deliberately engineered: compact where density helps, quiet where readers need focus, and expressive through Axiom's own typography, color, and interaction details rather than decorative novelty.

Anti-references

  • A stock Fumadocs theme whose framework defaults are more visible than Axiom's identity.
  • Mintlify's visual language or information architecture. Mintlify is migration context, not a design target.
  • Generic documentation templates with oversized rounded cards, pill-heavy controls, decorative shadows, or blue-as-default interaction color.
  • Interfaces that flatten the contrast hierarchy and make body copy, headings, labels, and code feel equally prominent.
  • Sparse marketing-page treatments that sacrifice technical density, navigation depth, or fast scanning.
  • Ornamental effects that compete with reading, including gratuitous gradients, glassmorphism, and animation without a functional purpose.

Design Principles

  1. Axiom before framework. Use Fumadocs as infrastructure while making the visible experience unmistakably Axiom.
  2. Optimize for technical reading. Keep articles centered, line lengths comfortable, hierarchy clear, and dense references easy to scan.
  3. One coherent system, distinct modes. Documentation, query reference, and API reference share a visual language while retaining the controls and density their content requires.
  4. Restraint creates confidence. Prefer borders, tonal shifts, compact spacing, and purposeful orange accents over shadows, oversized radii, and decorative effects.
  5. Interaction should clarify. Search, navigation, anchors, code controls, forms, feedback, and the assistant must provide immediate, predictable, keyboard-accessible behavior.
  6. Build reusable foundations. Improve shared components and compatibility mappings instead of accumulating page-specific exceptions.
  7. Performance is part of the design. Keep navigation responsive, statically buildable content fast to load, and optional features such as the assistant out of the critical path.

Accessibility & Inclusion

Target WCAG 2.2 AA across the documentation experience.

Use semantic heading order and navigation landmarks; preserve accessible names, roles, selected/current states, and status announcements; support keyboard and touch interaction with visible focus; meet text and UI contrast requirements in light and dark themes; respect reduced-motion preferences; and keep responsive navigation and search usable at tablet and phone sizes. Technical content must remain understandable without relying on color, animation, pointer hover, or visual position alone.