Skip to content
Writing Style Library

User Manual

Comprehensive documentation covering everything a user can do with a product, organized for lookup.

User Manual

Section titled “User Manual”

A user manual is comprehensive documentation that covers everything a user can do with a product, organized so a reader can look up any feature or task when they need it. Unlike documentation designed to be read from start to finish, a user manual is a reference artifact: the reader arrives with a specific question, locates the relevant section, reads what they need, and returns to the product. Completeness and reliable retrieval across the whole product surface are the defining values.

The format earns its place by serving a reader who already knows what they want to accomplish but needs the exact steps, parameters, or options for this specific product. A user manual assumes a capable reader who is not new to the product category but may be unfamiliar with this product’s conventions. It documents the product as it is, not as a teaching exercise, and trusts the reader to apply the information without capability-building scaffolding.

Good user manuals are organized for lookup, not for reading. The table of contents is a navigational instrument. Section titles name features and tasks in terms the reader will recognize when searching for them - not terms organized by system architecture or build sequence. Each section is self-contained enough that a reader can enter from the table of contents and find what they need without reading surrounding sections.

Unlike a how-to guide, which teaches one task end to end for a learner building capability, a user manual documents all tasks and features for a reader who arrives knowing what they want and consulting the relevant section the way one uses a dictionary rather than a tutorial.

Canonical template

Section titled “Canonical template”
# [Product Name] User Manual


## Table of Contents
[Section list organized by feature or task name]


## Getting Started
[System requirements, installation, account setup, and first-session prerequisites.]


## [Feature or Task Area 1]


### [Task or Subtask Name]
[Brief statement of what this feature does and when a user would reach for it.]


Steps:
1. [Concrete instruction]
2. [Concrete instruction]
...


Options / Parameters:
- [Option name]: [What it controls, valid values or range]


Notes:
- [Edge case, constraint, or version-specific behavior]


## [Feature or Task Area 2]
...


## Troubleshooting
[Symptom]: [Cause and resolution]


## Reference
[Index, glossary, or quick-reference tables]

When to use

Section titled “When to use”

Documenting a product or tool where users need to look up specific features or tasks at the moment of need rather than learn the product from scratch. Shipping the authoritative reference alongside a product that users will return to repeatedly across many sessions. Covering the full surface area of a product when one how-to guide per task would be impractical. Supporting users at all experience levels who need lookup access to features they have not yet used. Creating a lasting reference whose modular section structure remains accurate and maintainable across product versions.

When not to use

Section titled “When not to use”

Teaching a complete beginner who needs guided, capability-building instruction through a specific task for the first time (use a how-to guide). Providing quick expert lookup for parameters, flags, or syntax when the reader already knows exactly what they need (use API reference or a cheat sheet). Explaining concepts, background, or architectural decisions that do not map to a specific task or feature the user can perform.

Pairs well with

Section titled “Pairs well with”

technical-writer, operator, instructional, matter-of-fact, procedural

Often confused with

Section titled “Often confused with”

how-to-guide: A how-to guide teaches a reader to accomplish one specific task they do not yet know how to do, walking them through the steps with enough context to understand what they are doing and why. The goal is a reader who, having followed the guide once, could reproduce the task without the guide the second time - capability, not just completion, is the measure. A user manual is not a teaching document: it covers all tasks and features across the whole product surface for a reader who already has capability and arrives to look up a specific thing. Where a how-to guide takes a learner through one task end to end, a user manual is consulted the way one uses a dictionary rather than a tutorial.

technical-reference: A technical reference is a precise specification of inputs, outputs, and syntax for a developer artifact (API, library, CLI, config schema), organized by signature, parameters, and returns. A user manual is whole-product, end-user task and feature coverage with numbered procedural steps. The discriminator: if the unit of organization is a function, endpoint, or field, it is a technical reference; if it is a user-facing feature or task with steps, it is a user manual.

Tells

Section titled “Tells”
  • A table of contents that lists features and tasks by name, functioning as the primary navigation instrument for the document
  • Self-contained sections a reader can enter directly from the table of contents without reading surrounding material
  • Feature-first or task-first organization, not arranged by system architecture or development sequence
  • Terse, declarative prose that names what the product does rather than teaching the reader why it works or building capability
  • Step-numbered instructions within sections that rely on product terminology without defining it from first principles
  • Cross-references within sections pointing to related features rather than prescribing a linear reading sequence

