Skip to content

Readability and Plain Language

Instruction Comprehension Test

Observe whether representative readers can understand, sequence, execute, verify, and recover from a written procedure in a realistic environment.

Free editable Markdown · Technical writers, UX researchers, and support teams ·

Download Markdown

Accessible HTML preview

Blank template

The downloaded file contains the same fields in editable Markdown.

Test setup

Instruction title and version
[Name and date]
Participant profile
[Relevant knowledge, language, and access needs]
Environment
[Device, product, version, account role]
Starting state
[Files, settings, or materials]
Task goal
[Neutral scenario]
Success condition
[Observable result]
Critical steps
[Steps where error has high consequence]
Stop or safety rule
[When the facilitator intervenes]
Consent and recording
[Approved method]

Observation record

Participant ID
[Non-identifying code]
First action
[What they do]
Pause or reread
[Step and observation]
Incorrect path
[Choice and likely cause]
Help requested
[Question and source used]
Skipped prerequisite
[What was missed]
Expected result recognized
[Yes/no and explanation]
Recovery
[Could the participant correct safely?]
Outcome
[Complete, partial, stopped, or incorrect]

Revision checks

  • Findings distinguish words, layout, sequence, interface, and system issues.
  • Facilitator coaching is recorded rather than counted as success.
  • Warnings precede risky actions.
  • Decision points state how to choose a path.
  • Expected results reveal wrong turns early.
  • Troubleshooting starts from observable symptoms.
  • Critical revisions receive fresh testing.
  • Version, owner, and retest triggers are documented.

How to use this template

  1. Define the intended reader, supported environment, starting state, outcome, and critical comprehension behaviors.
  2. Prepare neutral tasks, safe test data, consent, stop rules, and observation criteria.
  3. Run sessions without coaching, recording actions, words, errors, help use, success recognition, and recovery.
  4. Diagnose root causes and rank revisions by consequence and frequency.
  5. Retest critical changes and document the approved instruction version plus maintenance triggers.

Define observable comprehension

Replace “Does this make sense?” with behaviors that show understanding: selecting the right path, preparing prerequisites, completing steps in order, recognizing expected output, explaining a warning, and recovering from a likely error. Identify critical steps where failure has higher consequence. Write neutral tasks that describe the participant's goal without quoting the instruction's labels or revealing the path. Include realistic constraints such as device, account role, version, time, and prior knowledge.

Observe without becoming the missing instruction

Ask participants to use the material as they normally would, thinking aloud when comfortable. Record where they pause, reread, skip, choose incorrectly, ask for help, or create a workaround. The facilitator should not coach unless a predetermined safety or stop condition is reached. Note whether the problem comes from wording, sequence, layout, interface mismatch, missing prerequisite, or system behavior. A successful finish can conceal confusion if the participant relied on prior expertise unavailable to the intended audience.

Revise and retest consequential failures

Prioritize errors that block completion, create risk, or undermine confidence. Add an expected result after a step when readers need to detect a wrong turn early. Put warnings before the action and link troubleshooting to observable symptoms. Retest changed sections with a fresh participant when possible, especially if revision alters sequence or decision logic. Preserve version, environment, test data, and findings so later product changes can trigger focused validation rather than repeating an undocumented session.

See the fields in context

Fictional example: reserve a music practice room

SoundStep is an invented booking service and the observed behaviors are illustrative.

  • Task: Reserve a fictional accessible practice room for Thursday using a test account.
  • Observation: A participant selects a room before choosing duration, then loses the room selection when duration changes.
  • Diagnosis: Instructions list controls in visual order but not dependency order.
  • Revision: Choose date and duration first, then show compatible rooms and the expected availability message.
  • Retest: A fresh fictional participant completes the sequence and explains what the confirmation means without coaching.

Frequently asked questions

Is asking readers whether instructions are clear enough?

No. People may report that text seems clear yet make errors during the task. Observe performance and ask them to explain key decisions and outcomes.

Should experts participate in the test?

Experts are valuable reviewers, but they may compensate for missing context. Include people who resemble the intended reader's actual knowledge and constraints.

What counts as facilitator assistance?

Any hint, correction, demonstration, rephrasing, or answer not available through the tested material. Record it because the participant did not complete that point independently.

When should instructions be retested?

Retest after consequential content, interface, dependency, permission, safety, or audience changes, and after a critical comprehension failure is revised.

File details

File name
instruction-comprehension-test.md
Format
Markdown (.md)
Size
3 KB
Designed for
Technical writers, UX researchers, and support teams

Usage note: Use this template to test a draft procedure with representative people and a safe, realistic starting state. Obtain appropriate consent and avoid production, personal, confidential, or hazardous materials. For medical, legal, financial, industrial, or safety-critical procedures, combine usability work with qualified domain review and the testing standards required for that context.