Document a reader case study without overstating the result

A reader case study should explain who faced which problem, what they did with your method, and what happened afterward. Keep their account distinguishable from evidence you inspected and conclusions you drew. Include relevant circumstances that could also explain the result.

You can tell a compelling story without claiming that your book or AI companion caused every improvement. Specific actions, a visible artifact, and a candid limitation often teach another reader more than an unsupported transformation headline.

The resource below is a proposed documentation template for practical nonfiction authors. Its filled example is fictional. It demonstrates how to describe evidence; it is not a customer story, a completed trial, or a result achieved with Skillfully.

Begin with a narrow question, such as whether a reader used your interview-planning method to prepare an oral-history session. Avoid starting with the title you hope to publish and collecting only details that support it.

A reader asking for useful books asks the more concrete question:

“Among such types of books in the genre, what are the books that actually helped you with something and how did it help?”

— u/error7382, asking about useful nonfiction

That question is a useful editorial test. Can your case study explain the help in enough detail that another reader understands what occurred? A statement that someone “loved the framework” describes their reaction but leaves the application unclear.

Use one attempt or a defined period. If the reader used several chapters, coaching sessions, and other tools, preserve that context instead of assigning the whole story to the companion you want to showcase.

For the fictional example, imagine a reader preparing an oral-history conversation about a community theatre. They initially have a long list of factual questions. After using a book companion, they produce a shorter session plan with prompts tied to specific episodes.

The draft and revised plan would be artifacts to inspect if this were a real case. The reader's statement that they felt better prepared would be self-report. Whether the interview yielded richer material would require further evidence; it cannot be inferred from the existence of the plan.

This table does not require every case study to prove causation. It helps you choose wording that matches the evidence you actually have.

CASE ID AND STATUS
Working title:
Real documented case / clearly labeled fictional illustration:
Author or researcher:
Period covered:

READER AND STARTING POINT
Relevant situation and prior experience:
Task they wanted to complete:
Starting artifact or baseline:
How the baseline was established:
Important constraints:

METHOD AND ACTIONS
Book chapter or principle used:
Companion version, if applicable:
What the reader actually did:
Help supplied by the author or anyone else:
Steps skipped or changed:

RESULT AND EVIDENCE
Observed or retained artifacts:
Reader-reported changes:
What did not change or did not work:
Follow-up period:
Evidence location and access permission:

INTERPRETATION
How the method may have contributed:
Other changes or plausible explanations:
What cannot be concluded:
Who this case may or may not resemble:

QUOTES AND PUBLICATION
Exact quote and original context:
Reader's factual corrections:
Identity and attribution preference:
Materials approved for publication:
Channels and purposes agreed:
Compensation or other relevant relationship:
Approval record and contact for later questions:

Keep the working evidence record separate from the public story. It may include private files or contextual details that the reader has not agreed to publish. Collect only what you need, and state how you will handle it.

In the fictional oral-history case, the reader may also have attended a local workshop or received advice from an experienced interviewer. Those factors belong in the record. Omitting them would make the companion appear to have done work that other people or experiences also contributed to.

HM Treasury's Magenta Book annex discusses assessing other influences when examining an intervention's contribution. It also distinguishes an evidenced contribution argument from definitive causal proof. The template here is a documentation aid, not a full contribution analysis.

A proportionate fictional narrative would say that the reader revised their session plan while using the companion and reported finding the prompts useful. It would also state that the case does not isolate the companion's effect from the workshop or other advice.

Do not turn a single selected success into an expected result for every reader. Explain how you selected the case and avoid implying that it represents people whose experiences you have not examined.

In a discussion about books and daily habits, one commenter reports:

“Whenever someone asks for a favor or a meeting I just say let me check my schedule first.”

— u/Adept-Bite-1306, describing a personal routine

That is a specific reported behavior. The short comment alone does not establish when it began, whether it continued, or which book or other influence caused it. A case study would need to ask those questions rather than supplying the missing links in the narrative.

Use reader quotes to convey the reader's own experience. Do not ask someone to adopt a more dramatic claim because it fits the headline. If you shorten a quote, preserve its meaning and keep the full source context in your working record.

Tell the reader what you want to publish, where it will appear, and how you intend to identify them. Sharing a draft for private feedback is not the same request as appearing in a public case study.

GOV.UK's informed-consent guidance emphasizes explaining research use and sharing arrangements and retaining a record of consent. For an author case study, make the publication request concrete: the proposed text, selected artifacts, attribution, and channels.

Give the reader a chance to correct factual mistakes and decline material they do not want shared. Keep approval attached to the version they reviewed. An attractive screenshot can still expose names or third-party information that does not belong in the story.

End with what another reader can learn: the situation in which the method was attempted, the action it supported, and the limitations of the evidence. A narrowly documented application can stand on its own.

For an AI companion, retain the instruction version so later readers can understand what the case concerns. The guide to measuring skill quality covers a different task: checking the skill's outputs. A reader case study follows the application beyond the output and should preserve that distinction.

To scope a companion around your own method, visit Skillfully and choose Book onboarding. Bring a task readers attempt and the kind of evidence you could reasonably collect. You do not need a dramatic success story to begin designing a useful, testable experience.