Tests

Test types

Findry supports four test types. Each one maps to a different stage of the evidence lifecycle — choose based on where your hypothesis sits, not what's easiest to run:

1. User interview — A moderated or unmoderated conversation with a user. Useful for uncovering Jobs to Be Done, friction points, and mental models. Best early in a hypothesis lifecycle when the belief is unformed.
2. Survey — A structured questionnaire sent to a segment of users. Useful for quantifying what interviews surface. Good for validating frequency and severity of a problem.
3. Prototype test — A usability session with a prototype or mockup. Useful for validating solution direction before building. Findry links these to Figma files if your integration is connected.
4. A/B experiment — A live split test in production. The highest-signal test type — it measures behavior, not intent. Requires your analytics integration (PostHog, Amplitude, or Mixpanel) to be connected for metric pull.

Writing a test plan

Before you run a test, write the plan. Findry's test creation form has three key fields:

• Objective — What question does this test answer? One sentence: "Does adding a progress indicator to the onboarding flow increase completion rate?"
• Method — How will you test it? Include participant criteria, environment, and what you'll measure.
• Success criteria — What outcome would make you change your mind? Write the threshold before you see the results. "If completion rate increases by 10% or more with p<0.05, the hypothesis is Supported."

“The success criteria must be written before the test runs. Deciding what counts as a win after you've seen the result isn't science — it's confirmation bias with extra steps.”

Linking to a hypothesis

Every test must be linked to at least one hypothesis. Open the hypothesis and click + New test, or create a test and select the hypothesis from the link field. When a test is linked and active, the hypothesis state moves to Testing automatically. You can link a single test to multiple hypotheses if it's designed to validate more than one belief.

Recording results

After running your test, open it in Findry and fill in the Results section:

• What happened — free-text summary of what you observed
• Metrics — if it was an A/B experiment and your analytics integration is connected, Findry pulls the metric values automatically. For other test types, enter them manually.
• Participant notes — for qualitative tests, attach your notes or transcript

Conclusions and signals

The final step is writing the conclusion — one of three verdicts: Supported, Refuted, or Inconclusive.

• Supported — the evidence favors the hypothesis. The hypothesis state moves toward Supported (if all its tests conclude Supported).
• Refuted — the evidence goes against the hypothesis. This is valuable. A refuted hypothesis is not a failure — it's a fact you now know.
• Inconclusive — the test didn't produce clear signal. Common reasons: too small a sample, bad instrumentation, confounding variables. Treat this as a reason to redesign the test, not as evidence either way.

After saving the conclusion, Findry prompts you to generate signals from what you learned. These auto-linked signals become evidence in the record — searchable, linkable, part of the chain.