Prefab - Design System
Upon joining Strike I knew that one of the projects I would be working on was the company Design System. Strike already had one, but as it turned out during the discovery process it was very hard to use, and surprisingly, very hard to find.
After some initial research, I decided to put together a short presentation on what we had, where we were, and where we could be, if I could start our design system again from scratch.
Presentation
I’m a visual person, and that’s how I communicate.
As I saw it, at that time, design system was like a makeshift store in a small-town market. Intimidating, not very consumer focused, not really something you would gravitate to naturally. Because of that and more, it was left unused, which resulted in lack of coherence in design files being handed over to developers.
My proposition would be modular and community-driven, a living organism, a beautiful store with an intuitive structure.
I must have been at a good place and the right time, because the stakeholders consulted were very much on board. With that in mind, I started building.
Typography
We started by documenting all font sizes that hadn’t been used. As we were creating components, widgets and new patterns, if we encountered a need for a new font size, we’d debate and implement it.
Over time we learned this approach wasn’t sustainable; every time we’d change a global font size it would result in a lot of unexpected behaviour of different elements, creating unnecessary design debt.
Hence a decision was made to move into a Design Token approach, which would ultimately create a future-proof system of independent reusable elements.
Name
Prefab means a prefabricated building. Our Design system could be a prefab for designs. Get it? I thought it was a pretty good idea.
Components & Libraries
Components were a hot debate, “Should we keep all components in one file, or even one page, or spread it amongst multiple files? How should we structure it all?”
My answer was to utilise Figma’s built-in libraries functionality, which allowed for the categorisation of each component, style and asset to create a truly modular approach.
This approach made it easy to turn libraries in any file on or off, and everyone in the team started adopting and contributing to Prefab pretty much instantly.
Documentation
After a while, it became apparent that we needed a way to communicate major changes to our system and document patterns across Strike’s ever-expanding world.
Confluence was my tool of choice to solve this problem.
As mentioned before, these things (design systems, documentations) are never finished, they’re a version-controlled entity that lives its own life and adapts based on the needs of its users, which is precisely my philosophical stance on Design Systems.
Every time I would learn of a problem, big or small, with Prefab, I would be glad, because the more issues are addressed the better the system is, and more usable it becomes.
Challenges & Takeaways
I am very proud of all the work I have put into Prefab; it is the biggest Design System I have ever created, though credit belongs to all my colleagues who helped and stakeholders who allowed me time and flexibility to build it.
To sum up my experience, here’s a few points:
Building it is hard, but maintaining it is harder
Don’t ask for time to create a pitch, create a pitch and ask for time to expand on your vision
Feedback is your best friend
Create patterns and procedures that benefit you, the user, and the organisation. If one isn’t happy, it won’t work long-term
There’s a lot more I could say about Colours, Iconography, Illustrations and other facets of Prefab, but trust me when I say this could be a book, not a case study. I hope this short format enlightens at least one person into creating a system of their own.
If that happens, this study has done its job.