In this short write-up, I want to take you along into the world of pattern libraries. First, let's investigate what is a pattern library. Then we dive right in with relevant features and considerations when choosing a pattern library, and some brief examples.
What is a pattern library
First, let's talk about a design system, which is a way of working of systematically designing and building your frontend, such that it adds value: consistent branding, ease of reuse across the applications, and ease of maintenance/continuous improvement, and with it, supporting iterative design.
This means thinking, designing and building in reusable design building blocks, and some place to show these blocks to make them first class citizens in your design process. Such a place is called a pattern library, and this kind of tool is therefore the cornerstone of a design system way of working. There are many such tools, so there is a choice to be made here, with many relevant considerations.
Useful features of pattern libraries
A pattern library is a tool during development, as well as a showcase of all your built patterns. As such, development "quality of life" features are much appreciated, such as file watchers, live reloading, browsersync, that shorten the cycle from code to visible component. The quick iteration that this allows, will let you as developers and designers radically shift your work process from handing over designed images and checking when development is done, to working together behind the same computer, constructively going back and forth about what works best for the user with the available technology. To get an idea of how this flow might look like, I can recommend the following conference talk from Rachel Andrew:
Other quality of life points help as well, such as easily checking your component in different browsers and/or window sizes. This allows you to bring mobile first much easier into your design/development process, which is a must nowadays.
As your pattern library is also a showcase of your components, you want it to have proper documentation. There are many aspects and nuances in good design, that you want to come across to the people that will use your pattern library. Things such as design tokens, color systems, or fonts, that may have specific use cases. This is useful for other readers, as well as during the evolution of your patterns, because another key feature of a pattern library is that it is a living document, a good design system is maintained when it needs to. This means that besides showing components, you want your pattern library to support generic documentation pages.
You want your pattern library to be easily readable and accessible, because that is how it is used. As such, because it is a web application or website, people should have access to that website. This means (amongst others) that it needs to be easily deployable to a web server.
Your components are not only exisiting in your pattern library, the idea is that they are used with fewest effort in your production applications. Therefore it is very useful to keep your components portable, by using the same template language across pattern library and other applications. This can be tricky though, as a production application built in backend technology such as (Java, C#, or a some packaged solution) might not support any typical frontend template language, whilst the pattern library is used and mainained by the frontend developers in frontend technology.
Examples
Fractal is a useful choice as a pattern library. It runs as an express server with watchers during development, and can be exported as static flat HTML, CSS, and Javascript files that can be hosted on an HTTP server without any logic. As it is built on express, Node and NPM, it can be easily fit into an existing frontend project, which already uses this technology, and it also allows for some extensibility. For more information, see https://fractal.build/
Another great pattern library tool is Storybook. Storybook has great frontend framework support. It also comes with a lot of bells and whistles, such as plugins, which allows you build a great workflow in development, as well as improving the showcase aspect of it by leveraging the frontend framework in which the components are built. These extras might be difficult to fit into an ongoing project though, as they might compete with something existing that works differently. See also https://storybook.js.org/
Conclusion
As you might have noticed, there are many aspects to choosing a pattern library, but do not feel overwhelmed. In the end it is not about making the right choice, but about making a choice that works for you, as you and your team needs to be able to work with it. There is no right or wrong, especially with so many considerations and so many tools in active development.
Top comments (0)