Designing flexible data tables - an atomic approach
Tables are complex components. Honestly when I started out in design, they gave me a lot of anxiety. I mean, the data cells could have infinite combinations, different states and worst of all, the table had to be in auto-layout!
The hack, though, is getting that one “data-cell” component just right, and then using that to build your entire table. I had to figure out how to build that one “atom” so it had me covered. In essence, what we’re doing here is going outside-in.
Break the table down into either rows or columns and then break those down into individual data cells.
Creating a data-cell
This is where the real work is. Tables can hold many different types of data and each of those could demand a slightly different layout or style.
Different contexts could demand different types of data to be displayed.
So the idea is to create a data-cell component set that:
Covers most common types of variations we may need.
Handles different states.
Scales to different sizes.
There are 2 common ways to approach this:
All variations as separate components.
Lean component with packed properties.
All variations as separate components
Personally, I don’t prefer this (though it’s not wrong). It feels bulky. Too many components cluttering my panel. But it’s very straightforward, and a lot easier for designers to pick the variant they want from the variants dropdown.
This becomes a problem when you start stacking variations:
States: default, hover, selected, disabled
Styles: colored or striped
Sizes: small, large
Your component set explodes!
Lean component with packed properties
This is my preferred approach. It’s much leaner. You can achieve a huge number of variations with a compact set of components.
The downside? You might end up with a bit of a “prop-soup” in the properties panel, potentially overwhelming you. But honestly, I feel this is a small learning curve and can be handled with a little practice.
As you can see in the image above, this setup includes both size and state variations (including the “colored” variant).
The variations are packed with the help of component properties. This helps me create a very flexible component set with just 15 variants.
Building rows or columns
Once your data-cell is ready, you can use it to build either rows or columns. Honestly, I started off building tables as columns, but I now prefer rows. Either way, it’s just a matter of preference.
Many UI kits, design systems and designers treat the “data cell” as the atomic unit of the table. They often include pre-built column components that use data-cell instances, so you can just drag in the whole column and go.
In Tenet UI, I kept only the data-cell as the main component. Rows and columns are up to you, which made things more flexible and customizable. This was actually a piece of feedback I got from teammates (at work). They liked having that level of control.
Example table 1
Example table 2
Closing thoughts
Tables can feel overwhelming, but its about cracking the logic behind building a single, robust data-cell. So, focus on that atomic unit. Build it well, and your tables will practically build themselves.