Disclosure: I work on FigCanvas. The manifest below is a suggested workflow, not a report of a measured experiment or a built-in FigCanvas feature.

A research figure is often assembled from several sources: a plot exported by a script, a workflow diagram, a schematic, and a caption in a separate document. File names such as figure_final_v4_revised.png do little to explain how those pieces fit together.

A small manifest can make that relationship explicit. It is a text file kept next to the figure sources. Its job is to identify the inputs and decisions behind one export, so a later revision does not depend on someone's memory.

Start with a panel map

For each panel, record its letter, purpose, source file, and the condition or analysis version it represents. Use stable paths within the project. Avoid putting confidential data or credentials into a public repository; a local reference is enough when the underlying input cannot be shared.

Here is a fictional example:

{
  "figure_id": "figure_03",
  "revision": "r02",
  "panels": [
    {
      "label": "A",
      "purpose": "Explain the processing workflow",
      "source": "diagrams/workflow.svg",
      "review_status": "checked"
    },
    {
      "label": "B",
      "purpose": "Compare the two example conditions",
      "source": "plots/comparison.svg",
      "analysis_ref": "analysis/comparison_v2.py",
      "review_status": "needs_caption_check"
    }
  ],
  "caption": "captions/figure_03.md",
  "export": "exports/figure_03_r02.png"
}

The schema is deliberately small. It names the material needed for review without trying to replace a laboratory's data-management system. A manifest is also a record of intended provenance, not proof that the referenced analysis was executed correctly.

Record meaning as well as file paths

Add a short note describing shared conventions. For example: circles denote measured samples, dashed arrows denote proposed relationships, and a particular label always refers to the same condition.

These decisions are easy to lose when two people edit different panels. A manifest gives a reviewer somewhere to check the intended meaning before changing a color or symbol. It can also record unresolved questions instead of letting an uncertain relationship look settled in the artwork.

If a generative tool helped create a schematic, keep the relevant prompt and review notes with the sources when appropriate. A prompt alone is not a reproducibility guarantee: model behavior, settings, and subsequent manual edits can change the result. Preserve the actual editable output as well.

Make revisions explicit

When a reviewer requests a change, update the source and identify the affected panel in the manifest. Then export the complete figure again and inspect that export. Reusing an old composite after updating one source file can leave the delivered figure out of sync with the project.

For a code-driven plot, a commit identifier or a content checksum can help distinguish revisions. For a manually edited diagram, a versioned source file and a short change note may be more practical. Use the simplest method your collaborators will maintain.

Keep assembly separate from verification

FigCanvas provides a canvas for arranging scientific illustrations, charts, and flowcharts. A manifest can sit alongside that workflow and identify the sources and review decisions that matter to your project; it does not require an integration with the tool.

Before sharing a final figure, check that every panel in the manifest exists in the export, every caption reference points to the intended panel, and every unresolved review item has been addressed. The benefit is a clear handoff: another collaborator can see what changed and where to begin the next revision.

The problem is the cost. Turning a methods paragraph into a clean figure usually means an afternoon in a vector editor, and then re-doing half of it when a co-author reorders two steps.

The two-pass habit that helped me

Pass one: describe, don't draw. I write the illustration out as plain relationships first:

• sample collected, then lysed
• lysate split into two fractions
• fraction A goes to sequencing, fraction B to mass spec
• both results feed one integrated analysis

If I can't state it cleanly in text, the figure isn't ready — and that's a clarity problem in the science, not the drawing.

Pass two: generate, then refine. I hand that description to an AI illustration for scientific papers and let it lay out a first draft. The repetitive geometry — boxes, arrows, even spacing — is done before I start, so my time goes into labels, emphasis, and what to leave out.

What I still do by hand

• Decide what not to show. Every extra arrow costs the reader attention.
• Keep arrow meaning consistent across panels.
• Export vector, so a reviewer's zoom doesn't expose a blurry mess.

None of this is automatic, and anyone selling one-click publication figures is overselling. But shifting the source of truth from a fragile vector file to a text description means revisions are quick edits, not full rebuilds — and that alone took figures off my list of dreaded final steps.

