Xing Lab markXing LabFudan University

Lab Guide

English中文

Research Practice

Practical standards and resources for data, writing, figures, documentation, code, shared scientific references and others.

0

Acknowledgment

This guide is inspired in part by publicly shared lab guide and resource documents from the Coley Research Group @ MIT and the Wang Bioinformatics Lab @ UC Riverside. We thank these groups for making their materials available to the broader research community.

01

Overview

Research practice covers the habits that make our scientific work clear, reusable, and trustworthy. This page gathers expectations for data, manuscripts, figures, documentation, code, responsible use of LLMs, reviewing, and shared reading resources.

The common thread is reproducibility: future you, lab members, collaborators, reviewers, and readers should be able to understand what was done, why it was done, and how conclusions were supported.

02

Data

Raw data are part of the scientific record. They should be preserved, organized, backed up, and documented even when they do not appear in a final paper.

Preserve raw data

  • Preserve ALL raw data, including exploratory runs, failed experiments, controls, samples, and files that are not used in the final publication. Do not overwrite original files.
  • Keep the original files separate from processed data, cleaned tables, exported figures, and analysis outputs.
  • If data need to be excluded from an analysis, document the reason instead of deleting the files.

Organize project data

  • Keep raw data, processed data, metadata, and analysis outputs in clearly named locations, with processing steps, key parameters, sample metadata, and quality-control decisions documented.
  • Use clear dates and names for folders and files so that progress can be reconstructed later.
  • Make sure collaborators and future lab members can understand where the important files are and which version was used for each result.

Backups

  • Back up data early and often. When possible, keep important project data in more than one place, such as an external hard drive plus lab NAS, approved institutional storage, or approved cloud storage.
  • Mac users can use Time Machine with an external drive or network storage. Windows users can use File History to back up selected folders to an external drive or network location; make sure project folders outside the default libraries are included.
  • Periodically confirm that backups can actually be restored, especially before major cleanups, computer changes, manuscript submission, or public data release.

03

Manuscripts

Start with the story

  • A manuscript outline should make the paper's logic visible before the prose is polished: what problem matters, what gap remains, what evidence we have, and why the result changes how readers should think or work.
  • Build the outline around figures and tables. Each major result should correspond to a figure, table, or clearly described analysis.

Outline components

  • Abstract: a concise 5-10 sentence summary of the whole paper, including context, gap, approach, main result, and significance. See the Abstract Guide when drafting or revising the abstract and paper narrative.
  • Introduction: a paragraph-level plan explaining the broad problem, the specific question, what has been done before, why this work is different or better, and the main contributions.
  • Results: a list of key figures and tables. Draft captions early so each figure has a clear standalone message.
  • Discussion: interpretations, important limitations, broader conclusions that are supported by the data, future improvements.
  • Methods and supporting information: experiments, controls, ablations, datasets, method details, supplementary figures, and anything needed for reproducibility but too detailed for the main text.

Drafting and revision

  • Draft early enough that revisions can improve the science, not only the wording.
  • Use comments and tracked changes as a learning process rather than a checklist to accept mechanically.
  • When sending a manuscript draft to the PI, use a clear file name with the project name, your name initials, and date, for example: ProjectName_SX_20260901.docx.

Supplementary information

  • Supplementary information is usually prepared as two files: one Word document for supplementary figures and supplementary notes (if applicable), and one Excel file for supplementary tables.
  • Nature journals usually also require a separate Excel file for source data.

Manuscript Template

Download Word template
  • Manuscript format may vary by journal; check the author guidelines when preparing the final version.

04

Figures

Minimum standard for every figure

  • Figures should look clean and professional in all contexts: lab meetings, manuscript drafts, posters, and final submissions.
  • For an internal draft, clean and professional means the audience can understand what is plotted, what is being compared, and what conclusion the figure supports without guessing.
  • At any stage, axes must have clear labels and units when applicable; legends or direct labels must explain groups, colors, symbols, and abbreviations.

Publication and submission standards

  • Avoid unnecessary chart borders, heavy gridlines, decorative effects, or color choices that are hard to distinguish. Less is more.
  • Use Arial (or Helvetica) throughout the figure, including labels, legends, annotations, and panel letters.
  • At the final printed size, most text should be 4-10 pt.
  • Use consistent font size, line width, marker size, color palette, panel labels, and chemical structure style across all panels.
  • Captions should state what is shown, the sample size, the statistical test, and exact p-values if applicable.

