Methods Papers

Highly specialised requests are first checked for feasibility from this information. Please do not send confidential data through the public form; describe it first and agree secure transfer afterwards.

1. 01Enquiry and requirement assessment
2. 02Technical scoping and proposal
3. 03Execution
4. 04Quality review and delivery, with an agreed round of revisions

Read the full project workflow.

In depth: how the work is done

1. Positioning the method

   The introduction must show the limitation of existing methods that motivates the new one and state precisely what the method does differently. We help authors position the method among alternatives and avoid vague claims that it is better or more efficient without a defined measure.

2. Describing the algorithm or protocol

   The method description is the core. For algorithms, this means inputs, outputs, steps, parameters, complexity and stopping criteria, perhaps with pseudocode. For experimental protocols, it means reagents or materials, conditions, timings and quality checks. We review for completeness and ambiguity.

3. Validation design

   Validation uses cases with known answers, synthetic data with controlled properties and real data with independent reference. The manuscript explains why the validation cases are appropriate and what they cannot show. Sensitivity to parameters and robustness to noise are reported.

4. Fair comparison with existing methods

   Comparisons should include recognised alternatives, use the same data and metrics and give each method comparable tuning effort. We help authors design tables and figures that make comparisons transparent and avoid selective reporting.

5. Applicability and limitations

   A statement of when the method works well, when it fails and what assumptions it relies on is among the most valued parts of a methods paper. Failure cases are shown. We help authors state limits concretely.

6. Reproducibility materials

   Code, data, parameter files and step-by-step instructions let others use the method. Repositories with version tags and persistent identifiers are preferred. We help authors plan and describe these materials and prepare availability statements.

7. Computational cost and practicality

   Cost, scaling, hardware needs, training time or required expertise determine practical use. Reporting them lets readers judge adoption. Where cost is high, authors discuss ways to reduce it.

8. Naming, versioning and licensing

   Clear names, version numbers and licences make a method easier to cite and reuse. We advise on citing the method paper and on software or protocol licences, noting that legal questions belong with qualified advisers.

9. Positioning for the right audience

   Methods papers can address developers of methods or users who want to apply them. The first group wants theory, proofs and comparisons; the second wants step-by-step instructions, examples and guidance on choosing parameters. The paper should say who it is for and structure content accordingly. We help authors decide on emphasis and, where both audiences matter, separate technical detail into appendices.

10. Anticipating reviewer concerns

    Reviewers of methods papers commonly ask whether the test cases were chosen to favour the method, whether tuning was fair, whether results are statistically meaningful and whether code is available. Preparing answers in advance and addressing them in the text reduces review cycles. We help authors list likely concerns and ensure each is handled in the manuscript or supplement.

11. Maintaining the method after publication

    Methods that are used get questions, bug reports and requests for extensions. A plan for responding, such as an issue tracker, a contact address and a statement of support, signals seriousness. Updates or corrections should be documented, with version numbers linked to the paper. We help authors set realistic expectations in the manuscript about the support they can offer.

Common pitfalls this service helps avoid

• Method description that cannot be implemented. Missing steps defeat the purpose.
• Weak or untuned baselines. Comparisons lose credibility.
• Overgeneralisation. State the conditions under which the method has been tested.
• No reproducibility materials. Reviewers and users expect code or protocols.

What good reporting looks like

Support for a methods paper is documented with a description-completeness review, a benchmark and comparison design summary, a limitations statement and a reproducibility package plan. Authors approve the manuscript and own the method. We do not invent validation results or comparisons and make no acceptance promise.

An illustrative scenario

Hypothetical example written for explanation. It is not a client case, a result or a testimonial.

Suppose a researcher proposes a new data-assimilation scheme for groundwater models. The draft shows improvements on one site. The revision adds synthetic tests with known truth, comparison with two standard schemes tuned equally, a sensitivity analysis and a statement that performance degrades with sparse observations. Code and a small example dataset are placed in a repository and cited in the paper.

Questions to settle before you begin

• What does my method do that existing ones do not?
• Could someone implement it from my description?
• What validation cases are used and why?
• Where does the method fail?
• What will I release for reproducibility?

Key terms

Pseudocode

A structured description of an algorithm.

Benchmark

A standard test used for comparison.

Baseline

A reference method for comparison.

Robustness

Insensitivity of performance to disturbances.

Persistent identifier

A permanent reference such as a DOI.

Working together on Specialised Scholarly Article Formats projects

Specialised article engagements begin by confirming which format suits your material, since short communications, methods, data, software, protocol and replication papers each have conventions and length limits. We ask for the results, code or datasets that the article describes, the target journal's guidelines and your deadline. Drafting follows the format's structure, and reporting checklists are applied where they exist. Statements about data and code availability reflect what you can actually share. We do not fabricate results, and we do not promise acceptance.

Few projects need a single service in isolation. These are the services most often combined with this one.

• Protocol Papers

  Support for protocol papers that describe planned studies or reviews before results exist, so that methods are transparent and public in advance.

• Software Papers

  Support for software papers that describe research software, its functionality, design, usage and validation, in the format specific journals expect.

• Statistical & Methodological Reporting Review

  Independent review of statistical methods and reporting in a manuscript to catch errors, omissions and unsupported inferences before reviewers do.

• Engineering Research Methodology

  Support for designing, justifying and documenting research methods: choosing between experimental, numerical, analytical and mixed approaches, and writing the methodology so that another researcher could repeat the work.