Title: Technical Writing — LearnCoachAssist

Q: What is technical writing?
A: Technical writing is the craft of explaining complex information clearly so readers can understand and act on it.

Q: Why is technical writing valuable?
A: It reduces confusion, improves adoption, and helps teams scale knowledge beyond live conversations.

Q: Who is the audience in technical writing?
A: The audience is the specific reader or user the document is trying to help, persuade, or guide.

Q: Why should technical documents start from user need?
A: Clear documents answer the reader’s real question instead of showcasing everything the author knows.

Q: What makes technical writing clear?
A: Clear technical writing is specific, structured, concise, and easy to scan.

Q: What is a good documentation structure?
A: A strong structure moves from context to steps to examples to troubleshooting in a logical order.

Q: Why are headings important in documentation?
A: Headings help readers find the right section quickly and understand the content hierarchy.

Q: What is procedural writing?
A: Procedural writing gives readers step-by-step instructions to complete a task successfully.

Q: Why should steps be numbered when order matters?
A: Numbering helps readers follow sequence correctly and reduces skipped actions.

Q: What is conceptual writing?
A: Conceptual writing explains how something works or why it matters before asking the reader to act.

Q: Why are examples useful in technical writing?
A: Examples turn abstractions into concrete cases that readers can copy, compare, or adapt.

Q: What is the role of screenshots or diagrams?
A: Visuals can clarify structure or sequence when text alone would be slower to understand.

Q: Why should jargon be controlled carefully?
A: Expert terms can be useful, but unnecessary jargon increases cognitive load and excludes readers.

Q: What is plain language in technical writing?
A: Plain language uses familiar words, direct sentences, and clear structure without sacrificing accuracy.

Q: Why should technical writers define assumptions?
A: Readers need to know prerequisites, environment, or context before instructions will work for them.

Q: What is a troubleshooting section?
A: A troubleshooting section anticipates common failures and explains how to diagnose and resolve them.

Q: Why should errors be documented explicitly?
A: Readers often arrive at docs because something went wrong, so clear error guidance saves time.

Q: What is a reference document?
A: A reference document provides precise facts such as options, parameters, fields, or behaviors for lookup.

Q: What is a tutorial?
A: A tutorial guides the reader through learning by doing, usually in a beginner-friendly sequence.

Q: Why should commands and examples be tested?
A: Broken examples erode trust quickly and make readers doubt the rest of the document.

Q: What is information scent in documentation?
A: Information scent is the set of cues that help readers predict where useful content is located.

Q: Why is consistent terminology important?
A: When terms change unpredictably, readers waste energy deciding whether two labels mean the same thing.

Q: What is an effective summary sentence?
A: An effective summary sentence tells the reader what the section will help them accomplish.

Q: Why should technical writing be revised aggressively?
A: First drafts often mirror the author’s thinking process rather than the reader’s path to understanding.

Q: What is doc maintenance?
A: Doc maintenance is the ongoing work of updating content as products, APIs, and workflows change.

Q: Why should stale docs be treated as a product problem?
A: Outdated documentation creates support load and leads users into avoidable mistakes.

Q: What is a useful technical-writing question?
A: What does this reader need to know, do, or decide immediately after reading this section?

Q: What is a durable technical-writing habit?
A: Write for the reader’s task, test your examples, and cut anything that does not improve understanding.

Q: Why should short paragraphs be favored in docs?
A: Short paragraphs are easier to scan, especially when readers are under time pressure.

Q: What is an action-oriented heading?
A: It is a heading phrased around the task the reader wants to complete rather than a vague topic name.

Q: What is a strong technical-writing principle?
A: Make the next right action obvious and the surrounding complexity easier to navigate.

Q: How can technical writing improve team alignment?
A: Shared docs make decisions, process, and system behavior easier to reference consistently across the team.

Q: Why should technical writers separate must-know from nice-to-know details?
A: Readers usually arrive with a task in mind and need the critical path before the extra context.

Q: What is progressive disclosure in documentation?
A: Progressive disclosure reveals the simplest useful guidance first and exposes deeper detail only when needed.

Q: Why is scannability important in docs?
A: Most readers scan before they read deeply, especially when they are troubleshooting under time pressure.

Q: What is a prerequisite section?
A: A prerequisite section tells readers what they must already have, know, or configure before the instructions will work.

Q: Why should examples mirror real usage?
A: Readers trust and adopt examples more readily when they resemble actual workflows instead of toy cases.

