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.
Top comments (1)
I'd surface ambiguous relationships one at a time, right on the review step, rather than asking a follow-up question before generation. A question up front makes people stop and think in the abstract, while a flagged line like "arrow direction unclear between receptor and kinase" lets them fix it in context in a couple of seconds.
The omissions point is the harder one, because a tidy list hides what's missing. Something as simple as highlighting the phrases from the original description that didn't map to any object or label could do a lot there. Repeated object names would be my first edge case too. Do you merge them into one object today, or keep them separate and let the reviewer decide?