Responses

Designing enterprise software means dealing with lots and lots of tables, which is exactly what I have been doing for the past three years.

After numerous semi-successful attempts to create that perfect table component that would perfectly morph itself to every existing use case and will be flexible enough to evolve for the future ones, I decided to scale back and concentrate on a single table cell component.

It worked! I’ve been using this approach for the past ~8 months and have found that I’m creating new tables faster, the component is easier to manage, and the overall work process is much more enjoyable.

Below is a short outline of pros and cons of using just one table cell as a starter for new tables. You can also grab the Figma file here and play with it yourself to decide whether it would work for you!

Small and easy to understand

A single table cell component keeps your component library small, neat, and easy to understand. In my case, I have just 13 table cell variants: one for the table header cell and two (striped/not striped) for each sub-component that goes inside the body of the cell (text, tag, input, icon, checkbox, and radio).

Scalable and easy to manage

For example, if I need to add a new sub-component, either existing or not, that can be inside the table cell (like a toggle or a link), all I have to do is to add two more variants (striped/not striped).

Enjoyable to work with

Creating tables is a much more enjoyable process now — it feels more like playing with Legos as opposed to guessing whether an existing table component would fit the specified use case or whether I should just detach it and/or create a new one from scratch.

Learning curve

Small number of variants comes at a cost of a bigger learning curve. Since I only have one table cell variant for every sub-component (with a default variant of that sub-component, as opposed to having a table cell variant for every possible sub-component variant), it may not be as evident right away how the table cell can be modified — unless you start digging into layers.

While this could be fine for smaller teams, there’s a valid argument that for larger teams, discoverability of available variants should be as obvious as possible (highly recommend this talk).

Still have to build

Instead of simply dragging a table component and filling it out with data, you still need to create rows/columns while knowing and following any guidelines or best practices that may exist within your team.

The only upside is that if at some point you want to convert rows to columns and vice versa, you can always use Columns to Rows plugin ;)

I think this covers it! Also, I would love to learn how you handle tables, so please share your insights :)