I built a scientific figure generator around a review checkpoint

I’m building FigureDraft, a web tool that turns research descriptions into scientific figure drafts.

The visible workflow is short: describe the research, review objects, labels, and relationships, generate the figure, and download a PNG.

The interesting engineering question is where to put the boundary between interpretation and rendering.

Treat interpretation as something users can inspect

A direct prompt-to-image flow hides a lot inside one action. If the result is wrong, the user has to work backward from pixels to figure out whether the problem was the description, the interpretation, or the rendering.

FigureDraft puts a review checkpoint in that flow.

From an application-design perspective, that means thinking about two different things: the intended contents of the diagram and the image that represents them. Those shouldn’t be treated as interchangeable.

Objects, labels, and relationships provide a useful vocabulary for that distinction.

The architecture matters more than a framework name

I’m keeping this post focused on the workflow rather than publishing an unverified framework or model inventory. The implementation stack isn’t documented here, so I won’t dress this up as a reproducible backend tutorial.

At the application level, though, the boundaries are worth discussing: research input, a reviewable interpretation, figure generation, and PNG delivery.

Each boundary creates a question the interface needs to answer. What is the user reviewing? What information will generation use? What should happen if the description leaves a relationship ambiguous?

These questions shape the product regardless of which frontend framework or model provider sits underneath it.

What I would test beyond the happy path

For a workflow like this, a successful image download isn’t enough.

I’d test descriptions with repeated object names, missing relationships, long labels, and conflicting directions. I’d also check whether the review screen makes omissions noticeable rather than simply making the interpretation look tidy.

Those are product-level tests as much as technical ones.

Looking for developer feedback

I’m especially interested in how other developers would represent uncertainty between interpretation and rendering.

Would you surface ambiguous relationships individually? Ask the user a follow-up question? Keep the first version intentionally minimal?

Try FigureDraft with a research description and tell me where the review boundary helps—or where it gets in your way.