Anti-patterns

Section titled “Anti-patterns”
  • Organizing sections by system architecture or internal component rather than by user task or feature name - A user who wants to accomplish something thinks in task terms, not system terms. Architecture-first organization forces readers to know how the product is built before they can find what they need to do.
  • Writing each section as a how-to guide complete with prerequisites blocks, capability-building explanations of why each step matters, and troubleshooting for the learner - A how-to guide teaches one task end to end for a reader who is building capability and wants to understand what they are doing. A user manual documents all features for a reader who arrives with capability already and needs only the specific steps for this product. Teaching scaffolding in a reference document slows down a reader who came to look something up.
  • Omitting a navigable table of contents, or organizing the table of contents to mirror the product build order rather than user lookup order - The table of contents is the primary navigation instrument of a user manual. A reader who cannot locate the right section from the table of contents cannot use the manual. Lookup order matters more than order-of-construction logic.

Failure modes

Section titled “Failure modes”
  • Over-comprehensive - the commitment to covering the whole product surface drives the manual into exhaustive edge-case documentation, so every common task is buried in variant tables and parameter matrices that serve no reader who has just arrived with a single question - Organize comprehensiveness hierarchically: standard cases prominent in the section body, edge cases and full parameter tables in sub-sections or appendices. A reader who needs the edge case will find it; a reader who does not need it will not be slowed by it.
  • Over-terse - the reference register is pushed so far that sections become command listings and parameter names with no context, producing output only parseable by a reader who already knows what the feature does and why they want it - Each section needs at minimum a brief statement of what the feature does and when a user would reach for it. Even in a reference register, that one sentence of orientation is not teaching - it is the anchor that makes the steps that follow usable.
  • Over-modular - the self-contained section principle is taken to the extreme, repeating boilerplate across every section that shares a concept, inflating the document and introducing contradictions when updates touch only some of the duplicated content - Use cross-references and a central Reference section for shared concepts rather than duplicating content. Trust the reader to follow a link. Redundancy that seemed helpful in authoring becomes a maintenance liability and a trust eroder when sections drift out of sync.

Instruction

Section titled “Instruction”
Write as a User Manual. Organize the content by user task or feature name, not by system
architecture or development sequence. Begin with a navigable table of contents that lists
sections in lookup order. Write each section to be self-contained: a reader who enters from the
table of contents should find what they need without reading surrounding sections.


Within each section, open with a brief statement of what the feature does and when a user would
reach for it. Then give the steps in numbered form, using concrete instructions and
product-specific terminology. Include options, parameters, or valid values where relevant.
Collect edge cases and notes at the end of the section or in a sub-section, not inline in the
main steps.


Use terse, declarative prose throughout. Do not teach the reader why the product works the way
it does; document what it does and how to use it. Do not add capability-building scaffolding.
Add cross-references to related sections rather than repeating content. Close the manual with a
Troubleshooting section and a Reference section (index, glossary, or quick-reference tables).

Template

Section titled “Template”

See the User Manual template.

Section titled “Related”

Pairs well with

Section titled “Pairs well with”

Technical Writer, Operator, Instructional, Matter of Fact, Procedural

Avoid with

Section titled “Avoid with”

Confessional, Reverent, Playful

Often confused with

Section titled “Often confused with”

How-To Guide, Technical Reference

Examples

Section titled “Examples”

Team Standup User Manual

Section titled “Team Standup User Manual”

Table of Contents

Section titled “Table of Contents”
  • Getting Started
  • Posting Your Daily Update
    • Writing and posting your update
    • Marking a blocker resolved
  • Reading the Channel (On-Call Duties)
    • Daily triage
    • Escalating a blocker
  • The Thursday Working Session
  • Special Cases
    • PTO
    • On-call days
    • No update to give
    • Sensitive or people-related blockers
    • Public holidays
  • Troubleshooting
  • Reference

Getting Started

Section titled “Getting Started”

This manual covers the #team-standup async process used by the eng-platform team (11 engineers across US Pacific, US Eastern, UK, and India). It replaced the team’s synchronous daily standup and is running as a 30-day trial, 2026-05-19 through 2026-06-19, owned by Maya Chen (EM Platform).

