Summary

I have a soft spot for workhorse projects. Not every design initiative is a flashy new feature — some of the most valuable work is about fixing the foundation so that everything built on top of it works better. This was one of those projects, and it’s one I’m proud of.

After three rounds of layoffs, ChartHop was lean. We’d been building fast for years, accumulating design and technical debt that was starting to show — in user feedback, in NPS scores, in the time it took engineers to implement anything that touched a shared component. PM, design, and engineering leads regrouped and we proposed an initiative to address it: incrementally improve discoverability, consistency, and scalability across the platform.

I took point on this initiative and worked to define what we could tackle to incrementally improve our users’ lives and our own efficiency.

List tables — the landing pages for every section of ChartHop — were a great candidate. They touched every user. They were deeply inconsistent despite looking similar. They were low risk to update, compared to major features with lots of dependencies. There was also a strategic angle: they could give us the opportunity to unblock adoption of the new design system and de-risk the upcoming overhaul of our datasheet feature.

Note: the navigation improvements that ran in parallel are covered in a separate case study.

Problem/Context

List tables looked like they were based on the same template but in reality, they had been implemented quite differently by different teams. Visual design, content, interactions, behaviours, and actions varied from page to page in ways users noticed even if they couldn’t articulate them.

Unlocking the design system: the design system was stuck. A year of careful work, sitting unshippable because the bridge between the new Figma components and what was in code hadn’t been built.

Strategic de-risking: we planned to adopt AG Grid for the upcoming datasheet overhaul, but introducing an unfamiliar framework on a high-visibility, high-complexity project carries real risk. List tables were a lower-stakes environment to explore and validate the framework first.

The Solution

Aligning on standards & validating throughout

I’d learned from previous projects that standards imposed by design don’t stick. I’d been quietly developing standards off the side of my desk for years — useful within the design team, but without broader adoption. For this to work differently, PM and engineering needed genuine ownership.

To collaborate and align on standards (for list tables and beyond), I set up PM/Design leads and Engineering leads working groups. Each woring group met weekly for 30 minutes but only if we had something to cover. Agendas shared in advance, sessions recorded for anyone who didn’t join in person, notes distributed in Slack afterward.

CX and HR working groups served as a cheap and cheerful way to solicit feedback and get user validation throughout the design process, as well as being a mechanism for running discovery on upcoming projects in parallel. We met up weekly in a similar format to the other working groups, just with slightly different agendas.

I looped the working groups in from the get-go and our collaboration was part of making this project such a success.

Audit first, design second

Before designing anything, I audited every list table instance across the platform: what information was shown, what interactions were supported, how these varied. Loading strategy, scrolling, column resize, sticky headers, tabs, filters, toolbar actions, sorting, row selection — all documented and shared with the working groups. The audit made the inconsistency concrete and visible, which made the standards conversations much more productive. It’s one thing to say “things are inconsistent”; it’s another to show exactly how and where.

Next, where we had variation in implementation, we aligned on standards for approach.

Rolling out to eight teams

We started with the simplest list table pages and expanded from there, with the core team building out all component variants and table UI template before handing off to the other eight engineering teams, giving each team a chance to play with the new system. Because those teams had been part of the working groups throughout, implementation was meaningfully faster — they’d already seen and shaped the standards, and the components were ready in the library.

Final designs

What I’d Do Differently

Honestly, tabular lists like this are great when you have >10 items to display but that’s not representative of the majority of these landing pages for most users. Owners, sure. But your average employee or manager might be looking at significantly fewer items, for example, three reports or scenarios. I think more appropriate to those cases would be to allow the user to toggle to a more approachable card view. I whipped up a design for that early on but we didn’t get around to implementing it.

Ask me more

Happy to go deeper on the broader initiative, the working group model, the validation process, or how I embrace standards & principles to align and empower product teams.