Q: What is tone in technical writing?
A: Tone is the style and level of formality that helps documentation feel clear, credible, and respectful.

Q: Why should docs avoid ambiguous pronouns?
A: Ambiguous references make technical steps harder to follow because readers are unsure what each instruction refers to.

Q: What is task-based documentation?
A: Task-based documentation is organized around what users want to accomplish rather than around internal system components.

Q: Why should changelogs and docs connect?
A: Users need to know not just that something changed, but how the change affects the way they work.

Q: What is a maintenance-friendly writing habit?
A: Prefer clear structure and reusable patterns so updates can be made quickly when the product changes.

Q: What is a strong documentation principle?
A: Write the shortest path to correct action, then support it with just enough context to build confidence.

Q: Why should docs be tested by non-authors when possible?
A: Fresh readers catch assumptions and ambiguity that the writer no longer notices.

Q: What is the difference between accuracy and precision in technical claims?
A: Accuracy means the claim is true; precision means it is stated with exactly the right granularity. Both matter: a precise but inaccurate number (e.g. "exactly 1,024.7 ms") is worse than a rounded accurate one.

Q: Which sentence is more scannable, and why: "The system retries the request when the network is unavailable" vs. "When the network is unavailable, the system retries the request"?
A: The second is more scannable because leading with the condition ("When the network is unavailable") matches how readers skim to confirm a precondition before reading the consequence.

Q: Why should imperative mood be used in procedural steps?
A: Imperative mood ("Click Save", "Run the script") puts the action on the reader without an ambiguous subject, making each step short, parallel, and easy to translate.

Q: What is a topic sentence in technical writing?
A: A topic sentence is the first sentence of a paragraph that previews the paragraph's single main idea, so a scanner can decide whether to read on.

Q: Why is parallelism important in lists?
A: Parallel structure ("Install the SDK. Configure the SDK. Deploy the SDK.") lets readers compare items at a glance and signals that each item is a peer, not a special case.

Q: What is the "one idea per paragraph" rule?
A: It means each paragraph advances a single claim or step, so a reader who skips a paragraph still does not miss a separate point buried inside it.

Q: When should a colon be used in procedural text?
A: Use a colon to introduce a list, a code example, or a definition that directly elaborates the preceding clause ("Use these flags: --verbose, --dry-run").

Q: Why is the passive voice often discouraged in instructions?
A: Passive constructions ("The file should be saved by the user") hide the actor, add words, and break the imperative pattern readers expect in steps.

Q: What is an "inverted pyramid" structure in docs?
A: It is a layout that puts the most important conclusion or instruction first, then expands with context, then ends with background or edge cases.

Q: What is the "callout" pattern in technical documents?
A: A callout is a visually distinct block (note, tip, warning, danger) used to highlight information that would be dangerous to miss or important not to overlook.

Q: What goes into a "Warning" callout versus a "Note" callout?
A: A Warning flags actions that can cause data loss, security holes, or irreversible damage; a Note flags useful context, tips, or clarifications that are helpful but not dangerous.

Q: What is a "code block" used for in documentation?
A: A code block presents runnable or copy-pasteable commands, configuration, or output with preserved whitespace, syntax, and no prose wrapping.

Q: What is the role of a "Prerequisites" section?
A: It lists exact software versions, accounts, permissions, or knowledge the reader must have before the rest of the doc will work, preventing wasted effort.

Q: What is a "How-to" guide versus a "Tutorial"?
A: A How-to is a recipe for a specific goal aimed at an informed reader; a Tutorial is a guided learning experience aimed at someone still building the mental model.

Q: What is a "Reference" page in API documentation?
A: A reference page exhaustively lists every endpoint, parameter, return type, and error code in a lookup-oriented format, with little narrative.

Q: What is the typical order of doc types in a product docs site?
A: Start with a Tutorial or Quickstart, then Concepts, then How-to guides, then Reference. This matches the journey of a learning reader.

Q: Why should the title of a doc page start with a noun or verb, not an article?
A: Titles like "Configure SSO" or "Authentication overview" sort and read more cleanly than "The SSO Configuration" or "An Overview of Authentication."

Q: What is a "table of contents" used for in long docs?
A: It lets a reader jump directly to the section that matches their task instead of scrolling, especially on mobile where scroll is expensive.

Q: What is "link rot" and how do docs fight it?
A: Link rot is when a referenced URL changes or dies. Docs fight it by preferring relative links, version-pinning, and showing a code snippet alongside any link.