For a while I kept fixing this by hand: cycle through the palette picker, eyeball the contrast, send the figure to a friend who has deuteranopia, redo. It worked. It also ate hours per figure, and the colors drifted between panels because I wasn't being systematic.

This is what I do now, roughly in order of how often I reach for each thing.

Start from a colorblind-safe palette, not from "what looks nice"

The single highest-leverage rule I've found: pick the palette before I make the figure, not after. And the default I reach for first is Okabe-Ito (the 8-color qualitative palette designed in 2008 specifically for color-vision deficiency). It's boring. That's the point — it survives the three things that wreck most figures:

• printed in grayscale by a reviewer who hates PDFs
• viewed on a cheap laptop screen
• read by someone with red-green color blindness

For continuous data I default to viridis or one of its cousins (magma, cividis). Both are perceptually uniform, both stay legible in grayscale, and both have stopped surprising me — which is exactly what I want from a default.

"Journal style" usually means a specific limited palette

Nature, Cell, and Science don't formally publish color guides, but if you scrape figures from accepted papers in each, patterns appear fast. Nature tends toward warm earth tones plus desaturated blues. Cell leans cooler with strong accent reds. Science is the loosest but their methods figures often use a tight 3-4 color set with one bright highlight.

This matters less than the colorblind question, but it matters for first impressions on a senior reviewer who has spent thirty years skimming figures in one journal's house style. Matching the visual vocabulary is a cheap signal that the paper belongs there.

The workflow change that actually saved time

I used to copy hex codes around in a notes file. Then I'd forget which palette I used in panel A by the time I was building panel D. Now I just generate the palette once for a figure set and apply it uniformly.

A while back I built a small piece of this into a tool we ship at FigCanvas — a publication-ready scientific figures color generator that lets you pick from Okabe-Ito, viridis, and Nature/Science-style sets, preview the palette directly on a sample chart, and apply it to whatever figure you're editing. Nothing fancy — it just removes the "did I use the same blue in panel C?" question. Most of the value, honestly, is the previews on actual chart shapes (bar, scatter, heatmap, volcano) instead of just swatches floating in space, because palettes that look fine as squares often collapse the moment a small scatter point picks them up.

A short checklist before I export anything

I run through five things now:

1. Did I pick the palette before drawing the figure?
2. Is the palette colorblind-safe (Okabe-Ito or viridis)?
3. Does it survive printed in grayscale? (one screenshot, desaturate, look)
4. Do I have at most 5-6 categories, and is the most important one the most saturated?
5. Is the same color used for the same variable across every panel of the figure set?

That last one is the one I still forget when I'm rushing for a deadline. But every "we redid this figure twice" story I have ends at one of these five.

What I'm not doing anymore

I'm not picking colors by eye. I'm not letting matplotlib's default cycle ship. I'm not improvising a new palette per panel because the data "wanted" it. The constraints are small, the time savings aren't, and the figures are notably more legible to reviewers.

Color is the part of a figure most authors over-personalize and most reviewers under-articulate complaints about. Pinning it down systematically — palette first, picked from a tested set, applied uniformly — has been one of the highest-ROI workflow changes I've made for paper figures this year.

Last week I tried something different. Instead of redrawing, I pasted my methods paragraphs into a tool, hit generate, and let it propose a first-draft flowchart. The output wasn't perfect — it had to be tightened, two boxes merged, one arrow rerouted — but the structural skeleton was right. About 60% of the work was done before I touched anything.

A few things I noticed that changed how I think about this step.

The bottleneck is parsing, not drawing

When I write a flowchart from scratch, 80% of the time is spent re-reading my own methods paragraph trying to remember the branching logic. The drawing is fast. So the right tool isn't a better canvas — it's something that extracts the structure from text first, then hands you something to refine.

Editable output matters more than pretty output

I have no use for a beautiful PNG I can't change. The moment my supervisor asks me to swap two steps or relabel a node, I need vector shapes I can grab. Tools that only export raster are dead weight by the time you're at v3 of a figure.

