Start with the attempt, not a verdict on the reader
When someone says your advice did not work, reconstruct the attempt before changing your framework or explaining it again. Establish what they wanted, what they understood, what they actually did, and what happened. Then investigate which part of the chain could explain the gap.
A clear instruction can describe a weak method. A useful method can be explained badly. A correctly understood step can also depend on conditions the reader does not control. These possibilities call for different responses.
An author AI skill can help gather the details, but it should not automatically classify every disappointing result as user error. The author still needs evidence before deciding what to revise.
This article provides a proposed diagnostic worksheet. Its worked example is fictional, and its categories are prompts for investigation, not a validated assessment or a record of reader testing.
Ask what “didn't work” means this time
Imagine a book teaches readers to protect a defined block of time for one meaningful task. A museum volunteer tries the method while staffing a public information desk. They plan to catalogue a small collection for an hour and finish only three entries.
Their report is: “I followed the method, but I didn't finish.”
That sentence leaves several questions open. How many entries did they expect to complete? What counts as a complete entry? Did they have an uninterrupted hour? Was answering visitors part of their assigned responsibility? Had they catalogued a similar collection before?
Ask for the smallest useful reconstruction:
What were you trying to finish? Which instruction did you follow? What did you do? What happened instead? What changed during the attempt?
The proposed prompt does not require an entire chat history, identifying details about visitors, or a justification of the reader's motivation. It needs enough context to examine the failed attempt.
Separate five questions before choosing a fix
| Question | Evidence to seek | What a plausible fix would address |
|---|---|---|
| Did the reader understand the step? | Their explanation in their own words | Wording, examples, or an undefined term |
| Could they carry out the intended action? | What they actually did and where they stopped | Missing prerequisites, tools, or an impractical sequence |
| Did the situation fit the method? | Task type, responsibilities, and necessary conditions | Scope, a different route, or a stated exclusion |
| Did something outside the method intervene? | Changes or constraints during the attempt | Contingency instructions and realistic expectations |
| Was the method itself sufficient? | A suitable, correctly executed attempt that still missed the relevant outcome | The recommendation or its promised result |
These categories can overlap. An unclear instruction to “protect your time” might hide the method's assumption that the reader controls interruptions. Rewriting that phrase without reconsidering the assumption would leave the substantive problem intact.
Program evaluation makes a related distinction between implementation problems and weaknesses in a program's underlying theory. The University of Florida's guide to process evaluation discusses both. The worksheet here adapts that distinction for an author's investigation; completing it is not equivalent to evaluating a program.
Use the failed attempt to narrow the explanation
Suppose the fictional volunteer explains “protect the hour” accurately and sets aside the planned time. Their supervisor still requires them to answer visitors immediately. The three finished entries also take longer than anticipated because each needs a reference checked.
The evidence supports at least two live explanations: the task estimate was poor, and the work setting did not provide uninterrupted time. It does not establish that the volunteer misunderstood the instruction or lacked discipline.
A productivity commenter describes a similar distinction in their own experience:
“I tried time blocking, but tasks would regularly take longer than planned (either due to a bad estimation of the time required, or interruptions that I couldn't overlook).”
— u/esrch, discussing time blocking
That account illustrates two possible sources of difficulty. It does not show how often either occurs or whether your readers face the same conditions.
For the volunteer, the author could first revise the route selection: use protected blocks only when the reader has that control; otherwise select a task that can pause safely. The estimate also needs its own check, such as timing one representative entry before committing to a completion target. Those are proposed changes to investigate, not demonstrated solutions.
Complete a failure-triage note
Use this template for one attempt at a time:
Reader goal:
Instruction they encountered:
Their interpretation:
Action they actually took:
Observed result:
Relevant conditions or changes:
Best-supported explanation:
Other explanations still possible:
Missing evidence:
Smallest proposed change:
What a new attempt would need to show:
What this attempt cannot establish:
For the fictional case, the best-supported explanation is a mismatch between the protected-time assumption and the public desk assignment, alongside an untested workload estimate. Missing evidence includes how long a representative entry takes and whether another work period offers different conditions.
The new attempt would need to show whether an appropriately scoped task can be completed under its stated conditions. A successful attempt would still not prove the method works across all volunteer roles or collections.
Check whether the situation changed after the plan
Some failures arise because the original conditions no longer hold. A reader may understand the plan and carry it out faithfully until a new obligation makes it unsuitable.
Another commenter describes that problem:
“Priorities tend to change a lot for me on a day to day basis, so any plan I make on Monday for Friday will be quickly invalidated.”
— u/lukkes, discussing interruptions
This is one person's experience, not evidence against planning in general. It suggests a useful author question: does your method tell readers when to reconsider a plan?
If changed circumstances matter, write the trigger explicitly. For example, “If the time available or your responsibilities change, reassess the task before preserving the original target.” Then check whether readers can recognize that trigger in a concrete case.
Change the part the evidence points to
If the reader misunderstood a term, test clearer wording against the same decision. If the situation falls outside the method, state the boundary and offer an appropriate next step. If a suitable, correctly executed attempt still fails, investigate the method and its promise rather than repeatedly adding explanations.
Keep the original report alongside the proposed revision. Otherwise, it becomes easy to treat a polished new instruction as proof that the problem is solved. A skill test can check whether the revised guidance follows your intended rules; actual reader use is a separate source of evidence.
If you want help turning this diagnostic process into a companion for your book, visit Skillfully and choose Book onboarding. Bring one anonymized failed attempt and the instruction it involved. That is a concrete starting point for deciding what the companion should ask and what should remain an author judgment.