Q: Why should doc examples be copy-pasteable?
A: A reader who copies a snippet and runs it should see the documented result. Trivial edits (placeholder names, missing flags) break trust quickly.

Q: What is "placeholder code" and why is it dangerous?
A: Placeholder code is a sample using names like "my-host" or "TODO" that the reader must replace. It is dangerous when the placeholders are not flagged and the reader pastes literally.

Q: What is a "minimum viable example"?
A: It is the shortest example that still demonstrates the documented behavior, with no unrelated features, no decorative config, and no copy-paste noise.

Q: What is a "complete, runnable example"?
A: It is a sample that runs as-is in a fresh environment (with documented prerequisites), demonstrating one concept end-to-end without ellipses or "...".

Q: Why should outputs be shown for example commands?
A: Showing expected output lets the reader verify their own run, diagnose typos, and trust that the documented behavior matches reality.

Q: What is the "show, don't tell" rule for technical concepts?
A: Demonstrating a concept with a real input/output is more convincing than describing it abstractly, especially for APIs and CLIs.

Q: What is "cognitive load" in the context of docs?
A: Cognitive load is the mental effort a reader must spend to understand a passage. Docs minimize it with structure, examples, and consistent terminology.

Q: What is the difference between "active" and "passive" voice in instructions?
A: Active voice puts the reader as the subject ("You can enable debug mode"); passive voice hides the actor ("Debug mode can be enabled"). Active is shorter and clearer in steps.

Q: What is a "runbook" in technical writing?
A: A runbook is an operational document giving on-call responders exact steps to diagnose, mitigate, and resolve a specific production issue.

Q: What is a "postmortem" document?
A: A postmortem is a written record of an incident: timeline, root cause, contributing factors, customer impact, and concrete action items to prevent recurrence.

Q: Why are postmortems written blamelessly?
A: Blameless framing focuses on systems, signals, and decisions under uncertainty, which encourages honest reporting and durable fixes over scapegoating.

Q: What is a "design doc"?
A: A design doc explains a proposed technical change: the problem, options considered, the chosen approach, trade-offs, risks, and rollout plan.

Q: What sections usually appear in a design doc?
A: Problem statement, goals and non-goals, proposed solution, alternatives considered, trade-offs, risks, rollout, and open questions.

Q: What is the audience for an RFC versus a design doc?
A: An RFC is written for a broad engineering audience to debate direction; a design doc is more concrete and aimed at reviewers who will approve implementation.

Q: What is a "decision record" (ADR)?
A: An Architecture Decision Record captures one significant decision: the context, the choice made, the consequences, and the alternatives rejected, signed by date and author.

Q: Why is it valuable to record rejected alternatives in an ADR?
A: Rejected alternatives prevent the same debate from restarting every time a new joiner questions the choice, and they preserve the reasoning when context is lost.

Q: What is a "README" supposed to do?
A: A README answers five questions fast: what this is, who it is for, how to install, how to run, and where to learn more. Anything else belongs in linked docs.

Q: What is a "CHANGELOG" entry?
A: A CHANGELOG entry is a per-version note that lists user-visible changes (Added, Changed, Fixed, Removed, Security) so users can see what to expect on upgrade.

Q: What is "SemVer" and how does it interact with docs?
A: SemVer uses MAJOR.MINOR.PATCH: breaking, feature, and fix. Doc sites typically pin references to a MAJOR version, while guides target the latest minor.

Q: What is a "code comment" and how does it differ from docs?
A: Code comments explain non-obvious behavior to future readers of the source. Docs explain the same system to users who never read the source. Both are needed.

Q: What is a "docstring" in Python and similar languages?
A: A docstring is a literal string placed at the top of a function, class, or module that documents its purpose, arguments, return value, and exceptions.

Q: What is "self-documenting code" and is it enough?
A: Self-documenting code uses clear names and small functions to reduce the need for prose. It is never enough on its own; intent, context, and trade-offs still need writing.

Q: What is the "WHY" comment pattern?
A: A "WHY" comment explains the reasoning behind a non-obvious line ("// Use 2 retries, not 3: 3 fails the SLO under packet loss"). It is the most valuable kind of code comment.

Q: What is a "type signature" in documentation?
A: A type signature declares the parameter and return types of a function. It documents shape, while prose documents meaning; both are usually needed.

Q: What is "API documentation" specifically?
A: API documentation is the human- and machine-readable description of an API: endpoints, request and response shapes, error codes, auth, rate limits, and examples.

