Original Research Methods Template

Last updated October 28, 2026.

An original research methods template records what you studied, how you selected it, what you counted and where the conclusion stops. Publish that record beside the finding so another writer can inspect the evidence before quoting it. Keep exclusions and missing answers visible: neither should silently change what a percentage means.

This worksheet is for independent publishers preparing a research article, not a substitute for survey-design or statistical advice. You need a specific research question and permission to use your evidence. The small dataset below is entirely fictional teaching material, not a CiteGuild study, a real market sample or a product benchmark.

Download the editable worksheet (.md). Save the Markdown file and fill it in with any text editor. It contains the general methods record and an optional technical-benchmark addendum, with a link back to this guide. No signup is required, and there is no form to submit your research to CiteGuild. Completing the worksheet does not validate a study or promise a citation.

The workflow:

1. Define the question and counting rules.
2. Keep an inspectable record.
3. Write the method beside the finding.
4. Review and publish the bounded claim.

On this page: define the question, keep the record, work through the example, copy the methods template, adapt for a survey, document a technical benchmark, publish and correct, and questions.

1. Define the question and counting rules

Start with a decision your reader needs to make. “What does this selected set of product documentation say about export formats?” is inspectable. “Which products are best?” needs a different design, criteria and evidence. A page audit can describe documentation; it cannot establish that an export succeeds inside an account.

Write down the unit you will count. A page, a product, a company and a person are different units. Two documentation pages for one product must not accidentally become two products. Specify how you will find the records, which qualify and how you will handle duplicates. Keep the selection list or a permitted version reference so someone can understand what you left out.

Then define the observation. For an export-documentation audit, “yes” might require a public passage naming at least one export format. “No” might mean the relevant page was inspected and did not name one. A page you could not read is “unknown,” not automatically “no.” Fix those rules before seeing which result would make the strongest headline. Record later changes explicitly.

This is an editorial planning aid, not an official research standard. For formal survey and public-opinion reporting, consult AAPOR's disclosure standards, checked October 21, 2026. They cover matters such as the population, instrument, sampling, collection and analysis needed to assess a reported finding. A short methods box does not replace the disclosures appropriate to your study.

Done looks like: another person can tell what one record represents, why it belongs in the study, and which observation would count as yes, no or unknown.

2. Keep an inspectable record

For each observation, keep the evidence reference, collection date, inclusion decision, observed value and any limitation. Preserve the difference between the source saying something and your interpretation of it. If a page says “CSV export,” your observation can record that text; it cannot become “all account data exports correctly.”

When analyzing an existing public dataset, record its publisher, release or vintage, file or query, variable definitions, filters and calculation. Describe your contribution as an analysis of that source's data, not as data you originally collected. Keep the source's missing-value and uncertainty notes attached to the analysis. Public access alone is not permission to redistribute everything you downloaded.

Separate the research record from the public evidence bundle. The first may contain restricted material; the second should contain only what you can share safely. A reader may be able to reproduce an aggregate calculation from a permitted table without seeing private responses. Do not put credentials, identifying respondent details or confidential source material into a public spreadsheet to make the method look transparent.

Worked example: the same records support different sentences

Here is the complete fictional input for a documentation audit. The row labels identify invented records only. There are no real products, URLs or collected observations behind them. We use the example to check the arithmetic and wording, not to estimate a market rate.

The fictional inclusion rule is one public export-documentation page per product in a fixed selection list. “Yes” requires an explicit export-format name. An inspected page without one counts as “no.” An unreadable page remains “unknown.”

Eight candidate records become six included records after two exclusions. Of those six, five can be assessed: three yes and two no. One stays unknown. These counts reconcile: three plus two plus one equals six. The excluded records do not enter the result, and the unreadable page does not become a negative observation.

You can now write either of these sentences, provided you retain its qualification:

• Across the included set: “Three of the six included records named an export format; two did not, and one could not be inspected.”
• Among assessable records: “Three of the five assessable records named an export format, or 60%; one additional included record could not be inspected.”

