Maintaining a Shared Pattern Library
by: Kim Schneider, Tobias Pickel, Michael Schmidt-Voigt, Filip Ilievski
Before we created the backoffice, we had a big task to accomplish. What should it look like? At that moment, we didn’t have that much time or resources to conceptualize and design the backoffice as we know it today. In fact, we only partially knew what we needed anyway, so we just needed a push to get things going. Since all the technical decisions had already been made, it was pretty easy for us to decide on Material UI (now simply called mui) as our UI library. So, the backoffice looked pretty much like Material-UI with some custom elements added to it.
As the backoffice began to grow, new teams formed, and new custom requirements emerged, some order was needed. Our previous structure included multiple teams working on different areas, and they all had either their own UX/UI designers or some common designers for those teams/areas. There was loose synchronization between them and also between developers who may have already built that particular component, but since there was no clear communication protocol, it was difficult to stay up to date.
Not only were we missing some order in all of this but also knowledge transfer.
We’ve introduced a weekly session that we now call “Pattern Library Sync”. In this round, the designers working on the backoffice, as well as some developers who want to stay up to date or get involved, discuss and present changes across the backoffice. If there is a big design change coming up that could affect many teams, we discuss it in this round. We define work packages, tasks, and so on so there are no surprises for anyone. We document our changes and decisions and take them back to the teams, share the knowledge and possibly prepare presentations for the company.
Around the same time, we started managing our custom components and their usage with Storybooks. It was an experiment to see if this would help us track growth, both in the backoffice and the teams involved. All of this happened by the end of 2019.
The design team itself works in Figma. This is also the place where we as developers get our resources, get feedback, and discuss with the design team. However, this leads to a problem because we now have two sources of truth, and to be fair, Figma is always one step ahead of Storybooks. So a new need arose for a workflow that makes sense to all of us. We need to somehow make sure that the designers are aware of the components that have already been developed, and that the developers are aware of the design guidelines and what is coming. Figma’s structure is not a problem for our designers, but not all developers know about every little thing in it. Conversely, our design team doesn’t necessarily know about all of our components. And sometimes, for some reason, we develop new components without the design team being involved, and there may be some developers who know about it, but not all… things can get confusing very quickly. So here is our plan. The developer's task is to keep Storybooks up to date. The designers’ job is to keep Figma up to date. When we’re about to implement a new feature that requires new design work, the designers in Figma check to see if something already exists, and if not, they look it up in Storybooks. And if everything is going well, there is already something that can be used, developed further, or redesigned. If not, we might bring it up in the Pattern Library Sync to get everyone on board, or we might just go into discovery mode to figure out what we really need, design the feature, and develop it. In the very best case, the new component ends up in Storybooks.
However, the reality is that our components in Storybooks are really not well maintained and are not as up-to-date as we would all like them to be. We started Storybooks as an experiment and never really finished it. We still have a lot to learn about how to best use it.
Read the other posts in our Series Explaining the Backoffice:
