Posted by meetpateltech 6 days ago
Reusable components. Shared styles. Auto layout. Variants. Design tokens. So many useful plugins! Interactive prototypes. Dev mode handoff. Versioned libraries. A single source of truth keeping designers, engineers, and PMs speaking the same language.
It's fucking bliss when you use it right. And best of all, anyone on the team can build with the legos the designers gave us!
Teams finally started treating the design system like infrastructure instead of decoration.
Then Figma Make showed up.
It generates pages that ignore your components, skip your tokens, and treat every screen like a fresh snowflake. Looks fine in the mockup. Lands like a brick on the dev team. Now every page is bespoke and every handoff is a rebuild. Fucking sucks.
We had it all figured out, then we fucked it up.
AI was supposed to accelerate momentum. But it just so completely lacks maturity. AI Tools are dragging teams back to 2010, when every page was a Photoshop file (with way too many layers and shitty names for them) and none of the designers can agree on what radius to assign to their buttons.
Good design systems are a discipline. If your AI tool doesn't respect the library, it's not a designer. It's an intern with a Molotov cocktail waiting to destroy your productivity.
I haven't used Claude Design yet, I'll try it, but I LOVE Figma, and I hate Figma Make. I don't have high hopes for Claude here.
Start with asking it to get up to speed on your design system, or build you a design system from your brand guidelines... and it does a pretty good job.
It also does a surprisingly good job of using some of the more advanced Figma tools that a lot of human designers struggle with...
3 days in, I've been really impressed.
Really hope Anthropic didn't notice my ingenious work and quickly copy it.
> do you see our current html
Hi-fi design Interactive prototype html
> do you see our current html
Hi-fi design Interactive prototype html
● Claude Yes — I can see your html/ folder. It has 7 files:
files-list.html math-result.html rows-view.html table-view.html text-editor-doc-view.html trending-topics.html unique-result.html Want me to open them up and take a look at what's in there? And what would you like to do — polish them, turn them into an interactive prototype, build something new on top, or something else?
> yeah in table view i'm thinking about how to deal with cells that may be big. i guess we want to do something different than excel or sheets in that auto expand rows with cells that contain big values. we can show like the first -- what does twitter show, 280? so we can show 280 chars and then [...]
● Let me take a look at the current table view to understand what we're working with.
Got it — I see the current table view. Right now every cell is clamped to max-width:220px with white-space:nowrap and text-overflow:ellipsis, so long values just get cut off at whatever ~30 chars fits the column. You're thinking about the opposite end: what if a cell genuinely holds 2,000 chars of text? Neither pure clip nor Excel-style row expansion is quite right.
Before I start sketching, a few quick questions so I don't guess wrong:
> Questions answered: - truncation_threshold: ~280 chars (new tweet) - expansion_ux: nothing right now -- it's not interactive - row_height_policy: Grow freely like Notion/Airtable - content_types: Not sure yet - indicator_style: [...] at the end of the text - newlines: Render them (row grows) - copy_affordance: no interaction right now - column_width: Fixed width, all columns equal - variation_count: 2 variations - aesthetic_direction: Same bones, but let you push it a bit
● Got it — so: non-interactive, rows can grow freely, 280-char cap with [...], newlines render, same bones but push it a bit, 2 variations. Let me sketch this out.
Set up variations file with two table treatments V1: Notion/Airtable-style free-grow with [...] cap V2: pushed aesthetic variant Wire both to the same sample data w/ long cells Let me peek at a couple of the sibling files so the variations stay in-family with the rest of the widget set.
Good — now I have the visual family. The shared vocabulary across widgets:
#f5f5f3 page, #fff card, #d0d0cc borders, #f0f0ec headers System font, 12–14px Subtle alternating row tints, no drop shadows, flat corners Color used sparingly; #666 for secondary text My plan for the two variations (side-by-side in a canvas so you can compare on the same rows):
V1 — "Notion-ish, stay in family"
Keep current palette, borders, zebra striping Rows grow vertically as needed; white-space: pre-wrap so newlines render Cap each cell at 280 chars; if longer, slice to 280 + […] inline Same fixed column widths, everything else identical V2 — "Same bones, pushed"
Tightens the grid (hairline borders instead of panels, more whitespace, denser typography) Column rail with sticky row numbers Soft fade on the bottom of ultra-tall cells instead of mid-text […] when content is really long (hybrid: char cap + visual) Monospaced tabular digits for row numbers; type column ⌾ / ▤ markers subtly hinting content type; column width slightly wider for breathing room Let me build it.
Now let me build the two variations. I'll set up realistic sample data with a mix of short values, tweet-length values, long-long values, and ones with newlines, so the behaviors are visible.
Now the two table components.
Clean. Two variations on the canvas, both rendering the same 7 rows so you can compare directly:
V1 — in-family. Your current widget, with white-space: pre-wrap so rows grow, newlines render, and a soft grey […] appended when a cell goes past 280 chars. Row 3's summary (double-long prose) and row 4's URL show the cap. V2 — same bones, pushed. Hairline borders instead of filled header panels, monospaced tabular row gutter, column letters as uppercased small-caps above the header names row, tighter typographic rhythm, cells > 280 → […] legend in the footer. Row 7 shows how newlines render naturally. Both slice at the nearest word boundary when one is within ~40 chars of the 280 cap, otherwise hard-cut — so […] never lands mid-word.
A couple of things worth calling out, not changed:
280 is pretty generous when a row has multiple long cells side-by-side — row 3 is ~2 cells × 280 = a very tall row. If that ends up being painful in real usage, dropping to ~180 or adding a per-row max-height with fade might be worth a follow-up. Neither variation is interactive per your answer; there's no click-to-expand, hover, or copy. Easy to bolt on later. Fork verifier agent Both variations are live on the canvas. Let me know which direction feels right and I'll fold it back into html/table-view.html." -----
It's basically similar to their Artifacts system in a harness I guess