The first sentence keeps all included records visible. The second uses only assessable records for its percentage and explicitly discloses the missing observation. Neither says “60% of products support export.” The study concerns documentation in a selected set, not tested features or the whole market.

Do not choose the second sentence just because its percentage is larger. Choose the report that answers the stated question, explain the counting rule and keep it consistent. If the missing page is systematically different from the readable pages, the assessable subset may be misleading. A methods note exposes that uncertainty; it does not repair it.

The arithmetic can also reveal mistakes before publication. Counting all eight candidates would ignore the eligibility rules. Counting the unknown as no would claim knowledge the audit does not have. Publishing only “60%” would hide both the small selected set and the unobserved page. This is why a chart alone is not a sufficient evidence record.

3. Copy the publisher methods template

Replace every bracketed field with what you actually did. If a field does not apply, say why rather than inventing a value. This is CiteGuild's editorial worksheet, not an AAPOR certification or a claim that the study is statistically valid.

Question and intended use: We studied [specific question] to help [reader] decide [action].

Who conducted and funded the work: [Publisher, research owner, sponsor and relevant conflicts].

Scope and selection: The unit was [person/page/product/other]. We selected [actual frame or source list] covering [period and geography, where applicable], using [inclusion, exclusion and duplicate rules].

Collection and measurement: We collected [observations or responses] on [dates, with timezone where relevant], using [instrument, source version and operational definitions].

Counts and calculation: We considered [candidate count], excluded [count and reasons], and included [count]. This finding uses [eligible observations for this question]. We calculated [formula or reproducible steps], handling missing values by [rule].

Limits and uncertainty: The result describes [actual observed group]. It does not establish [specific broader inference]. Relevant sampling, coverage, measurement and missing-data limitations are [details].

Evidence and corrections: Permitted supporting material is at [stable links]. Analysis completed [date]. Corrections and method revisions are recorded at [contact or version history].

For the fictional audit, the calculation section would say: “Eight candidates were considered; one duplicate and one out-of-category record were excluded. Six records remained. Five could be assessed, with three naming an export format. The assessable-record percentage is three divided by five, multiplied by 100: 60%. The remaining record is unknown.” That is a complete calculation, not a claim about real software.

For a real article, put the short method near the finding and link to fuller permitted supporting material. Use the writer-side source-selection checklist to check whether someone quoting your result could keep its scope intact. That guide evaluates sources; this worksheet documents how a publisher produced a finding.

Adapt the record for a reader survey

A survey needs more than replacing “records” with “respondents.” Name the recruitment channels, eligibility, collection dates, survey mode and any incentive. Preserve the exact question, response options and relevant questionnaire context. Explain weighting, if used, and keep the number answering each question separate from total completions.

For example, someone may complete a survey but skip the question behind your headline. State whether the result uses everyone eligible for that question or only those who answered, and explain missing answers. If people can select several options, say so; readers should not assume the percentages form a single-choice total.

Pew Research Center's question-writing guidance, checked October 21, 2026, explains why wording, answer choices and question order matter, and why pretesting is important. A changed questionnaire or collection mode can complicate a year-to-year comparison. Record those changes instead of treating every difference as a change in the audience.

An opt-in reader poll does not automatically describe the wider industry. Do not attach a conventional population margin of error just because a calculator accepts the response count. AAPOR's disclosure standards distinguish probability and nonprobability recruitment and require additional explanation for precision measures in nonprobability studies. Get appropriate methodological help before making those inferences.

Done looks like: the published statement identifies the actual respondent group, the question's counting base and the limits of recruitment. A large response count is not permission to omit those details.

Adapt the record for a technical benchmark

A technical case study needs a claim tied to a workload, not just a before-and-after chart. Use this branch when your article reports measured software performance. The documentation audit above records what a page says; a benchmark records what a particular setup did. Neither automatically describes production users.

