Read results and draft feedback
Turn a participant's difficulty into a finding you can reproduce, verify, and act on.
A study is useful when you can point to what happened, where it happened, and what to investigate next. Start with the run, then follow the participant's evidence.
Open the run
npx humanish runs
npx humanish observe --run latest --open
npx humanish review --run latest --jsonObserver shows the participant's account alongside screenshots and recorded actions. Read the final report, then inspect the moment behind each claim. When tasks have been declared, the per-task funnel helps separate reaching the goal from merely reaching the end of the session.
Use a specific run ID in place of latest when you compare studies or save a finding. latest changes after another run.
Separate a finding from a broken run
| Observation | What to investigate |
|---|---|
| Participant finishes the intended task | Check the actions and task evidence support the claim. |
| Participant abandons or reports friction | Inspect that moment in the app. This may be the study's useful finding. |
| Install, provider, or sandbox fails | Fix the study setup; the participant may never have reached the app. |
| A task was never measured | Treat it as unknown, even if the participant said they completed it. |
Synthetic participants can miss problems or report things that do not reproduce. Confirm a finding against the app before treating it as a defect. See known failure modes for when to recruit real people.
For a worked example, read the paired Save-button study: all 12 attempts saved the task, even though half used an app with a broken Save button. The comparison also exposed false feedback candidates in Humanish itself.
For a finding that led to an app change, read the TodoMVC keyboard repair: two uninterrupted keyboard sessions were blocked before a local Edit patch, and two completed after it. One provider interruption per version remains in the study counts.
Verify before sharing
npx humanish verify --run latest --jsonVerification checks the bundle's evidence and automated public-safety gates. It is not a usability score or certification that a finding is true.
shareSafety.status | Meaning |
|---|---|
share_ready | Eligible for public feedback drafts after review. |
local_only | Valid local evidence that should not be shared as-is. Raw screenshots are one reason. |
blocked | The bundle failed verification or a public-safety gate. |
Full-fidelity screenshots are local-only by default. The automated scan catches secret and local-path shapes; it does not certify that names, personal information, or sensitive content are absent from text or pixels. Use synthetic data and review what you share. Privacy details.
Draft an issue
For a share_ready run:
npx humanish feedback draft --run latest
npx humanish feedback verify --run latest
npx humanish feedback issue --run latest --repo your-org/your-app --format markdownThese commands generate and check a draft. They do not publish it or call GitHub to create an issue. Read the rendered Markdown, reproduce the finding, and edit it before posting.
If verification says local_only or blocked, public feedback generation refuses the bundle. You can still inspect local evidence in Observer. Do not change a stored grade to force it through.
Export or compare evidence
npx humanish export --run latest
npx humanish stats --jsonexport writes a self-contained Observer HTML file with its screenshots. It requires share_ready; --local-only permits a watermarked local export, which still needs review before sharing.
stats summarizes outcomes, duration, and estimated costs. Unknown cost is reported as unknown. Use --lab your-app to focus on one lab and --since to select a period; the CLI reference lists accepted flags.
Keep original run bundles so a later comparison can return to the same screenshots, actions, and app revision. A before/after claim is stronger when the same task succeeds for multiple participants after the change.