Choose the form that fits the reader's task: a comparison table, a sequence of steps or a worked example. Google's documentation style guide recommends tables for items with three or more related pieces of information, with lists or description lists for simpler structures.
Before shortening a dense passage, find the relationship the reader needs. Cutting the condition that changes their next action would make the page shorter and the instructions wrong.
What is the reader trying to do with this passage?
Decide whether they need to compare options, carry out a task or understand a decision. Align matching attributes for comparison, put actions in order for a procedure, and explain the reason when a choice needs judgment. Some of that explanation belongs in ordinary prose.
The examples below use Cedar Drafts, an invented documentation app. Its rules and review request were written for this exercise. We will restructure selected parts; the complete source passages remain available.
This assumes the source is sound. If the problem is missing evidence or an unclear point, diagnose the passage first. A table cannot supply a fact the writer never had.
When does a table make the comparison clearer?
Use a table when the same meaningful attributes apply to several options. Give each attribute a row so the reader can compare one thing at a time.
Here is an extract from the review-mode paragraph:
… permits named guest review only when the body has been cleared for that particular outside reviewer, and permits public preview only when the body has been cleared for public release.
That condition appears among other details about access and reviewing. Pulling the selected outside-review attributes into a table gives them a consistent place:
| What to compare | Named guest review | Public preview |
|---|---|---|
| Who can open it | One invited email address; sign in with that address | Anyone holding the link; no sign-in |
| Review actions | Read and comment | Read only; no comments |
| Required clearance | Body cleared for this particular outside reviewer | Body cleared for public release |
“Approved sharing” would be a shorter clearance label, but it would erase the distinction between those two permissions. Sending a public link to one person does not restrict who can open it.
This table covers these attributes, not every condition for choosing a mode. If the passage only listed the two mode names, a list would do; there would be no shared attributes to align.
How do I turn a paragraph into steps a reader can follow?
Put prerequisites before the actions, show what each action returns and keep a correction beside the check that triggers it. Google's procedure guidance supports that order and allows small related actions to be combined.
The source's correction is buried in the middle of a paragraph. This extract contains the branch:
If either differs, the editor closes the preview, corrects the selected revision or address, and previews again; editing text inside the preview is not possible and does not substitute for selecting the right saved revision.
Here is the complete invitation procedure, arranged so the editor encounters that branch before creating anything.
Before starting: have the Author role, the saved revision named in the review request, the assigned guest's email and clearance to share that revision's body with that guest. If the role or clearance is missing, leave the draft private and ask the document owner to resolve it.
- In Revisions, open the requested saved revision. Choose Guest review and enter the assigned guest's email.
- Select Preview. It shows the snapshot body, revision number and invited email.
- Compare the revision and recipient with the request.
- If either differs, close the preview, correct the selected revision or address, then preview again. The preview body cannot be edited.
- Continue only when both match.
- Select Create invitation. It returns a review link and an expiry time seven calendar days after creation.
- Copy the link and expiry into the review request, alongside the matching revision and recipient.
The invitation is prepared when those four fields are in the request. Creating it sends no email; the document owner sends it through the team's existing review channel.
Step 3 determines whether the editor can continue. Moving its correction below the whole procedure would leave creation on the apparent path even after a mismatch.
When is a worked example better than another rule?
Use an example when the reader needs to understand why an attractive option fails. Supply the requirement, show the relevant behavior and explain the consequence.
The source gives this rule:
An editor must not silently turn a requirement into a preference to select the closest match.
The following is a condensed case from the same source, focused on one option's update behavior:
- Option: Named guest review
Request and candidate
The outside reviewer needs to comment and see the author's latest saved edits through the same link. Replacement invitations are excluded. Named guest review allows comments, which makes it worth considering.
Decision
Reject named guest review for this request. It shows a frozen snapshot; later edits require a new snapshot and invitation. That conflicts with the required unchanged link. Return the conflict to the document owner before creating a guest link.
“Allows comments” is true but insufficient to justify this choice. The explanation makes the failed requirement visible instead of leaving the reader with an unexplained yes or no.
Does the new structure work inside the actual article?
Check the forms where readers will use them, at desktop and narrow widths. A correct source file can still become a table with unclear headers or a correction detached from its step.
- Comparison: each value must remain identifiable under its header. If the table scrolls sideways, check that the last column is reachable while the surrounding prose still fits.
- Procedure: keep the mismatch branch inside the comparison step, before Create invitation.
- Decision: keep the live-update requirement beside the explanation of the frozen snapshot.
W3C's table guidance explains why headers need structural markup. Its reflow guidance allows necessary table relationships to use scrolling while ordinary text still reflows.
Read the procedure once with the wrong recipient in the preview. The page should show you how to correct it before offering the action that creates the invitation.
Keep reading
Related guides.
Why an AI content workflow can still sound generic
Find why an AI-written draft feels generic. Use concrete examples to trace the problem to missing evidence, a vague brief, repeated structure, or wording.
Read the guideFact-check AI-generated content one claim at a time
Check an AI-written claim against its source, work through a hypothetical example, and decide what to keep, qualify, remove, or send for specialist review.
Read the guide