Ask about the difficulty the reader just encountered
When a reader gets stuck applying your method, offer a short way to report the specific difficulty while the relevant instruction is still visible. Ask what they were trying to do, what stopped them, and what they expected instead. Make reporting optional and let them continue the exercise without submitting anything.
That gives an author a more concrete starting point than a general satisfaction score. It does not automatically reveal the cause of the problem, and it should not turn every pause into an interruption.
Design the feedback request around one decision you want to improve. If your question is whether readers can select the audience for a short talk, gather evidence about that step. Do not attach an unrelated questionnaire about pricing, future features, and willingness to recommend your work.
The worked example here is fictional. It describes a proposed feedback flow for a companion to a book about preparing short presentations. It does not claim that Skillfully already implements this flow, that any reader used it, or that the example report was submitted.
Choose a moment with a reason to ask
A reader's explicit statement that they are stuck is a clearer signal than elapsed time alone. They may pause because they are thinking, answering a call, or doing the exercise on paper. A long silence does not establish confusion.
Useful candidate moments include a reader saying the instruction does not fit, rejecting an output because it answers the wrong question, or choosing to stop at a particular step. A completed exercise can also support a short reflection, but that is a different moment from a failed attempt.
For the presentation companion, suppose the current step asks the reader to name one audience question their talk will answer. The reader replies:
I cannot choose one question. Half the room already knows the project and the other half has never heard of it.
The companion should first acknowledge the actual task problem. It could offer help adapting the step, then a separate option to leave feedback about the instruction. Do not make the reader explain the same difficulty twice merely to satisfy your research process.
Keep the task and the report distinct
A proposed response might be:
You have a mixed audience, and the instruction assumed a shared starting point. We can work on that now. If you want to help improve this step, I can also prepare a short feedback note for you to review. You can skip that and continue.
This response describes the assumption tentatively enough to be corrected. It should not decide that the book is wrong before investigating. The reader may have overlooked an existing mixed-audience example, or the companion may have failed to show it.
The choice to report should not change the quality of help offered. If the reader skips feedback, continue addressing their presentation. If they choose to report, keep the note brief and return them to the same point afterward.
GOV.UK's guidance on contextual inquiry asks researchers to let participants defer questions when an interruption is inconvenient. A lightweight companion feedback prompt is not a full contextual-inquiry study, but the same respect for the person's ongoing task is a useful design principle.
Use three questions, with existing context filled in carefully
Here is an original prompt set for the fictional stalled step:
- What were you trying to do? “Choose the main question for a short project presentation.” Edit this if it is wrong.
- What made this step difficult? “The audience includes people with different levels of background knowledge.” What, if anything, would you change about that description?
- What did you expect the instruction to help you decide? Answer in your own words, or skip this question.
The first two draft answers come from what the reader just said. They are proposed summaries, not automatically verified facts. The third question remains open because the companion should not invent the reader's expectation.
Do not force the report into your preferred diagnosis. “Was our instruction too vague?” suggests a cause. “What made this step difficult?” leaves room for a different answer, including “I understood it, but I do not know who will attend.”
Three questions are a starting design, not an optimal number established by evidence. If one clarification captures the useful information, stop there. If a report needs a longer conversation, ask separately whether the reader wants to participate later.
Show the exact report before sharing it
The fictional reader might approve this note:
Step: Choose the audience's main question.
Task: Prepare a short presentation for a mixed group of project participants and newcomers.
Difficulty: The instruction asked for one question without helping me decide whose starting point to use.
Expected help: A way to choose a question that works for both groups, or permission to use separate questions.
Status: I have not completed the step. I want to continue with help.
The report does not need the project name, attendee list, slides, or full conversation to express this difficulty. If additional context is necessary, say why and let the reader review it.
Add the instruction version and step identifier when those are actually available. They help you find the material being discussed. Do not infer a version number from a vague memory or attach a transcript merely because the system makes that convenient.
If the reader edits “mixed group” to “I do not know the audience yet,” keep the correction. That changes the likely problem from competing audience needs to missing information.
Match the reporting promise to the actual route
Before adding “Send feedback,” verify where it goes, who can review it, what information is included, and what the reader is told about handling that information. A conversational draft and a delivered report are different states.
If your companion cannot submit a report through a working channel, provide a copyable note and say that nothing has been sent. If a real submission fails, preserve the note and accurately report the failure. Do not thank the reader as though the author has received it.
Similarly, avoid promising a personal reply or a product change unless that commitment is real. “Your report can help us investigate this step” is different from “We will fix this tomorrow.”
A reader should be able to decline sharing while retaining help with the exercise. The report is an optional contribution to improving the method's delivery, not payment for a useful answer.
Learn from feedback design without importing its claims
Practitioners report different experiences with in-product feedback. In one discussion, u/Immediate_Agency5442 described a design they inherited:
“I had to enhance a feature by another designer that initially involved a modal pop-up with happy or sad options, which was met with lack of engagement.”
Their later account describes changing its placement, while acknowledging they needed to check exact figures. This is an individual experience, not a verified response-rate benchmark. It is a reason to inspect whether your feedback request obstructs the task or leaves readers unsure what they are rating.
For an author, a thumbs-down could mean the answer was inaccurate, the task did not fit, or the reader disliked the wording. If you need to know which, offer an optional explanation tied to the step. Do not claim that the rating alone diagnoses the problem.
Treat a short report as the beginning of investigation
In another discussion, u/Minute_Decision816 described their next step after collecting feedback:
“We can then do a deeper dive to explore the issues raised.”
The commenter was describing their own website-feedback practice. Their unverified response percentage is not a target for your companion. The useful distinction is between collecting a signal and understanding it well enough to make a change.
For the fictional presentation report, the author could investigate several explanations:
| Possible explanation | Evidence to seek | Possible response if supported |
|---|---|---|
| Mixed audiences are omitted from the method | Review the relevant chapter and examples | Define the method's boundary or add a justified branch |
| The book covers this but the skill did not | Inspect the instruction and actual response | Repair the companion's routing or explanation |
| The reader does not know the audience | Confirm what information is available | Help identify the missing fact before choosing a question |
| The reader wants a different kind of talk | Clarify purpose and expected result | Explain fit or direct them to a more suitable task |
Do not immediately add all four branches to every session. Use the report to focus the investigation, then change the part the evidence supports.
Test the feedback flow as a reader experience
Try the flow with a reader who wants to report, one who wants only help, and one who changes their mind before sending. Check that each can continue from the same exercise step. Inspect whether the report contains anything the reader did not knowingly include.
Also test a mistaken summary. Can the reader correct it easily? Does the correction reach the final report? If not, your process may make the author's evidence look cleaner while making it less accurate.
Record actual observations before deciding that the prompt works. More reports are not automatically better if they are vague, repetitive, or obtained by repeatedly interrupting people. Fewer reports are not proof that the underlying difficulty disappeared.
The agent skill testing guide can help turn these paths into repeatable checks. Keep this lightweight feedback flow separate from a longer research interview or a later outcome study.
Bring one stalled step and its proposed three-question feedback note to Skillfully and choose Book onboarding. Start with the information that would help you improve the reader's next attempt.