This is a ready-to-use controlled form. It records the single highest-value step in authoring a procedure and the one most often skipped: watching a real user try to follow the draft. Replace each <<FILL: ...>> placeholder with your own specifics and route the completed form with the SOP review package. A filled specimen follows.
Document control header
| Field | Entry |
|---|---|
| Form title | SOP Usability Dry-Run Record |
| Form number | <<FILL: FORM-ID, e.g. FORM-QA-021>> |
| Version | <<FILL: version>> |
| Parent SOP | Writing and Maintaining SOPs (<<FILL: SOP-ID>>) |
| Retention | Filed with the SOP review package; retained per the records retention schedule, not less than <<FILL: retention period>> |
Purpose
To surface unfollowable steps before a procedure is approved rather than after a deviation. A draft that reads well to its author can still stop a new user cold at a missing value, an undefined term, an implied handoff, or a decision with no defined path. The dry run finds those defects while they are cheap to fix. This record is the evidence that the test was run and that each defect was closed.
What the dry run is
A qualified but new user, someone who did not write the draft and would realistically perform the task, attempts the task using only the draft procedure and its forms, with the author observing and not helping. Every point where the user hesitates, asks a question, guesses, or reaches for knowledge the document does not contain is a defect in the document, not in the user. Each defect is logged and resolved before approval.
Session header fields
| Field | Format | Required | Who enters |
|---|---|---|---|
| Draft SOP number and title | ID + text | Yes | Author |
| Draft version tested | Draft version ID | Yes | Author |
| Task performed or simulated | Text | Yes | Author |
| Performed or simulated | Performed / Simulated (state why if simulated) | Yes | Author |
| Dry-run user (name, role, why representative) | Text | Yes | Author |
| Observer (author or delegate) | Name | Yes | Author |
| Date | Date | Yes | Author |
Defect log
For each point of friction, record one row.
| Field | Format | Required | Notes |
|---|---|---|---|
| Step reference | SOP step number or “framing” | Yes | Where the friction occurred |
| Observation | Text | Yes | What the user did, asked, or could not do |
| Defect type | Missing value / ambiguous wording / undefined term / missing decision path / form mismatch / wrong sequence / other | Yes | Classify to spot patterns |
| Severity | Blocking / slows / cosmetic | Yes | Blocking means the task could not be completed correctly |
| Resolution | Text | Yes | The exact change made to the draft |
| Resolved in version | New draft version | Yes | The version that closed it |
Outcome
| Field | Entry |
|---|---|
| Total defects logged | <<FILL: count>> |
| Blocking defects | <<FILL: count>> (all must be resolved before approval) |
| Re-run required? | Yes / No (Yes if any blocking defect required a material revision) |
| Re-run reference | <<FILL: date of re-run or N/A>> |
| Author signature and date | <<FILL>> |
| Dry-run user signature and date | <<FILL>> |
Acceptance criteria
- The user was genuinely representative and did not write the draft.
- The user worked from the document alone, with no help from the observer.
- Every logged defect has a defect type, a severity, and a recorded resolution.
- Every blocking defect is resolved and the draft re-run if the revision was material.
- The form is signed by both the author and the dry-run user and filed with the review package.
References
21 CFR 211.100(b) (procedures followed and documented at the time of performance): a procedure that cannot be followed cannot be followed contemporaneously either. EudraLex Volume 4, GMP Chapter 4 (Documentation), on procedures being clear and unambiguous.
Confirm the current version and clause numbers before issue.
Filled specimen
Illustrative; replace with your own. Draft SOP-QC-032, “Incoming Raw Material Sample Receipt,” draft version 0.3, task performed by a receiving analyst who had not seen the draft, observed by the author.
| Step | Observation | Type | Severity | Resolution | Resolved in |
|---|---|---|---|---|---|
| 5.5 | User asked “which thermometer, and does it need to be in calibration?” | Missing value | Slows | Named the calibrated surface thermometer and its calibration requirement in the step | 0.4 |
| 5.6 | User read the temperature, then paused, unsure whether to record before or after moving the container | Missing decision path | Blocking | Split 5.6 into record-then-move; stated record at the point of measurement | 0.4 |
| 5.3 | User wrote “the log,” unclear which log | Undefined term | Slows | Named the Sample Receipt Log and its form number | 0.4 |
| Framing | User could not find the out-of-range failure path | Ambiguous wording | Blocking | Added explicit quarantine, deviation, and notify steps to 5.6 | 0.4 |
Outcome: 4 defects, 2 blocking, both resolved; material revision, so a re-run was performed on version 0.4 and completed without help. The two blocking defects, an undefined record point and a missing failure path, are exactly the kind that would otherwise have produced inconsistent records and improvised handling on the floor. The form is the proof that they were caught and closed before approval.
Common inspection findings this form prevents
- A procedure was approved and trained but operators could not actually follow it, and the resulting deviation was closed with “retrain.”
- A critical step had no defined failure path, so operators improvised when a result was out of range.
- A form referenced in the SOP did not match the steps, leaving an undocumented gap in the record.
- A load-bearing term or value was undefined, so different operators interpreted it differently.
How to adapt this form
- Set your form number and parent SOP in the header.
- Adjust the defect-type list to the categories your document system tracks, keeping “missing decision path” and “form mismatch” because they map directly to the most common deviations.
- For tasks that cannot be safely performed for real, define what a valid simulation looks like and record why simulation was used.
- File the completed form with the SOP review and approval package so the reviewer and QA can see the dry run was run and its defects closed.
- Confirm every regulation in the references against the current published version before issue.