BACK
Consolidating Table Design Across a Legal AI Platform
Jan - Feb 2026
(2 months)
Product Designer
(also shipped production code)
Sentri AI
B2B SaaS Legal AI platform
Figma, Claude code
Storybook + Chromatic
Problem
During a customer call, a user couldn't figure out how to open a processed questionnaire. The team had to verbally walk him through it. The action icons were small, unlabeled, and placed differently than in any other view. He wasn't the only one. A second client showed the same hesitation on a separate call.
Security analysts spend most of their time in tables.
At Sentri, that means managing Q&A knowledge pairs, evidence documents, questionnaires, and client compliance guidelines. Tables aren't supporting the product. They are the product.
But every table in the product was built differently. And separately, when a customer uploaded files with long names, the Source column expanded and pushed other columns off screen. A layout we'd never tested for, because every table handled column overflow differently. These weren't edge cases. They were symptoms of having no shared table pattern.
Separately, when a customer uploaded data with long file names, the Source column expanded and pushed other columns off screen. A layout we never tested for because every table handled column overflow differently. These weren't edge cases. They were symptoms of having no shared table pattern.
audit
I audited every table in the product using claude code
Before designing anything, I needed to understand what existed. I went through every data view and documented how each table was implemented, row heights, header and sort behavior, action placement, empty and loading states, and upload button inconsistencies across views. Row heights and cell padding.
Header styling and sort behavior
Action placement and icon usage
How each table handled empty states, loading, and pagination
Upload/import button naming and icon inconsistencies across views
This gave me a clear map of what "unified" actually needed to solve.
The product had 5 separate table implementations in the shared UI layer, around 10 features using raw HTML tables instead, and 3 different column definition type systems. Row heights, borders, spacing, and actions all varied.
Nobody owned the pattern. Different engineers had built different features at different times, and nobody had stepped back to look at the whole picture. Storybook coverage sat at around 15%.
I designed the pattern from the hardest view first
The Q&A Pairs page was the most data-dense view in the product. 600+ entries, long text content in both columns, multiple metadata fields, and the most user complaints. If the pattern worked here, it would work everywhere.
Key decisions for the base pattern:
Compact row height (36-40px, py-2 padding) analysts need to scan volume, not admire whitespace
Content-first column sizing, Reduced metadata column widths (source, date, owner) and gave that space back to primary content
Relative dates ("2 days ago") instead of full timestamps for faster scanning
Consistent action placement: clear, discoverable row actions instead of scattered icon buttons
Toolbar pattern: standardized filter, search, and action button placement
Then I scaled it to every data view
Once the Q&A table was solid, I applied the same pattern across 3 more views (Evidence Portal, Client OCGs, and Answered Questionnaires). Unifying row density, header alignment, action placement, and toolbar patterns across the product.
I verified all 4 views side-by-side to confirm every detail matched.
system
Every pattern shipped as a design system component
This wasn't a visual cleanup. Every pattern I built went into Sentri's design system, documented in Storybook and covered by Chromatic visual regression testing:
Table: default, compact, selection, sorting, actions, expandable, empty, loading states
All built in code (React/TypeScript/Tailwind) & merged to production via PRs I authored.
ai-powered workflow
I designed in Claude Code and shipped it myself
My process at Sentri isn't Figma-to-handoff. I sketch rough direction in Figma, then move into Claude Code where I design and build simultaneously with React, TypeScript, Tailwind, straight into production components.
For this project that meant iterating directly against real data. When compact row height felt off at 40px, I adjusted it and checked it against 600+ actual Q&A pairs in the same session. When I unified upload buttons across 4 views, I didn't file 4 tickets. I made the changes and opened one PR. The table pattern I designed isn't a handoff artifact. It's the code running in production.
Outcome
5+ implementations became one
4 major data views on the same design language. Storybook coverage for table components went from ~15% to full which means any engineer building a new view starts from a documented, tested pattern instead of improvising another one. Every change shipped to production as code I wrote.
No more "where do I click?" confusion on customer calls
5 table components consolidated into 1 unified, reusable pattern
4 major data views now share the same design language
Compact density gives analysts significantly more data per screen
Storybook coverage for table components went from ~15% to full coverage
Every change shipped to production as code I wrote
