Design System

Leadership did not ask for a design system. When I brought it up, they actively pushed back. The designer before me had been fired in part because leadership didn’t love how the product looked, and pitching a “let’s rebuild the foundations” project right out of the gate sounded like a long detour from real work. Their specific worry was that this would mean pausing features to go rebuild plumbing, which was a non-starter.

So I sold a different version of it. The pitch was that we’d build the system as we went. No stop on roadmap work. We’d ship the components we needed for upcoming features, swap the old ones out in the codebase opportunistically, and let the system grow alongside the product instead of in front of it.

The thing that actually turned it was the devs. They were begging for this. A group of them volunteered to put an hour or two of their week into helping build components and replace the old code, on their own time. That changed the conversation. Once leadership saw engineering actively pushing for this rather than tolerating it, they greenlit it. I was upfront that the real payoff was months out, not weeks, and we moved.

Tables are everywhere in this product. Legal docs are basically tables wearing trench coats, so the table component had to do real work, not just look good in a screenshot.

The hard part was accessibility. Most data tables on the web fall over the moment you turn on a screen reader, and side-scrolling tables are even worse. Ours had to handle a lot of columns without becoming a horizontal scroll trap.

What I landed on: the table side-scrolls like normal, but there’s a button in the top right that lets you tab through column groups instead of dragging. Keyboard users and screen reader users get a real path through the data. Mouse users still scroll if they want to.