> ## Documentation Index
> Fetch the complete documentation index at: https://docs.myresearchlab.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Piloting

> Test a draft measure on a handful of colleagues before you commit to a full sample.

A **pilot** is a small, fast run to check that a new measure or task actually works — that the wording is clear, the items behave, and nothing is confusing — *before* you spend a real sample on it. The loop is simple: draft, share with a few people, read what they say, tighten, repeat.

The quickest start is the **Pilot a new measure** starter template on [Explore](https://myresearchlab.app/explore).

## How the starter is built

The pilot starter is a short, single-arm study (no random-assignment conditions — everyone takes the same thing):

* A brief **introduction** screen.
* A **"Draft scale" screen group** with **four 7-point Likert items** and **one continuous-scale (VAS) item**, all on one screen, with placeholder wording you replace with your own statements.
* An **open-text feedback** question — *"What, if anything, was confusing about these questions? How would you reword them?"* — which is the real point of a pilot.
* A thank-you screen.

<Note>
  The pilot starter has **no conditions** — it runs as a single arm. You're testing the instrument itself, not comparing groups. (If you do want to compare two versions of a measure, that's an [A/B test](/methodology/ab-testing).)
</Note>

## The pilot loop

<Steps>
  <Step title="Draft your items">
    Replace the placeholder Likert and VAS items with your own statements. Keep it short — a pilot is about catching problems, not collecting findings.
  </Step>

  <Step title="Publish a runnable version">
    [**Publish**](/getting-started/your-first-study) freezes a runnable version without an OSF push — exactly right for an exploratory pilot. (Save preregistration for the real study.)
  </Step>

  <Step title="Share the link with a few people">
    Open recruitment on the **Run** stage to activate the participant link, then send it to a handful of colleagues or friends. No Prolific or recruitment service needed for a pilot of this size.
  </Step>

  <Step title="Watch responses land">
    Responses appear on the study **Dashboard** as people finish. Read the open-text feedback closely — it tells you which items were ambiguous.
  </Step>

  <Step title="Tighten and re-run">
    Edit the Draft to fix the wording, publish a new version, and share again. Iterate until the measure reads cleanly.
  </Step>
</Steps>

## Why pilot before you preregister

Preregistration freezes your plan — including your measures. Piloting first means the items you lock in are ones you've already seen behave on real people, so your [preregistered](/methodology/preregistration) study isn't the first time anyone has read your questions.

<Tip>
  A pilot run is also a good moment to sanity-check timing, mobile layout (use **Live preview**'s device frames), and that required-answer validation behaves the way you expect.
</Tip>

## From pilot to full study

When the measure is solid, you don't start over — keep building on the same study: add your manipulation or [conditions](/builder/conditions), expand the sample plan, [preregister](/methodology/preregistration), and recruit a full sample on [Prolific](/integrations/prolific). Your pilot version stays in the study's history.