Requirements:

  • Access to the #team-standup channel in the eng-platform Slack workspace.
  • If you are on the on-call rotation, access to #on-call-schedule and #on-call-log as well.
  • Five minutes a day to write and post an update.

First session:

  1. Read the pinned message in #team-standup. It holds the current template and house rules.
  2. Note your own posting deadline: 10am in your local timezone, not Pacific.
  3. Check #on-call-schedule to see whether you are on the on-call rotation this week (see Reading the Channel).

Posting Your Daily Update

Section titled “Posting Your Daily Update”

What this covers: the daily status update every engineer posts, and how to close the loop once something you flagged gets resolved.

Writing and posting your update

Section titled “Writing and posting your update”

What it does: records what you shipped, what you are working on, and what is blocking you, in a format the rest of the team can skim in under a minute.

Steps:

  1. Copy the pinned template from #team-standup, or trigger it with the /standup shortcut.
  2. Fill in the three fields: Shipped, In progress, Blocked or at risk.
  3. In the Blocked or at risk field, @mention the specific person who can resolve each item.
  4. Post before 10am your local time.

Template:

Shipped:
 - <what landed since your last post>


In progress:
 - <what you are actively working on today>


Blocked or at risk:
 - <what is stuck, and who or what you need>

Options / Parameters:

  • Empty field: write “nothing today” rather than deleting the field.
  • Skipping a field entirely: acceptable on Fridays only.
  • Backfill window: same day, until 17:00 your local time, if you miss the 10am cutoff.
  • Cannot post before 10am (early meeting, travel): post the previous evening instead, with a “tomorrow:” prefix on the In progress line.

Notes:

  • A valid blocker names three things: what is blocked, who can unblock it, and when you need it. “@user, can you review #4412 today?” is a blocker. “Reviews are slow” is not, and will not route anywhere.
  • Sensitive or PTO-affected updates follow different rules. See Special Cases.

Marking a blocker resolved

Section titled “Marking a blocker resolved”

What it does: closes the loop on a blocker you previously posted, so the channel stays a reliable record of what actually happened.

Steps:

  1. Edit your original post to reflect the resolution, or
  2. Reply in the same thread with resolved: and the outcome.

Notes:

  • Do not delete the original line. The searchable record of what was blocked and how it resolved is part of the point of moving async.

Reading the Channel (On-Call Duties)

Section titled “Reading the Channel (On-Call Duties)”

What this covers: the daily triage responsibility assigned to whichever engineer is on the on-call rotation that week. If you are not on-call this week, you do not need this section.

Daily triage

Section titled “Daily triage”

What it does: confirms every blocker posted that day gets a response, and surfaces anyone who has not posted.

Steps:

  1. Between 10:00 and 11:00 Pacific, open #team-standup and review the day’s posts.
  2. Tally posts received against today’s expected headcount (11 minus anyone confirmed on PTO).
  3. If fewer than 80 percent of expected posts have arrived by 10:30 Pacific, direct-message anyone missing: “Hey, no standup post yet today, any blockers?”
  4. Read every post and identify each @mention inside a Blocked or at risk field.
  5. Reply in-thread to every @mention (a resolution, a diagnostic question, or a handoff) within 30 minutes of your first read.
  6. For any at-risk line with no @mention, reply in-thread asking whether the engineer needs help.
  7. Post a triage summary in #on-call-log: “Standup triage [date]: [N] posts received, [N] blockers found, [N] resolved, [N] escalated.”

Options / Parameters:

  • Rotation: the same engineers who previously facilitated the synchronous standup.
  • Response SLA: 30 minutes during the resolver’s business hours.
  • Time budget: 10 minutes per morning under normal conditions.

Notes:

  • Triage running closer to 25 minutes on a given morning usually means blockers are surfacing earlier than they did under the old sync model. That is the system working, not a sign it is broken. See Troubleshooting before asking to split the rotation.
  • Triage is read-and-respond only; there is no system state to roll back. If you reply in the wrong thread, post a correction in the same thread.

Escalating a blocker

Section titled “Escalating a blocker”

What it does: moves an unresolved blocker up the chain when the normal @mention and reply does not clear it.

