This month’s newsletter will be about Design Systems. The first time I heard about Design Systems, was when reading Brad Frosts Atomic Design book in 2016. Of course, modular design existed way before that, for example in graphic design with the iconic brand guidelines of the 60s, that described, what colors, fonts and sizes to use. However, Frost’s book was one of the first foundational books for creating modular pattern libraries for the web.
From 2016 onwards there was a big hype around design systems and most major companies like Apple and Google adapted them. You can find a great collection of amazing design systems on designsystemsrepo.com.
Having worked with Storyblok’s design system in the last year, I have to say creating a good design system is a continuous challenge. It depends on the team, the designer, and the product and there is no one-size-fits-all solution. As a team, we got into discussions even on a small component level of how an element should work and look. A design system is a lot of work, that pays off in the long term because you will build new parts of the application faster and more consistently.
Last month we were working hard to release the beta version of the Storyblok V2 app. It was really busy and the whole team pulled together to make the deadline. Personally, these hard release deadlines in software development are quite stressful, but a good team and process setup can help to prevent developers to burn out. A month ago I did a short twitter survey on what situations cause people to write bad code and surprisingly a lot of people answered that hard and tight deadlines or bad processes caused them to introduce problems in their code.
I read this book a few years ago and found it was a good introduction to how design systems are connected to frontend architecture. Some of the examples might be a little outdated, but the principles still apply.