Before running the comparison, define the operation, input size, concurrency, metric and success condition. Keep the baseline and changed revision identifiable. Record hardware, operating system, runtime and build settings, along with cache state and warm-up. If several things changed, disclose them rather than crediting one optimization for the whole difference.

Google Benchmark's user guide, checked October 25, 2026, distinguishes warm-up from measured execution and describes repeated runs with summary statistics. Those are separate choices: more iterations inside one run are not the same as separate repetitions. Choose and document a repetition plan appropriate to the question; there is no universal run count that makes a claim valid.

Add this record to the general methods template:

Comparison: We compared [baseline revision] with [changed revision], changing [specific factors] and keeping [controlled factors] fixed.

Workload and environment: We measured [operation, inputs and concurrency] on [hardware, OS, runtime, build and dependency versions]. The metric was [definition and unit]; setup, cache and warm-up followed [rules].

Runs and correctness: We planned [repetitions, iterations per run or stopping rule, duration and run order]. The successful-output check was [rule]. We recorded [completed runs, errors and timeouts], retaining [per-run results] and excluding [records, with reasons].

Result and calculation: The baseline was [value and unit] and the changed version was [value and unit], using [summary statistic over the stated runs]. Variation was [observed spread]; any relative change uses [formula and denominator].

Reproduction and limits: Permitted code, inputs, commands and result files are at [versioned links]. This supports [bounded finding] for [tested conditions], not [untested workloads, user outcomes or causal claims]. Restricted material and reproduction limits are [details].

Do not silently drop failed requests from a latency result or count incorrect output as useful throughput. Brendan Gregg's benchmarking checklist, checked October 25, 2026, asks whether a benchmark errors, reproduces and matters to the intended workload. His active benchmarking method also calls for observing the system during the run to understand what limits it. Report a suspected explanation as suspected unless supporting evidence establishes it.

Write the final sentence with the conditions attached: “For [workload] on [setup], [statistic] changed from [baseline] to [result] across [stated runs], with [errors and limits].” This is a fill-in sentence, not a CiteGuild performance result. A local speed difference does not establish better customer retention, search rankings or citation rates. Let the reader inspect the narrow finding without inheriting a larger promise.

4. Review and publish the bounded claim

Before publishing, ask someone to reconstruct one finding from the permitted evidence. They should recover the included count, missing observations and calculation without guessing. Also have them read the proposed headline without the methods section: does it imply a population, tested behavior or causal effect that the design never measured?

Keep findings separate from interpretation. “The inspected documentation names a format” is an observation. “This makes the product a better choice” needs additional criteria. A selected page audit does not show that adding documentation causes adoption, links or citations. If the desired headline needs stronger evidence, narrow it or change the study, not the description of the method.

Publish the finding, date, method and appropriate supporting material together. Retain a correction route and a dated account of changes. If a source changes or an error is found, explain what changed in the result. When repeating a study, preserve comparable rules or disclose the differences before presenting a trend.

Once you have a useful public article, the publisher source-readiness workflow explains how it can fit into CiteGuild's sitemap-backed article network. Membership is free and invitation-only. Eligible member articles can be discovered by writing agents, but this template does not validate a study, guarantee retrieval or promise that anyone will cite it. Publish something worth checking first.

Questions about using the template

Does completing this template validate my study?

No. A methods record makes the work inspectable. It does not establish representativeness, remove bias, prove causation or guarantee a citation. AAPOR's Transparency Initiative, checked October 21, 2026, likewise distinguishes methodological disclosure from a judgment about a method's quality or rigor.

Should an unknown observation count as no?

Not automatically. Keep unknown observations distinct, explain why they are missing, and state the counting rule beside the finding. In the fictional example, an unreadable page does not tell us whether an export format is documented.

Do I need to publish raw survey responses?

No. Publish only material you have permission to share. Describe the method and provide suitable aggregate evidence without exposing respondents or confidential records. If restrictions prevent independent reproduction, state those limits rather than describing the evidence as fully open.