Q: What is "OpenAPI" (formerly Swagger)?
A: OpenAPI is a machine-readable specification (YAML or JSON) that describes REST APIs and can be rendered into interactive reference docs.

Q: Why is the order of fields in an API reference important?
A: Ordering the most important and most-frequently-used fields first helps readers find the answer faster, even if the underlying schema is alphabetical.

Q: What is the "404 page" pattern in technical sites?
A: A 404 page acknowledges the missing content, suggests where the reader might go next, and offers a search box instead of a dead end.

Q: What is a "deprecation notice" and what should it contain?
A: A deprecation notice tells users a feature will be removed, states the removal version, explains the migration path, and links to the replacement.

Q: Why must deprecation notices include a migration path?
A: Telling users something is going away without telling them how to move creates churn, support tickets, and the perception of forced upgrades.

Q: What is a "feature flag" and how does it relate to docs?
A: A feature flag is a runtime switch that enables a feature for some users. Docs should describe the flag, its default, and which audiences currently see the feature.

Q: What is a "known issue" section?
A: A known issue section lists active bugs or limitations the user should be aware of, with workarounds, the affected versions, and a link to tracking.

Q: What is "versioning" in documentation?
A: Versioning is the practice of maintaining a separate copy of the docs for each major release so users on older versions still see accurate guidance.

Q: What is the role of a "search" bar in technical docs?
A: A search bar lets readers who arrive with a specific term (an error message, a parameter name) bypass navigation and reach the answer in one or two clicks.

Q: What is a "landing page" in a docs site?
A: A landing page is the entry point for a product area: it explains what the area is for, lists the most common tasks, and links to tutorials and reference.

Q: Why is the "two-level" navigation pattern common in docs sites?
A: A two-level navigation (sidebar of sections, in-page TOC of subsections) supports both the reader scanning a category and the reader drilled into a specific page.

Q: What is a "breadcrumb" in docs navigation?
A: A breadcrumb shows the path from the docs home to the current page (Docs > API > Auth > Tokens), helping readers back up without losing context.

Q: Why is it bad to use "click here" as link text?
A: "Click here" discards the information scent of the link. Better link text ("View the auth tokens reference") tells scanners where the link goes before they click.

Q: What is "alt text" and why is it mandatory for documentation images?
A: Alt text describes the image content for screen readers and for readers whose browser cannot load images. It must convey the same information as the image itself.

Q: What is the "one screenshot" anti-pattern?
A: It is filling a doc with screenshots for things code blocks or text could say better. Screenshots are expensive to maintain and break on UI changes.

Q: When are screenshots the right choice?
A: Use screenshots when the visual is the answer (a UI to find, a diagram, a layout) and a reader would otherwise have to re-render the picture mentally from prose.

Q: What is a "diagram" in technical docs?
A: A diagram is a visual model of relationships or flow (sequence, architecture, ER). It is best when relationships are the point, not the individual facts.

Q: What is a "sequence diagram" used for?
A: A sequence diagram shows the ordered messages between components over time. It is the right tool for documenting API calls, RPC flows, and async choreography.

Q: What is a "flowchart" used for?
A: A flowchart shows decision branches in a process. It is useful for runbooks and troubleshooting where the next step depends on the answer to a question.

Q: What is "ASCII art" and when is it acceptable in docs?
A: ASCII art is text-drawn diagrams. It is acceptable in code comments, READMEs, and terminal contexts where rendered images are not an option, and when simplicity is the goal.

Q: What is a "table" in technical documentation?
A: A table aligns parallel facts across rows (e.g. parameter, type, default, description) so readers can scan a single column instead of reading prose.

Q: When should prose replace a table?
A: Use prose when the relationship between facts is sequential or causal, when there are only one or two rows, or when the table would force a single cell to be a paragraph.

Q: What is a "definition list" in markup?
A: A definition list pairs a term with its definition, useful for glossaries, configuration keys, and field references, with less visual weight than a table.

Q: What is "consistency" in technical writing?
A: Consistency means reusing the same word for the same concept, the same heading pattern across pages, and the same formatting for the same kind of content.

Q: Why is a "style guide" useful for a docs team?
A: A style guide records team-specific decisions (capitalization, date format, voice, terminology) so writers do not re-debate them per page and the site feels uniform.

Q: What is the "Google Developer Documentation Style Guide"?
A: It is a widely adopted public style guide covering word choice, formatting, voice, and inclusive language for technical content. Many teams adopt it as a baseline.

