Overview
Designers kept detaching the Carbon Data Table. I shipped a Figma plugin that takes four ways in and hands back a real, un-detached Carbon component. Live internally: 200+ IBM designers. Constraint: it only works inside IBM's Figma seats — the official library keys don't travel.
I wrote about the whole thing on Medium: I built a Figma plugin because the Carbon Data Table workflow was broken.
The problem, the workflow nobody liked
The Carbon Data Table is one of the most-used components in the system, and almost nobody used it the way it was meant to be used. The cycle was the same everywhere, from designers on week one to design leads who'd been doing it for years:
- Pull in the component.
- It doesn't fit the need, so detach it from the design system.
- Hand-arrange the rows and manually fill the data.
- At handoff, the developer asks for it rebuilt with the actual component.
- Redo the whole thing before it can ship.
Every step after the detach is rework. The component was technically fine, the workflow around it was broken, and it was broken for everyone.
The insight
Two things pointed at the same principle. A Segway e-bike uses gyroscope sensors to read the terrain and adjust the motor so the rider barely notices the hill. And Notion 3.0's framing, Ivan Zhao's split between busy work and creative work, with the routine parts automated away.
Take the least possible input from the designer, and do the heavy lifting behind the scenes.
Arranging cells and matching variants is busy work. Deciding what the table should say is the creative work. The plugin's job was to erase the first so you're left with the second, and to never, ever detach the component to do it.
What I built
The core move: four ways in, one clean output. However you start, you end up with an authentic Carbon component, production-ready, design-system-compliant, never detached.
| Way in | What it does |
|---|---|
| Manual grid | A visual builder, add/remove rows and columns, edit cells inline, live updates. Up to 12 columns × 12 data rows, with normalization and validation built in. |
| File import | Drop in a CSV, XLSX or JSON file (up to 50KB). Handles arrays of arrays, arrays of objects, and nested structures, with automatic header detection and smart truncation for oversized data. |
| AI generation | Describe the table in plain language and watsonx generates the data, specify the dimensions or let it default to 6 columns × 5 rows. Prompts are tuned and the JSON is parsed automatically. |
| Extract from existing | Select any Carbon Data Table already on the canvas; the plugin reads the cell values, detects the variant, pulls the pagination settings, and loads it all into the editor for quick edits, no recreation. |
And everything you'd otherwise fiddle with by hand becomes a control:
- Variants: default, checkbox select, radio select, expandable rows, batch actions. Switching is a component swap, not a rebuild.
- Sizing: XL / LG / MD / SM / XS, driving Carbon's variable modes.
- Zebra striping: none, odd, or even rows.
- Pagination: advanced (items per page, totals), simple (current page), or unbound; all text customizable.
- Toolbar toggle with auto-fill, and native theming that matches Figma's light/dark mode.
The whole point of the control surface: no detaching to start, and no rework at handoff.
How I built it
The timeline is the honest part. September 2025, concept, straight after a conference. October, a working version, tested with a small group of designers I trust to tell me it's bad. End of October, feature-complete. Then November through January, internal compliance, which took roughly twice as long as building the thing did. Mid-January 2026, published as an internally approved tool. February, presented at the department design showcase.
Everything the plugin outputs is genuine Carbon components keyed to IBM's official Figma library, so the result isn't an approximation of the design system, it is the design system. That's also the source of its one hard limitation (below).
Where it stands
Live and in daily use across IBM design, 200+ designers. The showcase response was the tell: the people nodding hardest were design leads who'd independently hit the exact same detach-and-rebuild frustration and just assumed it was the cost of doing business.
The feedback that meant the most:
"For the first time, I didn't detach the component from adding it to the canvas all the way to dev handoff."
The code lives on IBM's internal GitHub for any employee to read or extend.
What I'd do differently, and the honest limit
It only works inside IBM's Figma seats. The plugin relies on the component keys from IBM's official Carbon library; duplicate the file externally and those keys change, so the plugin can't recognise its own components. That's a limitation, not a design choice, and I'd rather name it than pretend the tool travels further than it does.
The lesson I took from it, and the one I'd repeat: if something in your daily work feels broken, don't wait for someone else to fix it. You understand the problem better than anyone who'd be assigned it. Build the tool you need.
Read the full story
I wrote this up in detail on IBM's design publication, the broken workflow, the build, and everything that shipped. For the long version, read I built a Figma plugin because the Carbon Data Table workflow was broken on Medium.