Lythe

Findings & reports

Reading simulation output, severity, and suggested fixes.

A finding is a specific, located observation from a run. Findings are the product's actual output, everything else exists to make them trustworthy.

Anatomy of a finding#

A well-formed finding names three things:

  1. Where: the specific screen or step.
  2. What happened: the observed behavior, not a judgment.
  3. The suggested fix: a concrete change.

For example:

Finding:  Unlabeled left nav icons cause hesitation
Detail:   Navigation icons in the left sidebar lack text labels, causing
          users to hover over each icon to discover its purpose before
          navigating.
Fix:      Add text labels, or a persistent expanded state for first-run users.

Compare that to "the navigation is confusing," which is not actionable.

Triaging#

Sort findings by two questions, in this order:

  1. Does it block the goal? A persona that could not complete the task outranks one that found the experience unpolished.
  2. How many personas hit it? Friction that shows up across contrasting personas is structural. Friction one persona hit is often about that persona's lens, which still matters, especially for accessibility.

Findings that block completion for the accessibility persona should be treated as blocking, not cosmetic, they lock people out rather than annoying them.

Reports#

Findings roll up into a report covering what was tested, which personas ran, what they were trying to do, and what got in the way. Reports are meant to be handed to design or engineering directly.

Filing findings as tickets#

Any finding can become a ticket in Jira or Linear, filed straight from Slack or Teams. The ticket carries the finding's location, the observed behavior, and the suggested fix, so whoever picks it up has the context without opening Fraser. A human still reviews and ships the change, Fraser files and suggests, it does not merge or deploy on its own. See Slack, Teams & tickets.

What findings are not#

Findings are synthetic. They are strong evidence that something is confusing and weaker evidence about how many real users would churn over it. Use them to prioritize what to look at and fix, not to close debates about market size.

Don't present findings as real user interviews, verified vulnerability reports, or statistically valid research unless you've independently validated them. See Authorization & limits.

Was this page helpful?