Q: What is the "Microsoft Writing Style Guide"?
A: It is a public style guide focused on plain language, accessibility, and a warm, direct voice, used across Microsoft Learn and adopted by other teams.

Q: Why is inclusive language important in docs?
A: Inclusive language avoids alienating or stereotyping readers, widens the audience, and reflects the team's values; specific words ("allowlist", "primary/replica") are usually easy swaps.

Q: What is the "second person" rule in instructions?
A: Address the reader as "you" rather than "the user" or "one". It shortens sentences, matches how readers think about themselves, and reads more like a guide than a manual.

Q: What is "tense" in technical writing and which is preferred?
A: Use simple present for describing current behavior ("The API returns 200 on success") and simple past for reporting completed actions. Avoid future tense for documented behavior.

Q: What is "voice" in technical writing?
A: Voice is the personality the document projects: direct, helpful, neutral, sometimes warm. A consistent voice builds trust across pages.

Q: What is the "F-shape" reading pattern?
A: It describes how web readers scan: horizontally across the top, then a shorter horizontal sweep further down. Docs use headings, lists, and bold to feed this pattern.

Q: What is the "inverted pyramid" applied to a single paragraph?
A: Lead with the conclusion or main action of the paragraph, then add the conditions, edge cases, and background, so scanners get the point in the first sentence.

Q: What is a "TL;DR" section?
A: "TL;DR" ("Too Long; Didn't Read") is a short summary block at the top of a long page that gives the busy reader the key takeaway in one or two sentences.

Q: What is the role of an "Overview" section?
A: An overview sets context: what the feature is, what problem it solves, who should use it, and the minimum the reader needs to know before going deeper.

Q: What is a "Glossary" and when does it pay off?
A: A glossary defines domain terms in one place. It pays off in any product with a heavy domain (security, finance, ML) and reduces inline definitions.

Q: What is the "minimum viable documentation" for a new feature?
A: For most features, ship a short overview, a quickstart, and a reference for every public option. Other doc types come later, once support feedback shows gaps.

Q: What is a "doc plan"?
A: A doc plan is a short list of the docs to write, update, or retire for a release, mapped to features, with owners and dates, agreed before launch.

Q: What is the "docs as code" approach?
A: Docs as code stores documentation in the same repository as the product, in plain text (Markdown, AsciiDoc), reviewed via pull requests, and built by a static site generator.

Q: What are the benefits of "docs as code"?
A: Versioned with the product, reviewed by engineers, branched per release, searchable as text, and CI-checkable for broken links and lint rules.

Q: What is a "static site generator" for documentation?
A: It is a tool (e.g. Docusaurus, MkDocs, Sphinx, Hugo) that turns plain-text source files into HTML, navigation, and search indexes for a docs site.

Q: What is "continuous deployment" of documentation?
A: It means doc changes merged to the main branch are automatically published within minutes, so users see updates as soon as engineers ship them.

Q: What is a "doc lint" tool?
A: A doc lint tool (markdownlint, Vale, alex) automatically checks prose for style issues, banned words, broken links, and accessibility problems in CI.

Q: What is "Vale" and why is it popular for docs?
A: Vale is a syntax-aware prose linter that runs locally and in CI. Teams ship custom rule sets to enforce their style guide, including domain terminology.

Q: What is a "broken link" check?
A: It is an automated crawl that follows every link in the docs and reports any that 404 or redirect unexpectedly, often run on every pull request.

Q: What is "information architecture" (IA) in a docs site?
A: IA is the structure of categories, sections, and pages that determines how readers find content. Good IA matches the reader's tasks, not the org chart.

Q: What is a "card sort" exercise for docs?
A: A card sort is a UX exercise where readers group proposed doc topics into categories. The result informs navigation labels and section boundaries.

Q: What is a "user journey" in docs?
A: A user journey is the sequence of docs a typical reader traverses from "I just heard about this" to "I have a working advanced setup." Docs should make each step land.

Q: What is "task success" in documentation?
A: Task success is the rate at which a reader with a goal completes it using the doc alone. The single most important metric for procedural content.

Q: What is "time to first hello world"?
A: It is the time from opening the Quickstart to seeing a working sample output. Shorter is better, and it is a common KPI for SDK and framework docs.

Q: What is a "feedback widget" on a docs page?
A: It is a small "Was this helpful?" prompt that lets readers flag bad pages. Aggregated feedback is a strong signal for what to rewrite first.