One-shot generation is a draft, not a deliverable

Anything you generate from text is a starting point. Plan to spend 10–20 minutes refining: tighten labels, kill redundant arrows, fix orientation. That's still better than starting from a blank canvas.

The publication-ready test

A figure is publication-ready when an editor can drop it into a PDF without complaint. That means four things:

• vector format (SVG, PDF) — not 72dpi PNG
• legible at single-column width
• consistent typography across all panels
• arrows and shapes that snap to a sensible grid

If your tool produces an artifact that fails any of these, you'll redo the work in Illustrator anyway. Test for these before you commit your workflow to it.

The tool I landed on for this step is a methods figure generator built for researchers. You paste the methods text, it returns an editable flowchart, and it exports clean SVG. It's still rough on long branches (anything with more than eight decision nodes gets messy), but for a CONSORT-style flow or a basic protocol diagram, the first draft is usable enough that the rest is real refinement, not redrawing from scratch.

What I haven't tested yet: how it handles multi-panel figures where the flowchart is one panel of three or four. That's next week.

If you have a methods-to-flowchart workflow that doesn't involve hand-drawing in Illustrator, I'd genuinely like to hear it.

The baseline I am benchmarking against

Before any tool changes I time-tracked a single methods figure for a small biophysics paper:

• 18 min sketching on paper
• 35 min in Illustrator (arrows, labels, grouping, hairlines)
• 22 min fixing alignment and colour after coauthor feedback
• 11 min exporting + checking 300 DPI and CMYK behaviour

That is ~90 min for one panel. A typical paper has 4–6 multi-panel figures. Easy to lose a full week.

What I tried this week

I ran the same methods figure through five tools and graded each on three axes:

The two that surprised me are the bottom two — and not for the reason you would expect.

Why text-to-image still fails for scientific figures

Image diffusion models are great for vibes, terrible for figures. I asked gpt-image-1 for "a methods schematic showing a microfluidic chip with three inlet channels feeding into a serpentine mixer, then into a detection chamber with a fluorescence probe". What I got:

• vaguely chip-shaped pixels
• three things that look like channels but two are connected wrong
• text labels that are unreadable hallucinations like "Inllt" and "Detctn Chambr"
• nothing is editable; it is one PNG

That last point kills it for academic use. Reviewers ask for changes. If your figure is a raster you cannot re-label, you have to redraw.

What worked for me

The thing that actually saved time was treating figure generation as a vector composition problem, not an image problem. The tool I linked above takes a prose description and emits structured SVG where each domain element (channel, inlet, label, scalebar) is a real grouped object you can edit afterwards. Same prompt as above, output was a clean 4-component schematic in ~9 minutes, fully editable in Illustrator or Inkscape afterwards.

This is the workflow I converged on:

1. Write the figure caption first, in prose, the way I would in the paper.
2. Feed that caption into the figure tool.
3. Open the SVG in Illustrator only to nudge layout and fix the parts where the model misunderstood domain conventions.
4. Export at 300 DPI.

Step 3 is still ~20 min of manual work but the starting point is the difference. Going from blank canvas to "almost right schematic with editable components" in under 10 minutes is a structural change to my paper workflow.

What I would not use it for

• Photorealistic biology illustrations — BioRender is still better for tissue-level art
• Network/graph layouts with thousands of nodes — Gephi or Cytoscape territory
• Anything where domain-specific notation matters (e.g. circuit schematics — KiCad, music notation — Lilypond)

What I am tracking next week

I want to see whether the same approach holds for two harder cases:

• Multi-panel figures with shared legends across 3+ subplots (a/b/c style)
• Methods schematics with quantitative inputs, like dose-response curves embedded inside a schematic

If either of those holds, I think a non-trivial chunk of methods-section figure work is just... gone. Will report back.

If you have a figure workflow that already works for you, I would love to hear it. Especially: how do you handle round 2 of reviewer feedback when the senior author wants to "just move the arrow"?