A study plan is not a calendar. It is an argument: if you gather this evidence under these conditions, the result will answer the question better than the obvious alternatives.
01
Question & success metric
02
Evidence & sample
03
Baseline / control
04
What stays constant
05
Pilot & logging
06
Stop rule & backup
Start from the evidence
Draft the kind of sentence your study should eventually support:
Compared with the vision-only baseline, the touch-assisted controller changed the object-drop rate across 120 simulated grasps under three visibility conditions.
You do not know the direction or size yet. The sentence simply exposes the comparison, outcome, cases, and conditions that the plan must define.
Now work backward:
- What raw observations produce the primary metric?
- How many independent samples, people, runs, sites, or cases are needed?
- Which repetitions measure random variability, and which are genuinely new samples?
- What comparison would make the result meaningful?
- What must remain constant?
- What metadata will explain failures later?
Ten measurements from the same object are not automatically ten independent samples. Repeated trials can estimate measurement variability; they do not necessarily expand the population your claim covers.
Choose one primary metric before results
Define the main outcome and analysis before collecting final data. Secondary measurements are useful, but choosing whichever metric looks best afterward inflates the chance of a misleading story.
Write units, calculation steps, exclusion rules, and how missing or failed trials will be handled. Preserve raw data separately from cleaned data. Use stable sample IDs rather than names when personal data is involved.
Run a pilot that is allowed to fail
A pilot tests the procedure, not the hypothesis. Use it to discover:
- sensors that saturate or drift;
- software that cannot finish within available time;
- ambiguous instructions;
- data formats that lose important information;
- samples you cannot obtain consistently;
- safety or supervision requirements you missed;
- a baseline that is unfair or impossible to reproduce.
Do not quietly mix pilot measurements into the final dataset if the procedure changed.
Define stopping and failure rules
Set a stopping condition based on sample count, time, material, or a safety/feasibility boundary—not whether the result becomes favorable. List expected failures and the response to each.
| Failure | Planned response |
|---|---|
| Sensor misses a reading | Keep the missing value; record the error code; do not invent a value. |
| Simulation crashes | Save the seed/configuration; retry once under a predefined rule. |
| Recruitment is below target | Report the smaller sample and narrow the claim; do not add unapproved groups. |
| Prototype part breaks | Record the failure mode; use the documented spare; preserve the failed part if useful. |
Maintain a backup path: an open dataset if field collection fails, a simpler baseline if the full implementation overruns, or a reduced but still meaningful operating range.
Do not label every project “human subjects” or “hazardous” automatically. Determine the actual category from current rules. Public, de-identified datasets may be treated differently from interacting with participants, but the source license, privacy terms, local policy, and competition rules still apply.
Keep a research log
For every session, record date/time, objective, version or configuration, sample IDs, raw file locations, deviations, observations, and next action. Photographs and code commits help, but they do not replace a short explanation of what happened and why.
At the end, another student should be able to reconstruct the evidence path without guessing which file or trial you preferred.
Primary sources
Go deeper
Use these first-party references to check rules, study the method further, or adapt this guide to your field.