Steps:

  1. Day 0, at post time: the engineer @mentions the resolver in their update.
  2. Plus 4 business hours: the on-call engineer nudges the resolver in-channel.
  3. Plus 1 business day: on-call escalates to the resolver’s manager.
  4. Plus 2 business days: escalates to Maya Chen.

Notes:

  • This ladder runs alongside the 30-minute first-response SLA. The SLA covers acknowledgment; the ladder covers what happens if acknowledgment does not turn into resolution.

The Thursday Working Session

Section titled “The Thursday Working Session”

What this covers: the 60-minute weekly slot that replaced the block of synchronous standups, reserved for anything that genuinely needs real-time discussion.

Steps:

  1. Check the agenda at docs/thursday-agenda.md before the session.
  2. Add a topic to the agenda by 17:00 Pacific Wednesday if you need real-time discussion time.
  3. Attend Thursdays at 8:00 Pacific / 20:30 IST.

Options / Parameters:

  • Length: 60 minutes.
  • Cancellation: if the agenda is still empty by 17:00 Pacific Wednesday, the session is cancelled and the time is given back.

Notes:

  • This is not a status meeting. Status belongs in #team-standup. Bring decisions, design questions, and anything that needs real-time back-and-forth.

Special Cases

Section titled “Special Cases”

What this covers: how to post when your day does not fit the standard pattern.

PTO

Section titled “PTO”

Post one line on your last working day before you leave: “OOO <date range>, back <date>. Coverage: @user.” Do not post while on PTO.

On-call days

Section titled “On-call days”

Post your normal update, plus a fourth line: “On-call: responding to pages, async post may be late.” On-call days do not count against your participation metrics.

No update to give

Section titled “No update to give”

Post anyway, with “nothing today” in each field that does not apply. A thin update is easier to interpret than no update at all.

Section titled “Sensitive or people-related blockers”

Post “Blocked: DMing @maya” in the channel and take the actual content to a direct message. Do not name the person involved in the channel.

Public holidays

Section titled “Public holidays”

Post on the days you work. On a public holiday for your locale, skip without notice.

Troubleshooting

Section titled “Troubleshooting”

Posts are running long, 200 words or more: The three fields are prompts for short bullets, not headers for paragraphs. Point to the exemplar posts pinned in the channel and hold the three-bullet ceiling at the Thursday session.

A timezone cluster is consistently late or silent: Check whether the 10am local cutoff is achievable for that group. If their workday starts at or after 10am local, the cutoff is a scheduling problem, not a compliance one. Move their window.

A thread under a blocked item runs past a few messages: Standup threads are for clarifying questions, not decisions. Move the conversation to a DM or add it to the Thursday agenda.

On-call triage is regularly running over the 10-minute budget: See the note under Daily triage. Give it a week before restructuring the rotation.

An engineer has not posted and has not replied to a DM within 60 minutes: Escalate to Maya Chen with the engineer’s name and last known context.

Reference

Section titled “Reference”

Template fields

FieldIncludesExcludes
ShippedWork merged, deployed, or otherwise complete in the last 24 hoursWork in review, planning, meetings attended
In progressCurrent focus through your next workdayBacklog items, speculative work
Blocked or at riskAnything where someone else’s input changes your dayVents, status with no ask

Timing at a glance

EventTime
Daily post deadline10:00 local time
Backfill windowSame day, until 17:00 local
On-call triage window10:00 to 11:00 Pacific
Blocker response SLA30 minutes, resolver’s business hours
Thursday working session8:00 Pacific / 20:30 IST, 60 minutes
Thursday agenda cutoff17:00 Pacific Wednesday

Metrics tracked (pulled weekly by Priya)

MetricTarget
Participation rate (posts / engineers / workday)9 of 11 or better
Blocker response time (post to first substantive reply)Under 30 minutes
Stale blockers (open more than 2 business days)Zero

Glossary

  • On-call reader: the engineer assigned to daily channel triage that week.
  • Blocker: an item that needs another person’s input, tagged with an @mention.
  • At risk: an item trending toward becoming a blocker, not yet actionable by anyone else.

Related documents

  • Process playbook: docs/playbook.md
  • Thursday agenda: docs/thursday-agenda.md
  • Trial retro: docs/trial-retro.md
  • Decision record: ADR-0014, Adopt Async-First Standup Format
  • Channels: #team-standup, #on-call-log, #on-call-schedule