Get new users to a win before they lose interest
Most people decide whether a product is worth their time in the first session. A quick start guide exists for exactly that window: it strips away everything optional and walks the user, in five steps or fewer, from nothing to a visible result. This builder forces that discipline — a single promise, a short numbered path, one highlighted key action, and a clear “you did it” moment.
How it works
You provide four pieces and the tool assembles them into a tight getting-started document:
Promise — one line: what you'll achieve + how long it takes
Steps (<=5) — numbered actions; one is flagged as the KEY action
Result — what success looks like so the user knows they're done
Next steps — 2-3 links to go deeper after the first winThe promise becomes the opening line so the reader immediately knows the payoff. Steps render as a numbered list, with the key action emphasised so it stands out from setup. The result section gives the user a checkpoint, and next-step links route already-activated users toward the next feature instead of leaving them at a dead end.
What separates a quick start from other doc types
Documentation exists on a spectrum from “get me started right now” to “explain every option”. A quick start occupies the leftmost position on that spectrum:
| Doc type | Goal | Length | When to use |
|---|---|---|---|
| Quick start | First working result | < 5 steps | New user, first session |
| Installation guide | Full environment setup | 10–20 steps | Pre-requisites and dependencies |
| Tutorial | Learn by building | Many steps | Deeper feature learning |
| Reference | Lookup everything | Comprehensive | Already activated users |
A quick start assumes the user has installed the tool and simply needs to reach the “aha” moment. If installation itself is complex, a separate installation guide should precede the quick start, not be embedded in it.
Writing effective steps
Each step in a good quick start has three characteristics:
- A single action — one command, one click, one configuration decision. If a step contains “then” or “and”, split it.
- The exact input — copy-pasteable commands in code blocks, specific field values, not vague descriptions like “enter your details”.
- An expected output — what the user should see or receive after completing the step, so they can verify they are on track.
For example, a mediocre step might read: “Configure your account and generate an API key.” A strong step reads: “Go to Settings → API Keys, click New Key, name it quickstart, and copy the key that appears — you’ll need it in step 4.”
The key action: what it is and why to highlight it
The key action is the single step that produces the payoff — the visible, tangible result the user came for. In an email API it is the send call. In a database tool it is the first query result. In a deployment platform it is the live URL.
Highlighting the key action serves two purposes. For first-time users, it signals “this is the moment that matters” and keeps them engaged through the surrounding setup steps. For returning users who forgot one piece, it tells them exactly where to focus.
Tips and example
Write the promise as an outcome, not a feature: “Send your first transactional email in about 3 minutes” beats “Learn about our email API”. Keep each step to a single command or click, and put the actual command in backticks so it is copy-pasteable. Pick the one step that produces the visible result as your key action — for an email tool that is the send call, not the API-key setup. End on a concrete result (“Check your inbox — the test email arrives within seconds”) so the user gets a clear success signal that brings them back tomorrow.