> ## Documentation Index
> Fetch the complete documentation index at: https://learn.mintlify.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Structure individual pages for scanning

> Turn a page goal into headings, prerequisites, examples, and verification that help readers move quickly.

export const Quiz = ({question, answers, correctFeedback, incorrectFeedback}) => {
  const [selected, setSelected] = React.useState(null);
  const [checked, setChecked] = React.useState(false);
  const quizId = React.useId();
  const isCorrect = checked && answers[selected]?.correct;
  const reset = () => {
    setSelected(null);
    setChecked(false);
  };
  return <div className={"quiz-container" + (checked ? " quiz-checked" : "")}>
      <Badge color="green">Quiz</Badge>
      <p className="quiz-question" id={quizId + "-question"}>{question}</p>
      <div className="quiz-options" role="radiogroup" aria-labelledby={quizId + "-question"} aria-disabled={checked}>
        {answers.map((answer, i) => <label key={i} className={["quiz-option", !checked && selected === i ? "quiz-option-selected" : "", checked && answer.correct ? "quiz-option-correct" : "", checked && selected === i && !answer.correct ? "quiz-option-incorrect" : ""].filter(Boolean).join(" ")}>
            <input type="radio" name={"quiz-" + quizId} checked={selected === i} onChange={() => !checked && setSelected(i)} disabled={checked} />
            <span className="quiz-radio" />
            <span className="quiz-option-label">{answer.text}</span>
          </label>)}
      </div>
      {checked && <div className={"quiz-feedback " + (isCorrect ? "quiz-feedback-correct" : "quiz-feedback-incorrect")} role="status" aria-live="polite" aria-atomic="true">
          <span className="quiz-feedback-icon">{isCorrect ? "✓" : "✗"}</span>
          {isCorrect ? correctFeedback : incorrectFeedback}
        </div>}
      <div className="quiz-actions">
        {!checked ? <button className="quiz-btn quiz-btn-check" type="button" onClick={() => selected !== null && setChecked(true)} disabled={selected === null}>
            Check answer
          </button> : <button className="quiz-btn quiz-btn-reset" type="button" onClick={reset}>
            Try again
          </button>}
      </div>
    </div>;
};

A good navigation structure gets readers to the right page. The page still has to help them finish the job.

Readers rarely start at the top and study every sentence. They scan headings, code blocks, lists, and visual cues until they find the section that matches their immediate question. Build pages for that behavior.

## Give each page one clear goal

Before writing, finish this sentence: “After reading this page, the reader can \_\_\_.”

If the answer contains several unrelated verbs, split the page. “Install the SDK, understand our architecture, and troubleshoot webhooks” is at least three goals.

Match the page structure to its content type:

* A tutorial guides a learner through a complete experience.
* A how-to guide starts with a known goal and provides the shortest reliable path.
* Reference content makes facts easy to locate and compare.
* An explanation builds understanding through context and relationships.

## Put prerequisites before instructions

Tell readers what they need before they start working on a task.

* Required accounts, roles, or permissions
* Software and supported versions
* Values they need to collect
* Setup they should have completed elsewhere

Link directly to prerequisite instructions. Don't make readers discover halfway through a procedure that they lack access or need another tool.

## Write headings that tell the story

A reader should understand the page's shape by scanning its headings alone. Use headings that name a task, decision, or question:

* “Generate an API key” instead of “API keys”
* “Choose a deployment region” instead of “Options”
* “Fix a 401 response” instead of “Troubleshooting”

Keep the hierarchy meaningful. Use `##` for the main sections and `###` for subsections within them. Don't skip levels only to change the visual size.

## Introduce examples before showing them

Before a code block, tell readers what it does, where it belongs, and what they may need to replace. Afterward, state the expected result when it isn't obvious.

```bash theme={null}
curl https://api.example.com/me \
  -H "Authorization: Bearer YOUR_API_KEY"
```

For this example, the surrounding page should explain where to find the API key and what a successful response looks like. The code shouldn't carry the full teaching burden.

## Put help near the failure point

Don't collect every warning and troubleshooting note at the bottom of a long guide. If step three commonly fails because of permissions, mention the required permission before step three and link to the relevant fix there.

Keep broad troubleshooting pages for symptoms that can occur in many workflows. Keep task-specific recovery close to the task.

## End with proof and direction

Tell readers how to confirm that they succeeded. A useful verification is observable.

* A command returns a specific value
* A new status appears in the dashboard
* An API request returns `200 OK`
* The published page appears at a known URL

Then tell them what comes next—if there is a meaningful next step. Don't add navigation only to fill the bottom of the page.

## Review the page as a stranger

Before publishing, check:

* Can someone understand the goal from the title and description?
* Are all prerequisites visible before the first action?
* Do the headings make sense without the paragraphs beneath them?
* Can a reader tell what to copy, change, and expect from each example?
* Is help placed near the step that can fail?
* Does the page say how to verify success?

<Quiz
  question="A reader needs administrator access for step four of a guide. Where should the guide first mention that requirement?"
  answers={[
{ text: "In a troubleshooting section after all the steps", correct: false },
{ text: "In the prerequisites before the procedure begins", correct: true },
{ text: "Inside a collapsed accordion in step four", correct: false },
{ text: "Only in the page description", correct: false },
]}
  correctFeedback="Right. A required permission is a prerequisite. Tell readers before they invest time in the procedure, then repeat it near the action if that context helps."
  incorrectFeedback="Required access belongs in the prerequisites before the procedure. Discovering it at step four wastes the reader's time and may leave the setup half-finished."
/>

Next up: [Design navigation for your users](/courses/structure-docs/navigation-design) — Connect well-structured pages into paths that match user goals.