Figure assembly

  • Use a tool that supports vector editing, such as Adobe Illustrator, Inkscape or PowerPoint.
  • Save vector formats whenever possible, such as SVG, unless the journal requires a specific format.
  • If a vector file becomes too large or impractical (for example, with large UMAP plots), export a raster image such as PNG or JPEG at no less than 600 DPI.
  • When assembling multipanel figures, export plots at the intended final figure or poster size to avoid awkward resizing later.
  • If panels are generated separately, keep axis sizes, label positions, fonts, and line widths consistent across panels.

Chemical structures

  • Chemical structures should usually be drawn in ChemDraw, using Nature or ACS style.
  • On macOS, export ChemDraw structures as SVG files. On Windows, copying and pasting into PowerPoint should preserve vector quality.

Plots and reproducibility

  • Generate quantitative plots programmatically when possible in Python or R (I personally prefer Python when possible). Programmatic plotting matters because data may update, analyses may need to be rerun, and figures often need to be reproduced during revision. Avoid making plots manually in Excel or Prism.
  • Keep plotting code, processed data, and exported figure files together.
  • For a practical introduction to data visualization, this is a great resource: From Data to Viz.

Figure Template

Download PowerPoint template
  • Use this template as a starting point for assembling clean, consistent manuscript and presentation figures.

05

Documentation & Code

Future you, future lab members, collaborators, and reviewers should be able to understand what was done and why.

Working records

  • Everyone is expected to keep research notes for experiments and analyses, either electronically or in a handwritten notebook, with enough detail that the work can be understood and revisited later.
  • Record why important choices were made, not only what was done.
  • Use clear dates and names for files, slides, drafts, and result folders so that progress can be reconstructed later.

Code and reproducible workflows

  • Use version control for code-based projects whenever possible.
  • Organize scripts and notebooks so the main analysis path is understandable without relying on memory.
  • Include a README with the folder structure, main scripts, expected inputs and outputs, and the order in which scripts should be run.
  • Document the software environment, package versions, operating system or server, and external tools needed to rerun the work.
  • Before making code public, check carefully for private data, credentials, unpublished collaborator materials, and licensing issues.

06

Large Language Models (LLMs)

LLMs are useful research tools, and we should embrace them thoughtfully.

LLMs and AI-powered assistants can help with coding, documentation, literature triage, outlining, editing, brainstorming, data-analysis planning, presentation preparation, and learning unfamiliar tools or concepts. They are most useful when they make us faster, clearer, and more careful, not when they replace our understanding.

Responsibility and verification

  • It is your responsibility to understand every line of code that you commit. You are also responsible for every analysis and claim that you submit. Never accept LLM output without understanding it and verifying it with tests, inspection, source checks, and code review. We will use code review to help ensure this standard is met.
  • LLMs are usually strongest on common programming and writing tasks. They can be unreliable for specialized predictions, unpublished facts, or highly domain-specific scientific claims.
  • Do not outsource scientific judgment or novelty. Use these tools to accelerate execution and clarify thinking, while developing your own ideas and expertise.

Context and privacy

  • Good results require good context: provide the relevant code base, expected inputs and outputs, and clear instructions for the task.
  • Do not paste sensitive data, private manuscripts, confidential code, unpublished collaborator information, credentials, or proprietary material into cloud tools without appropriate approval.

07

Reviewing Manuscripts

  • Be kind. Write the review as if you are helping real people improve work they care about.
  • Start with the major strengths when possible, especially if the work has clear value. This helps the authors and editor understand what is worth preserving.
  • Separate technical correctness from novelty or significance. A correct paper can still have limited impact; a potentially important paper can still need stronger evidence.
  • When claims are overstated, identify the specific claim and explain what the data do and do not support.
  • For each major concern, try to propose a solution, even if it is not perfect. This is more helpful than only saying that something is wrong or missing.

08

Reading List & Key Papers

These are key papers and tools that all lab members are expected to read and become familiar with. The goal is not to memorize every detail, but to understand what each paper contributes, what each tool is used for, when it is relevant, and how it connects to our work.

Key Research and Tool Papers

Core research papers and method/tool papers that define important ideas, workflows, and resources for the lab.

Commonly Used Tool Links

Lab members should know what these resources are used for and when they are the right place to start.