Getting feedback worth having.

1.Start with a project

A project is the thing you built: a name, a URL testers can reach, a category, and a summary.

The summary is capped at 200 characters and 2 sentences. That is not us being precious about length — a tester decides whether to pick up your mission from this sentence and the mission title. Say what it does and who it is for. Skip the positioning.

The URL has to be reachable without an invite. A tester who hits a login wall marks every step blocked, which is a true report and a wasted one.

2.Decide what kind of test you need

Missions come in three kinds. Picking the right one changes who self-selects into your mission and what they look at.

Process Flow Testing

A journey end to end — sign up, checkout, reset a password.

Component Testing

Individual elements like buttons, inputs, and checkboxes.

UI Design Testing

How it reads and feels — clarity, hierarchy, polish.

3.Write the test case

The test case is the brief. It is an ordered list of steps, and each step is two things: an action the tester takes, and what should happen when they do. The action is capped at 200 characters and the expected result at 200 — if a step needs more room than that, it is two steps.

Start from one of the 12 templates if one fits. They are grouped by the three categories above and cover the flows most projects share — sign-up, password reset, checkout, form validation, first impressions, mobile layout. A template is copied onto your mission, so edit it freely afterwards.

What makes a step testable

• One action per step. “Sign up and create a project” is two steps, and when it fails you will not know which half broke.
• Say what should happen in terms the tester can see. “The session persists” is invisible; “you land back on the dashboard and your name is in the top right” is not.
• Do not write the answer you hope for. The expected result is what you believe the product does — if you are unsure, that is the most valuable step in the case.

Your wording is copied onto every report as it was at the moment the tester submitted. Editing the mission later never rewrites what a tester appears to have been asked.

4.Notes for testers are optional

There is a notes field, tucked behind a disclosure, and it is genuinely optional. It is notes — a login you want them to use, a warning that the payment step is a sandbox. It is not the brief. The test case directly below it is the brief.

If you find yourself writing the instructions in here, they belong in the steps.

5.Say where it should be tested

Three answers, and Mobile & Desktop is a real choice rather than indecision — it means you want the flow checked in both places and you will get reports from testers doing each.

• Mobile
• Desktop
• Mobile & Desktop

6.How many testers, and why five

Five people find around 85% of the usability problems in what they're testing. Past five you are mostly paying to rediscover the same issues — the finding is the Nielsen Norman Group's, and it is one of the most cited results in usability research.

The practical consequence is about mission sizing, not about a number you pick. Scope a mission to one flow that five people can cover properly. Testing something else as well? That is a second mission. Ten missions of five beats one mission of fifty.

This holds for qualitative usability testing, which is what Twnhall does. It does not hold for quantitative work — task success rates, A/B tests, load testing.

7.Reading the audit log

A report comes back as one row per step, in your order, with your wording. Each row carries a status:

Pass

It did what the builder said it would.

Fail

It ran, and did something else.

Blocked

You could not get to this step at all.

A passing step carries nothing else — what it confirms is your own expected result, already on the row. A failed step and a blocked step both carry three things: what actually happened, a one-line summary of the issue, and steps to reproduce it.

Read the blocked steps first. Blocked is not a milder failure — it means the tester could not get there at all, so everything below it in the case went untested. One blocked step early in a flow can invalidate the rest of the report.

Screenshots are attached to the report, not to individual steps. Every report has at least one.

8.Review and rate every report

A report arrives pending, and you approve it with a rating out of five. There is no sending it back: a tester files one report per mission. The rating is required — an approval without one leaves the tester nothing to build a reputation on, and reputation is the only thing Twnhall has to offer testers.

Rate the report, not the news. A careful report that says your checkout is broken is a five.