How do I turn a list of rules into instructions readers can apply to a real task?

Treat each rule as a requirement to translate, not a sentence to paraphrase loosely. For every item, capture what it requires, who or what it applies to, any condition or exception, and the official source. Then decide whether the reader needs an action, a choice, or a completion check.

A useful pattern is: When [situation], do [action] by [time or condition], then check [evidence of completion]. Fill only the parts the rule actually specifies. Don’t add a deadline, document, or exception just because it sounds helpful.

Put instructions before or beside the activity, break them into complete steps, and use clear language and examples when useful. These are W3C supplemental cognitive-accessibility recommendations, not a substitute for interpreting the applicable rule. [S1] For web content, W3C also recommends clear instructions, short sentences, and lists where appropriate. [S2]

Make one worksheet row per rule. Keep the source wording separate from your plain-language instruction so you can compare them. For example, using a hypothetical placeholder rule—“[Submit the required form before [specified event]]”—you might draft:

• Rule as written: [Paste exact rule]
• Source and version/date checked: [Official source; date checked]
• Applies when/to: [Condition or audience stated in source]
• Reader action: Submit [form named in source]
• When: Before [event named in source]
• Decision point: If [condition explicitly stated], [action stated in source]
• Completion check: [What the source says confirms completion, or “not specified”]
• Unclear or missing: [Question to resolve with the policy owner]

The placeholder is a writing example, not a real policy. If the source does not define a completion check, don’t invent one. Keep the source’s requirements and your explanatory wording visibly distinct.

Sort actions by what readers must do first, next, and last—not by the order that rules happened to appear in your notes. Keep an exception directly beside its rule so it cannot be mistaken for a general step. Use a decision question only when the source gives a condition that changes what the reader must do.

A safe draft shape is:

1. Before starting: [Preparation the rule actually requires].
2. Do: [Required action, including any stated format or destination].
3. If [source-defined condition]: [The applicable action or exception].
4. Check: [Source-defined way to confirm; otherwise mark what remains unspecified].

For each step, ask whether a reader can tell what to do and when. If a key term or format needs explanation, define it without silently changing the requirement. W3C recommends describing requirements such as accepted date formats in web instructions; the applicable official source must establish what the requirement means. [S2]

Do a rule-to-instruction comparison, one row at a time. Confirm that every requirement appears somewhere, and that every added instruction is supported by the source or clearly labeled as an editorial aid. Check conditions, exceptions, order, and any stated formats. If the rule depends on a policy that may change, verify it against the current official source before publishing; this worksheet does not establish whether a policy is current or resolve ambiguity in it.

You can finish with a small traceability check: place the rule identifier beside the step that implements it. That helps reviewers spot rules with no corresponding action and actions with no supporting rule. If an issue remains unresolved, write a question for the qualified policy owner rather than turning an assumption into an instruction.