Establishing a scalable data table pattern across products
Context
Our platform is made of six different products, built at different times with different technologies. Over the years, tables quietly multiplied. Same purpose, different behaviors. Filters worked differently. Actions moved around. Accessibility was inconsistent. Performance varied depending on who built what and when.
The result was predictable. A fragmented experience for users and constant friction for designers and developers.
Tables were not broken in isolation. The pattern was.
Goal
The goal was not to redesign a single table.
It was to establish a scalable, accessible table pattern that could work across products, technologies, and use cases.
One that:
- Feels consistent for users
- Is fast to design in Figma
- Is modular and predictable to implement
- Scales from simple lists to complex data-heavy views
The table became the test case for aligning design, code, and product teams around a shared system pattern.
Approach
Instead of optimizing for one “perfect” table, I focused on modularity.
The table was designed as a composition of interchangeable parts rather than a monolithic component. Layout, filters, search, pagination, row actions, loading states, and column behavior could be mixed and matched depending on context.
This allowed teams to build what they needed without reinventing interaction patterns or breaking consistency.
Spotlight: Filters as a system
Filters were one of the most impactful pieces of the pattern.
Previously, each product solved filtering differently. Now, filters are designed as a plug-and-play system:
- Multiple filter types with clear data models
- A dedicated filter menu and active filter bar
- Strict interaction and visual guidelines
- Accessibility baked in from the start
- Validated through research, not vibes
For developers, filters became composable and predictable. For users, filtering became familiar across products, even when the data changed.
Impact so far
This work is still evolving, but the benefits are already visible:
- Faster implementation thanks to clear component boundaries
- Stronger alignment between design and code
- More consistent experiences across products
- Accessible filtering patterns reused instead of re-implemented
Even when individual tables are not yet “perfect” in production, teams now have a clear reference point instead of guesswork.
Reflection and next steps
The table pattern proved that complex components are best designed as systems, not one-off solutions.
Filters are only one piece of the puzzle. Next steps include more advanced filtering logic, such as negation, conditional operators, and richer query building. The same modular thinking will guide those additions.
This case study is less about tables and more about how a design system can turn fragmentation into momentum.
