This guide walks through the fastest complete path from a new account to a live documentation site. It is written for first-time users who want to understand not...
This guide walks through the fastest complete path from a new account to a live documentation site. It is written for first-time users who want to understand not...
This guide walks through the fastest complete path from a new account to a live documentation site. It is written for first-time users who want to understand not only which buttons to click, but also what each setup decision affects later.
dxb CLI.Before you begin
Before starting, decide three things:
- whether this documentation should be public or limited to authenticated readers
- whether your team will primarily work in the block editor or through docs-as-code
- whether you want to start from a template or from a blank structure
These choices are all reversible, but setting them intentionally gives the project a cleaner starting point.
1. Sign in and understand the dashboard
Sign in to Doxbrix, then open the Dashboard. This is the control surface for your workspace and the starting point for every project.
The dashboard gives you two kinds of information:
- a workspace summary, including cards for Projects, Pages, Spaces, Articles, and AI Usage
- operational queues, such as drafts that need attention and publishing status across your active documentation
The top search field, Search projects, docs, or settings…, is the fastest way to navigate once your workspace grows.
2. Create a new project
Click New project to open Create a new project. The page is structured into numbered sections and a summary rail, which makes it suitable for a first-run setup rather than a lightweight modal.
Doxbrix templates provide more than sample pages. They establish a starting information architecture, suggest common sections for the documentation type, and speed up evaluation by letting you see a complete site shape immediately.
Common starting points include:
- Blank for teams that already know their structure
- Help Center for support-led content
- API Documentation for developer-facing references
- Product Documentation for end-user and admin guidance
- Internal Knowledge Base for private operational documentation
Use Search templates… to filter, or Browse all to inspect the full template catalog.
The Project details section controls how the site is identified and branded:
- Icon gives the project a visual marker in the workspace
- Project name is the internal and reader-facing title
- URL slug controls the path portion of the site URL
- Description can be used on landing surfaces and should clearly explain the purpose of the site
- Brand color and Font family establish the starting visual identity
Choose a name and slug you would be comfortable keeping long term. They often appear in shared links, search results, and project-switcher menus.
This section defines the working model of the site:
- Visibility: choose Public when the site is intended for customers,
partners, or external developers; choose Private when the content should remain limited to authenticated workspace members
- Editor mode: choose Block editor for structured, component-based
authoring, or WYSIWYG when your team prefers a document-style editing surface
- Primary language: sets the default locale of the project
- Multi-language docs: enables matching page sets across multiple locales
If you are unsure, use Public, Block editor, and one primary language. That combination matches the most common product documentation workflow.
If your plan includes Git sync, you can connect GitHub or GitLab during project creation. This is useful when you already know the project will be maintained as docs-as-code or when you want immediate repository-backed history.
If you are evaluating the product or starting in the app, it is reasonable to skip Git for the first pass and configure it later in Git connect.
Review the summary rail, then click Create project. Doxbrix provisions the project, generates the template content and navigation, and routes you into the editor. If Git import is involved, Doxbrix displays a sync progress overlay before the editor opens.
3. Get oriented in the editor workspace
When the project opens, you are looking at the main authoring workspace. The exact arrangement may vary by editor mode, but the core areas are consistent:
- The content tree lists your spaces, groups, and pages — create and reorder structure here.
- The canvas in the middle is where you write.
- The side panel on the right has tabs for the table of contents and document insights (your quality score and suggestions).
- The top bar holds the project switcher, Project settings, Comments, Preview, History, and the Publish / Submit for review button.
Treat these regions as separate responsibilities:
- the content tree controls information architecture
- the canvas controls page content
- the side panel surfaces quality and structure
- the top bar controls workflow state and output
4. Create or edit your first page
If you started from a template, begin by opening one of the seeded pages. This is the fastest way to understand the block model, heading structure, and expected tone.
Hover a space or group in the content tree, click +, and choose Add page. Doxbrix lets you start from page-level templates such as Blank, Guide, API reference, or FAQ.
Choose the page type based on reader intent. A guide is for a procedure. An FAQ is for short-answer support content. An API reference page is for a stable endpoint or operation.
In the Block editor, type / to open the block palette and insert structured components such as callouts, steps, cards, code groups, media, and API blocks. Markdown shortcuts also work for common patterns such as headings, lists, and emphasis.
For a first page, include:
- a clear title and introduction
- a short explanation of the outcome or purpose
- prerequisites, if applicable
- ordered steps if the page is procedural
- next steps or related links
Doxbrix saves continuously. The save indicator in the interface moves between Autosaving… and Autosaved, while the page itself remains a draft until it is published or submitted into review. This distinction matters: saved content is not necessarily live content.
5. Review quality before publishing
As you edit, Doxbrix analyzes the page and assigns a Quality score from 0 to 100. The score is broken into five dimensions:
- Readability
- Structure
- SEO
- Accessibility
- Completeness
Open document insights to see the reasons behind the score and the highest-impact fixes. This is where Doxbrix becomes especially useful for product documentation: it helps standardize quality across pages, not just accelerate drafting.
If you want guided rewriting, use Improve with AI to revise the page overall or target one dimension at a time. See Improve with AI.
6. Preview and publish
When a page is ready, publish it from the top bar:
Click Preview to inspect the rendered reader experience. This is the right time to check heading hierarchy, link text, card layouts, code blocks, and visual density from a reader perspective rather than an author perspective.
Click Publish — or Submit for review first, if your project requires approval. The page's status dot turns to Published and the reader-facing site updates. If you need to ship a larger batch, the split action also supports publishing a whole section.