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:

  • Framework (Mission, values, the way we work etc)
  • Foundations (Accessibility, tone of voice, tokens etc)
  • Platforms
    - Web App
    - Website
    - Emails
    - Admin
    - Help Centre & Intercom


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:

  1. A better visual documentation tool – Confluence is not a suitable platform for a central platform to house and communicate how to use design libraries and follow conventions. It's too limited in its features to really get a proper branded feel, and to demostrate interactions. We ended up using a combination of Confluence and Storybook but for both designers and developers documenting the design system was cumbersome and clunky, and I believe this is where the design system needs(ed) more work.
  2. Dedicated team & dev stream – Push for a dedicated team and development time early on. We never had the capacity to put time into the project - it was known we needed it, but when resources are scarce it always took a backseat - especially in development maintenance of existing components.

Thinking ahead, we planned our design system to handle growth at scale

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.

Hatch DS - Structure

Hundreds of variations, sub-components and learning the art of Figma's override system

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.

Hatch DS - Variations

All the pieces we needed for our interfaces, but no more

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.

Hatch DS - Layout
Natalie Ferguson
Andy’s work touched every part of the business. His focus on delivering results at a high growth startup, alongside his methodical approach to design systems enabled us to rapidly experiment, iterate, and roll out “needle-moving” features at pace. He’s excellent at taking a piece of work from start to finish, and brilliant at pulling designers together to build on each others ideas.
Natalie Ferguson
Co-founder & Chief Experience Officer @ Hatch
Lulu Pachuau
If you’re looking for someone who has empathy and respect for the customer and users, can collaborate easily and openly with anyone, takes time and care with their outputs, Andy is your designer. The fact that he’s a top notch designer, goes without saying. But what makes Andy great is his ability to grasp new and complex ideas, growth mindset, technical knowledge and ability work with anyone at any level. I loved his openness to learn new ways of approaching design, give and take feedback. These attributes make him a great asset to any team.
Lulu Pachuau
Design Director @ Hatch