Design a flexible Table component in Figma with slots

WHAT THIS TESTS: This question evaluates whether you understand Figma's Slot feature as an architectural tool for high-complexity design systems, specifically how to avoid the pre-Slot trap of boolean-variant bloat. The interviewer wants to see separation of concerns between content (what goes in a cell) and layout (how rows and tables behave), plus knowledge of auto layout nesting and instance management at scale.

A GOOD ANSWER COVERS: First, the Cell layer. You should describe a base Cell component with variants for different content types like plain text, avatar, or status tag. Alternatively, you can use separate atom components, but the key is keeping cell-level styling encapsulated so the row and table do not need to know what is inside each cell. Second, the Row layer. The Row component should be built around a Slot that uses horizontal auto layout with zero padding and zero margins. This Slot is where consumers place Cell instances. The Row itself owns horizontal dividers, hover state backgrounds, and zebra-striping logic because those are row-level concerns, not cell-level or table-level concerns. Third, the Table layer. The Table component uses a vertical auto layout Slot to hold Row instances. You should also mention a secondary Slot above the table body for global controls like search bars, filter chips, action buttons, or tabs so the table shell remains reusable across contexts. Fourth, the maintenance strategy. Instead of manually inserting individual Row instances into the Table Slot and tweaking each one, you componentize a configured Row instance once it contains the correct cells, column spacing, and alignment. Designers then use that componentized row inside the Table Slot, so future edits to column structure propagate instantly without detaching instances.

COMMON WRONG ANSWERS: Proposing a single Table component with dozens or hundreds of boolean variants for every combination of cell type, column count, and state. Suggesting that consumers detach instances to swap cell content, which breaks design system governance. Putting padding or spacing at the Table level instead of the Row level, which makes column alignment fragile. Using fixed widths everywhere instead of a mix of Hug and Fill to let tables adapt to content.

LIKELY FOLLOW-UPS: How would you enforce consistent column widths across rows if each row is an independent Slot? What happens when a table needs a sticky header or frozen first column? How do you handle empty states or loading skeletons without breaking the Slot structure? How does this Figma architecture map to semantic HTML and responsive behavior in code?

ONE CONCRETE EXAMPLE: Imagine a user directory table with three columns: employee name with avatar, email as plain text, and account status as a colored tag. You build one Cell component with three variants. You drop those three Cell instances into the Row Slot, set the Row to horizontal auto layout with zero padding, and add a bottom divider line. You then turn that configured row into its own component. Inside the Table component, you place three instances of that row component into the vertical body Slot and set the top Slot to hold a search input and an Add User button. When the product team later needs to add a fourth column, you update the componentized row once and all three instances in the table update automatically.

Source: bitovi.com