Introduction

This handbook is how our writers plan, structure and write technical documentation. We publish it because the same habits work for any product team, and because documentation that users can't follow costs you support tickets, slow onboarding and lost trust.

The problem we solve#

Most technical docs don't fail because the writer misunderstands the product. They fail because they were written for the writer, not the reader. The result is predictable:

• Users get lost. Pages follow how the product was built, not how people use it.
• Support tickets pile up. The docs don't answer the question, so your team does.
• Onboarding takes longer than it should. New users stall on unclear steps.

Our approach#

1. Dig into the product. Calls, existing docs and, when needed, the codebase.
2. Structure the content. Organise it so it flows logically, step by step.
3. Write in plain language. Cut the jargon and write for end users, not just engineers.

Principles#

Write for the task, not the feature#

Readers arrive with a job to do. A page titled "Webhook settings" describes a screen. A page titled "Verify a webhook signature" describes a task. Prefer the second.

Show, then explain#

Lead with the smallest working example or the first step, then explain the moving parts. A reader who can follow along and see a result trusts the page.

One page, one purpose#

If a page is both a tutorial and a reference, it fails at both. The information architecture guide covers the four page types we use.

How to use this handbook#