# How do we build a task-coverage map that keeps technical documentation navigation honest?

> Model documentation around canonical user tasks, then use that map to drive navigation, ownership, and release maintenance.

Canonical URL: https://www.devobs.io/articles/qa-ge50-task-coverage-map-docs-navigation/
By: Theo Morgan
Published: 2023-04-07T05:49:17.109Z
Updated: 2026-09-06T10:18:15.722Z
Section: Architecture

Build the map around canonical user tasks and treat it as maintained architecture, not a content inventory. Define the tasks, prerequisites, branch points, and completion criteria first; that is the enforced ordering boundary. Then assign every page a role in helping a reader start, continue, recover, or finish that task. Navigation stays honest when pages must prove they move a real task forward rather than merely exist in a sidebar.

## What should count as coverage?

Coverage should mean task completion coverage, not page count or feature count. A task is something with a visible finish line: create an API client, rotate a key, debug a failed [webhook](https://www.devobs.io/articles/webhook-delivery-protocol-design/) signature, onboard a new tenant.

That only works if you separate content by purpose. [Diátaxis](https://diataxis.fr/) argues documentation should be organized around distinct user needs: tutorials, how-to guides, reference, and explanation. In practice, your how-to content should own task completion, your reference should answer point questions, your explanation should support decisions, and your troubleshooting should unblock failure states. If one page tries to do all four, navigation may look complete while readers still cannot finish the job.

## How do we model the task map?

Use a graph, not a tree. For each canonical task, capture:

- entry point
- prerequisites
- decision points
- supporting pages
- failure paths
- completion check

The important sequence is this: define the task graph first, then design navigation from it, then write or revise pages. If you reverse that order, the sidebar becomes a guess about user journeys.

Next, build a page-to-task matrix. Mark whether each page starts, supports, unblocks, or completes a task. This quickly exposes drift:

- pages with no task owner
- two pages claiming to start the same task
- reference pages that never route back to a workflow
- troubleshooting pages that explain errors but do not reconnect the reader to the failed step

[Google’s developer documentation style guide](https://developers.google.com/style) is useful here because it explicitly frames a style guide as a reference for specific questions. That is the right mental model for reference pages: valuable, but not the backbone of task navigation.

## How should navigation behave?

Navigation should offer the next valid move for the task the reader is in. A start page should state prerequisites plainly. A local guide should link forward to the next action, sideways to necessary explanation, and out to troubleshooting when the task can fail. A reference page reached from search needs an escape hatch back into the owning task.

[Write the Docs’ software documentation guide](https://www.writethedocs.org/guide/) describes documentation as a living guide and includes taxonomy and regular process as part of the work. That is the right maintenance model: the map belongs in release work, not in a one-time docs audit.

## What does a worked example look like?

Take the task “integrate service-to-service authentication for our API.”

Map it this way: start with choosing the auth pattern; require client credential setup; branch by environment; support with token endpoint reference; add failure paths for invalid audience and expired credentials; complete with a successful authenticated API call.

That map often reveals three defects immediately: duplicated credential setup in multiple guides, a token reference page with no route back to the integration flow, and an error page that names the problem without restating the corrective step.

## Questions about task-map tooling and page reuse

**Do we need special tooling first?** No. A spreadsheet or YAML file is enough if task ownership stays current.

**Should every page map to exactly one task?** No. Reference and explanation pages can support several tasks, but every critical task still needs one canonical completion path.

Next step: choose one high-value journey, draw its task graph on a single page, and use that graph to rewrite one docs section before the next release.

Reviewed: 2026-09-05.

## Source references

- <https://diataxis.fr/>
- <https://developers.google.com/style>
- <https://www.writethedocs.org/guide/>