Problem

Chase's design system, MDS, had only been around for about three years at the time. It gave us a strong foundation, but it had real limits once we got into some of Account Uplift's more complex use cases. Three components we relied on constantly, the Tile Accordion, the List, and the Data Table, had already gone through several rounds of enhancement, and there wasn't much room left to keep stretching them. The MDS team advised us to use those components as a reference point instead and build custom versions suited to what our product actually needed. The tokens would stay the same, but our engineers could now build something entirely our own to fit the job.

Approach

That's how Custom Accordion, DIY List, and DIY Table came together. The Custom Accordion could hold almost any kind of content, key value pairs, additional slots within the main blade, giving us the flexibility to handle account information that kept getting more complex. DIY List supported multiple headers and sections, which we used to separate transactions by date and build clearer hierarchy as people scanned their account history. DIY Table let us bring in buttons, definition links, additional text treatments, and more, none of which the existing MDS Data Table could offer for Transactions.

Figuring out how to build these wasn't just a matter of picking components off a shelf. We had to understand where the existing system genuinely worked, where it could reasonably be enhanced instead of replaced, and where our own product requirements actually justified building something more specialized. Part of that meant understanding the real difference between a design-system component and a product-level pattern. MDS owned the components themselves, their functionality, tokens, and proper usage. It was on our team to figure out how those components should actually work together on a page: how information got prioritized, how spacing and alignment behaved, how things stayed consistent between Account Summary and Transactions. I attended MDS office hours regularly, three times a week, to work directly with the design-system team on what was possible, what wasn't, and where a custom solution made more sense than pushing the shared library further.

Challenges

Each component came with its own specific hurdle. The Custom Accordion was our first ever custom component built from scratch, and getting it to resize properly on web at extra-small breakpoints took real iteration. DIY List had a limited number of available slots to work with, and we had to design around WCAG 1.4.10 reflow requirements to keep it accessible at every screen size. DIY Table meant incorporating components MDS's own Data Table simply didn't support, so we were often building solutions that hadn't been tried elsewhere in the system yet.

Beyond the components themselves, the scale of the project added its own pressure. I worked across four separate scrum teams, so keeping design, engineering, product, and stakeholders aligned took real, ongoing effort. We ran design discoveries, IPBRs, and desk checks throughout the project just to keep decisions aligned from early exploration through implementation, and none of it happened in isolation. A decision made for one part of Account Uplift could quietly become the pattern another scrum team was later expected to follow, so we had to think past our own screens and consider how every choice would scale across the broader account experience.

Custom Accordion:

Challenges: First ever custom component / Resizing on web XS

DIY List:

Challenges: Limited slots available / WCAG 1.4.10 reflow

DIY Table:

Challenges: Incorporating additional components (MDS Data Table limitations)

Takeaways

This project taught me that staying within a design system doesn't mean limiting yourself to whatever already exists in it. Sometimes the right move is to extend the system while still respecting its underlying rules, which is exactly what these three components did: they kept MDS's tokens, behaviors, and visual principles intact while giving our product the flexibility it actually needed. It also sharpened how I think about design systems generally. A design system is more than a Figma library of components. It gives designers a shared foundation, but it's still on product designers to establish the patterns, hierarchy, and interactions that turn those components into something people can actually use.

Conclusion

All three custom components were successfully implemented by our scrum teams and went on to be adopted by multiple other teams across JPMC. That experience turned out to matter well beyond Chase too. It taught me how to design within an established system and extend it responsibly, which came in handy almost immediately when I moved to the NHL and ran into nearly the opposite problem: helping build a design system from scratch while designing the products that had to use it at the same time.