In-house at TotallyMoney | My role: Principal UI Designer
When I first joined TotallyMoney, there was an intention to build a design system but few foundations had been laid. There were a couple of disjointed and incomplete Sketch UI library files and an unrelated selection of components in Storybook.
One of my first tasks upon joining was to conduct a UI audit. I discovered that the product had grown organically and as such was full of inconsistencies. There were at least 40 text styles, and multiple versions of each of the palette colours. As a result, it was hugely confusing to work on the product. There was a clear requirement for a robust design system.
The company was still using Sketch at the time. My initial aim was to create a single strong, efficient, more comprehensive UI library file. I set up a completely new structure, based on Brad Frost's atomic principles.
I started with the most basic foundations: the palette, typography, grids, buttons and icons.
At the beginning, the new UI library was universal, covering both the web and native apps. This would change when the Future Vision project focused on the native app first – more on this later.
In the summer of 2020 the design team moved from Sketch to Figma, to facilitate a more collaborative way of working. This decision transpired to be hugely beneficial. I leveraged Figma's excellent 'variants' feature to reduce the overall number of components and make the UI library easier to consume.
I then started to think about how the design and engineering teams could come together to build a proper design system.
The images below are screenshots from the Figma libraries (note that the 'Read guidelines on Zeroheight' buttons are not clickable).
The core product palette
Colour icons from the shared UI library
Product icons from the shared UI library
I set up a Design System Guild comprising designers and engineers who had an interest in improving and bringing order to our product. To kick this off, and gain exposure for the new guild, I facilitated a workshop in which we all considered what we felt the design system should be. This was extremely useful in engaging the right people, and from it came a team who would initially meet fortnightly and later monthly.
In addition to the main guild, we soon established a core group of four representatives from web engineering, native engineering, product design (myself) and creative design. We were given the time and space to work out the nuts and bolts of our new system, giving life to the decisions made by the wider guild. We worked out how to keep our Figma UI library and Storybook components in step, matching component names, variants and properties so that designers and engineers spoke the same language. We also agreed a shared set of priorities.
After some deliberation we chose Zeroheight as the platform that we would use to tie together the loose ends of our nascent design system and provide appropriate documentation for its consumers. This was essential for the future governance of our system.
An accessibility documentation page on the Zeroheight platform
Top of the border radius documentation page
Part of the documentation for typography in the native app
To raise awareness of our new design system in the wider company, the core team of four representatives from design and engineering put together a presentation for our weekly company breakfast meeting. We explained in simple terms what a design system is, and launched a competition to come up with a name for our system. This garnered unexpected levels of engagement – we ended up with more than 70 entries! Some funny, some clever, some bizarre.
A winner was chosen and the TotallyMoney Momentum design system was born. My former colleague Charlie Lewis created a logo for it, based on the clever concept of a Newton's Cradle.
At the same time as the design system started to take shape, my work on the Future Vision project was accelerating. This concentrated initially on the native app, and resulted in a raft of new styles and patterns being created. The single unified UI library I had set up, shared between the web and native apps, now became difficult to maintain. I saw a need to break the library into three: shared foundations, web app and native app.
I set up the Figma libraries in a way that was easy for designers to reference and tied our platforms together. For each component or pattern, I provided brief 'TL;DR' documentation with buttons out to read detailed guidelines in Zeroheight.
Badges and labels from the shared UI library
Top navigation and tab bars from the native app
In-app notifications for the native app
Native app templates
A selection of components from the native app UI library
When Figma introduced variables, it became possible to define design tokens directly in our design files rather than only in code. Together with my former colleague Aaron Krohn, an engineering lead, I designed a token set that both disciplines could share. We began with colour, building a full primitive set and a semantic layer that laid the foundations for dark mode. We then tokenised spacing, border radius and typography.
Spacing unit tokens shown as Figma variables
A snapshot of border radius tokens in JSON
Alongside our UI libraries and Zeroheight, I maintained a set of master files: Figma files containing the key screens from our web app, native app and public website. Where Zeroheight documented how the system should be used, the master files showed how it was used in the live product, making them a 'source of truth' for what customers actually saw. They were organised as a hierarchical diagram, as shown in the example below for the native app.
The native app master file
As time progressed, we faced the questions every growing design system eventually has to answer. How should new components be proposed and reviewed? How do we release beta patterns without undermining the stable ones? When, and how, do we retire old styles and components?
I set up a process using Notion for product designers to submit proposals for new components. This encouraged them to think carefully about the role of their proposed additions within the context of the wider system, and whether something already existed that would satisfy their requirements. Beta patterns were labelled as such in both Figma and Zeroheight until they were proven in the product, and deprecated components were flagged and given a retirement date before being removed.
Zeroheight was the first destination for our team to reference, but I set aside time to answer questions directly. When nuanced design questions arose, I gave clear, considered guidance, firm where the integrity of the system was at stake and flexible where it wasn't. Complex cross-functional problems were put before the guild or the core team.
By the time the system had matured, the contrast with where we started was stark. A product that once had dozens of overlapping text styles and colour variants now had a single, documented set of foundations. Design and engineering shared a common language, which meant fewer misunderstandings, faster handoff and a clearer picture of how the product fitted together. Accessibility also became a primary concern, built into the documentation and the components rather than checked at the end.
My five and a half years at TotallyMoney taught me a great deal about setting up and managing a standalone design system. I've taken what I learned about governance and maintaining a live system into my role at J.P. Morgan, where I'm responsible for the core Markets system. The challenges are different in a large, heavily regulated organisation, where product-specific libraries must work in concert with company-wide systems.
More recently, I've seen a growing recognition among senior leaders that design systems have a vital role to play in enabling AI-enhanced design. To support this, I've re-architected parts of the Markets system so that AI agents can access it through Figma MCP. I've also begun exploring how AI can support the ongoing growth and maintenance of a system: