The two-row problem

The reason your prototype table has three rows is not a design decision. It is because keying forty rows into Figma manually is something nobody actually does. It takes too long, it is the wrong kind of work, and it gets rationalised away with "stakeholders understand it is not real data." That rationalisation is usually true. The problem is that by the time it matters, the components have already been reviewed, iterated on, and handed off against a table that has never had more than five rows in it.

The real cost is not what stakeholders see. It is what you see when you are making decisions.

The workflow

The plugin exists to close the gap between having dummy data and having it in Figma.

The workflow runs like this. You have a dataset, or you generate one with AI. You use AI again to format it as comma-delimited text, handling any values that contain commas with standard double-quote wrapping. You paste that text directly into the plugin's input field, point it at your table component, and run it. The plugin parses the data against your column headers, populates the text layers in each cell, and generates additional rows dynamically if the data exceeds the existing structure. A twenty-row table takes seconds. A forty-row table takes the same seconds.

The manual alternative is selecting a row, duplicating it, editing each cell individually, repeat. At twenty rows that is genuinely prohibitive in practice. At forty it simply does not happen.

AI at both ends

What makes this workflow worth writing up is that AI appears twice, not once.

The first use is the one most designers would reach for, generating and formatting the dummy data itself. Given a schema or a set of column headers, AI produces a realistic dataset and formats it as a clean CSV in a few seconds. That step used to mean finding a dataset, cleaning it, and exporting it correctly. Now it means a prompt.

The second use is the plugin itself. I built it just over a year ago, and I would not have built it without AI tooling. I used it to write the initial implementation, to work through the parsing logic, to debug. A developer on the design system team reviewed the code before deployment. The plugin has been in active use at Woolworths since, and is published on the Figma Community for anyone who wants it, alongside a template file and a walkthrough video.

The starting point was not "I want to build a plugin." It was a specific, recurring problem. We needed realistic table data in Figma, regularly, and the manual process was too slow to be worth it. AI made a solution that was previously out of reach into one that took a few focused sessions.

When this is worth doing

The honest qualification is that not every workflow problem warrants building a tool. This one did because it recurred constantly in a table-heavy application, and that frequency made the investment straightforward to justify. And AI-assisted is not maintenance-free; the plugin needed bug fixes after deployment, which required the same tools and attention as the original build. Treat this as a threshold decision, not a default.

What changed is not that the problem was new. Designers have always wanted realistic data in prototypes. What changed is that the cost of solving the problem dropped far enough to make the attempt reasonable.

The more useful question is not whether designers should build tooling. It is which problems in your specific practice have crossed that threshold in the last year or two. The manual table entry problem was one of mine. There will be others.