TotallyMoney design system

TotallyMoney design system

How we built a design system from a place of confusion

In-house at TotallyMoney  |  My role: Lead UI Designer

At the time I first joined TotallyMoney, there was an intention to build a design system but very 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 starting my new job 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 up to five different versions of each of the palette colours. It was hugely confusing to work on the product; nobody seemed to know which were the definitive styles and patterns. It was clear that work should begin immediately on building a robust design system.

The company was 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 but naming the levels in a more prosaic manner: foundations, elements and patterns. My experience of working with other product design systems was that consumers would often forget the order of the traditional atomic monickers. I started with the most basic foundations – the palette, text styles and grids.

The brand palette A few of the text styles

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.


Move to Figma

In the summer of 2020 the design team moved from Sketch to Figma, to facilitate a more collaborative way of working. After a period of adjustment 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 use.

I then started to think about how the design and engineering teams could come together to build a proper design system.

Variants of the form field

Establishing a guild

We 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.

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 figured out ways to align our Figma UI library and the Storybook component libraries, and agreed on shared priorities. After much deliberation we chose Zeroheight as the platform that we would use to tie together the loose ends of our nascent design system.

Part of the form spacing guide Buttons used in the web app

Creating dedicated libraries

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.

Table rows for the native app

I was reluctant to add outdated, deprecated patterns to the Figma libraries, which sparked a few interesting discussions. I felt that the design system should be representative of the future of the product, and the parts we wanted to keep from the past, rather than being a repository of absolutely everything. I created guides to show which of the new components could be used with which template.

Native app templates

Choosing a name

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 garned 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. It is a continual work in progress. For all the devotion we have for it, it will never be finished.

However, its tangible benefits are already clearly evident. We've seen much improved collaboration between the design and engineering teams, a speedier workflow and a greater understanding of the way that the product is structured.


See previous work