Q: What is a "docs review" and who should do it?
A: A docs review is a structured pass that checks accuracy (does it match the product?), completeness (are edge cases covered?), and clarity (would a new reader get it?). Engineers, writers, and ideally a fresh reader all contribute.

Q: What is a "technical reviewer" for documentation?
A: A technical reviewer is an engineer or subject-matter expert who verifies that the doc's claims about the system are correct, and that examples actually run.

Q: What is a "copy edit" pass?
A: A copy edit pass focuses on language: grammar, spelling, style, terminology consistency, and tone. It comes after technical review.

Q: What is the "dumb it down" trap in technical writing?
A: It is the assumption that simpler always means better. Important nuances, constraints, and edge cases must be preserved; clarity is not the same as oversimplification.

Q: What is the "curse of knowledge" in technical writing?
A: It is the tendency, once an author understands a topic, to forget which parts are hard, and to skip the steps and definitions a beginner actually needs.

Q: What is a "smoke test" for an example?
A: A smoke test is running the example exactly as written, in a fresh environment, and confirming the documented output appears. Examples that fail the smoke test should not ship.

Q: What is a "golden path" in product documentation?
A: The golden path is the shortest, most-supported route through the product to a useful result. Docs should make this path obvious and well-paved.

Q: What is "edge case" documentation?
A: Edge case documentation covers non-default inputs, error conditions, limits, and behaviors at boundaries. It is usually in reference or troubleshooting, not in tutorials.

Q: What is the "happy path" versus the "unhappy path"?
A: The happy path is the sequence where everything works as expected. The unhappy path covers errors, retries, and failures. Both deserve documentation.

Q: What is an "error code" reference?
A: An error code reference lists every error the system can return, with a unique identifier, a plain-language meaning, common causes, and remediation steps.

Q: What is the "troubleshooting tree"?
A: A troubleshooting tree is a decision structure: "If you see X, check Y. If Y is true, do Z. If Y is false, check W." It maps symptoms to actions without prose walls.

Q: What is a "FAQ" page good for?
A: An FAQ is good for short, recurring, real questions from support, sales, or community channels. It is not a substitute for proper How-tos for complex tasks.

Q: What is the difference between "FAQ" and "Troubleshooting"?
A: An FAQ answers anticipated, generic questions. Troubleshooting diagnoses specific symptoms with concrete next steps; it is procedural, not informational.

Q: What is a "release note" in technical writing?
A: A release note is a short, dated entry per version that calls out user-visible changes, with links to the relevant docs and to the changelog.

Q: What is the "single source of truth" principle for docs?
A: Information should live in exactly one place. Other pages link to it, never copy-paste it, so updates propagate automatically and never contradict each other.

Q: What is a "duplicate content" problem in docs?
A: When the same guidance is written in two places, the two copies drift apart, and a reader following the wrong copy wastes time or hits bugs. Centralize, then link.

Q: What is a "stub" page?
A: A stub is a placeholder page that exists so a link does not 404, but contains only a heading and a TODO. Stubs are useful in a doc plan, harmful if they ship unflagged.

Q: What is a "redirect" used for in docs?
A: A redirect sends a reader from an old or renamed URL to the new canonical page, preserving SEO and external links while content moves.

Q: What is a "canonical URL"?
A: A canonical URL is the one preferred address for a page. Other addresses (with or without trailing slashes, query parameters) should redirect to it.

Q: What is the "headings hierarchy" rule?
A: Headings should descend without skipping levels: H1 once, then H2 for top sections, H3 inside H2s, and so on. This keeps the table of contents and screen-reader navigation honest.

Q: What is "anchor text" in documentation?
A: Anchor text is the visible words of a link. Effective anchor text is descriptive of the destination ("OAuth setup guide") and never "here", "this", or a raw URL.

Q: What is "alt text" length guidance?
A: Alt text should be concise (a sentence or less), describe what the image conveys rather than how it looks, and stay empty for purely decorative images.

Q: What is the "mobile-first" consideration for docs?
A: On mobile, long paragraphs, wide tables, and side-by-side code blocks break. Write for narrow screens first; wide layouts are a progressive enhancement.

Q: What is "search-first" navigation?
A: Some readers always search instead of browsing navigation. Docs must work via search: titles should match the words readers actually type (error messages, parameter names).

Q: What is a "landing sentence" on a long page?
A: It is the first sentence after the page title that previews what the page is for and the concrete task it accomplishes, so scanners can confirm they are in the right place.