As our small *but mighty* design team grows and matures, the need for a design system kept coming up. And our website was growing and more things were being made! We switched from Sketch to Figma in 2020 and while we were able to import our old system, it was getting increasingly difficult to know what the most updated asset was. Our UI kit was incomplete, disconnected from code, and components were not built responsively or with editability in mind. A design system to us means having a source of truth for all of our design components alongside a collection of documented design decisions and processes. This year we were able to dedicate some time to building out our design system in Figma. We only had 3 months to build a solid foundation and here are our reflections at the end of it all.

Determine how you’ll document your system from the start.

With such limited time, we had to decide what we wanted to achieve at the end of the 3 months and what order the components should be built in. A common problem we have as a small team is leaving documentation to the very end or not being done at all, so we wanted to do this the right way. Since design systems are meant to be used by others, we decided that a component will only be marked as complete once documentation is done and reviewed by another designer. This documentation will live in Figma on the same page as the live component and will be linked from other places like Confluence. This ensures that other people can understand and use your work while also proactively identifying gaps in the component that can be addressed right away instead of finding out after the system is “launched”.

Start small and build up to bigger things.

With only two designers working on this project, we had to be strategic and realistic about what we could achieve. We made decisions based on what would be the most impactful for our team. Taking from atomic design principles, we worked from smaller components like input fields or checkboxes into larger things like forms. This allows you to document these small design decisions that you can then reuse as base components throughout your system. But we didn’t wait until we had all of our atoms and molecules built before creating bigger things. Instead we determined what organism would be most helpful to have, like our footer for example since that lives on every page, and worked backwards to determine what atoms and molecules we needed to build it. At the end, we had a fully built out footer and a few atoms and molecules we could reuse for other organisms. So build what you need now in a way that works — it can always be updated later.

Don’t future-proof your way into a dead end.

Building a design system is complex and as a small team, we don’t know the next chance we’ll get to go back and update components. So we might as well build it perfectly the first time, right? Well… it’s really difficult to design without constraints and equally as difficult to design for future use cases that haven't even happened yet. So, a suggested approach is to note down those edge cases that might come up and see what your options are to tackle them but don’t let that block you from building a component you and your team can use today. Save some time and don’t overbuild if you don't need to.

All these design rules are just suggestions; make things you’ll actually use!

There are plenty of articles out there on how to build the perfect design system but ultimately do what makes sense for your team and your organization. This means your design system will be unique and won’t work exactly the way another team’s would. And why should it? Your organization and its needs are unique as well! Taking inspiration from other design systems is a good idea but only implement parts that you’ll actually use. We decided what components to make based on what elements were most common throughout our site. Toggles are a frequent UI element but we don’t have any right now and we had to resist the urge to prepare for something we aren’t using yet. Design systems are living documents so you also don’t have to get it right the first time. It should be used, revisited, and adjusted to fit the needs of the people using it.

So what’s next for us?

We were able to build out the foundational elements for most components to allow any designer to mock up a full page or to quickly create a new component if needed. Now it’s time to assess! We’ll be keeping an eye on how other designers are using the system, how we can help bring this all into code, and how people outside the team can contribute to the design system. With a rebrand coming up in early 2024, this is the perfect time to test our system. By learning along the way and making decisions that worked for our organization, we have built something that’s adaptable and sustainable.

Feel free to peruse our documentation here!