My first Figma plugin

While working on internal admin tools and reporting interfaces, I kept running into the same problem: mocking table data took far more time than it should — and still didn't give anyone a realistic sense of scale.

Most of the time, I was either copying and pasting the same few rows over and over, or jumping out to random name generators and manually cleaning up the data before pasting it back into Figma. It was slow, inconsistent, and didn't help stakeholders understand how dense or complex the data actually was.

More importantly, it hid real UI problems — truncation, column compression, empty states, and accessibility edge cases rarely showed up in design reviews because the mock data was too clean and too repetitive.

I found myself spending 15–30 minutes just preparing believable table content for a single screen.

So I built a plugin to remove that friction entirely.

The problem

When table data is unrealistic:

• Designers can't feel how dense the UI really is
• Stakeholders can't tell how large or complex the data is
• Engineers can't estimate behaviour or edge cases properly

Most design reviews end up happening on "happy-path" mocks that don't reflect what the product will actually look like once real data flows through it.

What I built

FillKit is a Figma plugin that lets you populate table columns with realistic, structured, varied data in seconds.

You select a column and choose a data type.

FillKit handles the rest.

It supports:

• Names
• Dates
• Status values
• Locations

This makes it possible to turn a table mock into something that behaves much closer to a real system — without leaving Figma or manually cleaning data.

I built the first working version over a weekend using Cursor, focusing on speed, simplicity, and consistency.

The outcome

After sharing FillKit internally, two designers reached out almost immediately to say how useful it was for their day-to-day work. It quickly became something I reached for whenever I needed to mock tables — and I stopped using external random data tools altogether.

Instead of spending time jumping between generators, cleaning data, and duplicating rows, I could focus on testing real interface behaviour:

• Truncation and wrapping
• Empty states
• Dense and sparse data scenarios

Mocking tables became faster, more realistic, and more useful for reviews. Designers could explore different states and layouts without worrying about data accuracy, and stakeholders could finally get a clearer sense of scale and complexity.

Why building this matters

Being able to explore real-world density and edge cases early makes a huge difference to design quality.

Without believable data, teams tend to lock in layouts too early and only discover issues during build — when changes are more expensive and harder to make.

FillKit makes it easier to explore, test, and iterate on complex UIs before they reach development.