Hatch is a DIY investment platform with a responsive consumer facing web app that allows users to deposit money and invest it in the stock markets. Aside from being the best priced platform, our Chief of Experience Natalie Ferguson & Design Director Lulu Pachuau created a design lead business that was on a mission to make investing easy for everyday kiwis - from design and user experience, right through to using layman english and understanding each investor mindset, deeply.
When I joined Hatch in 2021 we were bootstrapped (literally Bootstrap) with very little design consistency across our multi-platform offering. After switching the design team to Figma from Adobe XD, we set about building out a design system that catered to not only designers and developers, but a central hub of guidelines for all employees at Hatch - from content writers to senior leadership.
Though I had come from designing a design and developer library of components at WPMU DEV, I wanted to fix shortcomings and look at other companies who had built more scalable options. Resting on Spotify's design systems, we ended up having a unique structure where all of the design systems shared core framework and foundational guidelines, but each output (app, website, marketing etc) had their own design systems mapped out. Like so:
In my mind, adoption was always going to be the biggest challenge at a fast-paced startup. Yes, designers love them; developers usually find issues with them; but senior leadership and other parts of the business hardly understand why we need them or what they achieve. However, I approached this methodically through multiple presentations and workshops to communicate the opportunity at hand.
Looking back, two main lessons stand out for me:
When planning design systems, most smaller teams whip up a design and (matching) dev library of components and rules for designers and developers to follow. That's where we all start, but from detailed research into how larger teams worked - Spotify stuck out as an example of a company that had rigorously adjusted their systems for a multi platform and global system all under the one framework.
Taking notes from Spotify and other great systems (Shopify, Airbnb etc) we formed a core set of guidelines that all of the company could refer to and follow (mission, values, mindsets, content guidelines, design tokens etc), and then defined a sort of umbrella structure with sub-design systems specific to each platform. You can see Confluence followed this structure (our documentation platform), where Framework and Foundations sat separate to the Platform design systems for the Web App, Website, Emails etc.
This worked well, as all these teams shared aspects of the foundations, but ultimately had their own constraints when working in the platforms we were designing, developing or writing for.
Our Figma library was also set up in this manner, with a Core library of colours and logo tokens, enabled by default for all the sub libraries that were specific to the project you were working on (App, Emails, Admin, Website etc). This worked well, with each team having a nominated gatekeeper looking after their design and dev library.
Going from Bootstrap and no design library to 8 Figma libraries harmoniously sharing information between them was no mean feat and took a lot of trial and error. As you can see, we broke every variation of each component down to match exactly what was expected in development. Buttons had variations for their type, state, icon position, size, loading and disabled states, and more recently - darkmode support.
I personally had never built a design library that supported dark mode before, so this was a decent learning curve. In the end, the design libraries had an additional variation added to their colour styles "Light" and "Dark". Working closely with our frontend devs we figured out a way to set a top level theme that ultimately override the colour variables for design token being used. It worked surprisingly well and ultimately sets the platform up to support not only light and dark modes, but also potentially device or OS specific themes. Very cool.
At my previous role at WPMU DEV it was one of the first proper design systems I had built. One of the mistakes I desperately wanted to avoid with Hatch's design system was keeping things lean and nimble.
As a rule, no new component was added to the design or dev libraries until it had been re-used in a second project.
This rule served us well. Time and time again we thought "should we add that to the design library?" and over the course of 18 months there were plenty of examples where we would have added a component that was only single use (for now) and ultimately introduces bloat and dead-weight to a system that's intended for efficiency and speed.
That said, we still had 100s of components available for use, all working perfectly (reads 'well enough'!) in a way that created harmony in most interfaces designed. Limited use of colours, set sizes and line-heights, consistent padding etc ended up bringing the apps experience into a tighter, higher quality outcome that truly felt Hatch.
