Documentation
docs
Set it up, learn how it thinks, bring your team in, and find the answer when something looks wrong — in the order you will actually need them.
Replace this blockquote with two or three sentences describing what docs does, written for somebody who has never heard of it. Name the job it does rather than the category it sits in — "keeps stock counts in sync across warehouses" tells a reader more than "an operations platform".
Start where you are#
How this site is organised#
Each section makes a different promise, and mixing them is what makes documentation hard to read.
- Getting started is the shortest path from nothing to a working setup. It assumes no prior knowledge and explains nothing it does not have to.
- Concepts defines the words the interface uses, so the rest of the site stops reading like a translation.
- Features describes capabilities, so an evaluator can decide whether docs covers their case before signing up.
- Guides are task-shaped. Each has a goal in the title and ends with a result you can check.
- Integrations, Security, Troubleshooting and the FAQ answer the questions that arrive after the product is in use.
Two habits that keep this site true#
- Change the page in the same pull request that changes the product. A stale instruction costs more support time than a missing one.
- When a customer asks the same question twice, write the answer down once instead of answering it a third time.
Link to https://docsbook.io/docsbook-websites/docs-9 from the product's help menu so nobody has to go looking for these pages.