Patrycja Radaczyńska is a Principal Design System Engineer at Babbel, now building design systems at Babbel in Berlin. With a background in music, she transitioned to tech later in life and now combines her artistic and technical skills to innovate in her field. Patrycja is also a mentor, sharing her journey to help others. When she's not coding, she enjoys art, books, music, and road trips in her van.
Can you walk me through the current state of the design system you're involved with?
I joined Babbel in November 2022 as a Principal Engineer. Initially, we were just Ralf, the design system director, and me trying to understand what we were dealing with.
So, the first couple of months were a research phase. For me, it meant learning about legacy work, repositories, how teams use them, the tech stack, the current state of the libraries, contributors, etc. We were also trying to build relationships with engineers and designers. Then, I started planning, talking with different stakeholders, and trying to understand the product organization.
During the first couple of months, we discovered many things and planned, but also we were trying to extend the team. Passionate contributors maintained the design system at Babbel, but no one took care of it full-time. We needed to focus on some initiatives that we could push forward with given time and possibilities. The introduction of semantic colors was in progress but a bit stuck, and that was the more significant initiative that we decided to focus on. In the meantime, we prepared a plan for the design system topic according to the product needs.
Currently, we are much further in the development. We were able to release semantic colors tokens in the product, and thanks to that, we also released dark mode for mobile apps. We are currently focusing on building components for mobile apps and pushing forward design system components for React. We invested a lot of time in designing token architecture, and we hope this will help us to scale the system in a more consistent and maintainable way.
We got lots of recognition for the product, and this is a fantastic reward for all the advocacy that we have been doing.
What tools do you use to build and maintain your design system?
We manage our design tokens in Tokens Studio, and from there, we export variables to Figma. We connect from Tokens Studio to our GitHub repository, using the Style Dictionary to ship tokens for different clients to consume. We support iOS, Android, and other formats for the web, including JSON, CSS, and SCSS.
When it comes to components, we provide separate packages for different clients. iOS and Android are currently building libraries of components based on the design tokens we offer them. We also publish a package of React components for web clients.
From Tokens Studio, we connect to Supernova, our documentation tool. With Supernova, we combine all the dots to provide comprehensive documentation for different stakeholders.
How do you balance the need for consistency with the desire for creative freedom among your designers?
We're viewing our design system as a tool to enhance, not hinder, creativity. So far, designers have largely accepted it, likely because it's still new at Babbel and we're in the early stages of using it. I anticipate more discussions in the future. If our team or the system isn't adaptable, people will find ways to bypass it. As long as new designs are made using our foundational elements and tokens, designers have the freedom to create what they want, ensuring product consistency.
I'm always eager to see innovative designs from our product teams. If these designs prove useful to others, we incorporate them into our design system for wider use.
How do you stay true to your vision for the design system, even when faced with external pressures or trends?
Dealing with resistance is a common aspect of working with design systems. It's vital for us to keep advocating for the system. We must be flexible and remember that we're here to support the business goals. I aim to stay aware of what's happening both within and outside our design system team, gathering valuable insights. It's important to listen to feedback and make improvements. Our main goal isn't to create a flawless design system, but to develop one that best supports our teams.
How does your team collaborate on the design system? How do you ensure that your design system evolves with the changing needs of your users and stakeholders?
We are still a very small team, and a big part of our work is building the community around the design system. This is the only way to keep the design system alive. We want to avoid the design system being a bottleneck for product teams, and we want folks to feel that the design system is there for them. Building a solid contribution model and allowing folks to participate actively creates this connection, sense of commitment, and responsibility for the project.
We have a small core team that drives more significant initiatives. We are building a web of external contributors from different parts of the organization. They are a massive driving force for the adoption and advocacy of the design system in the product. Without them, we would be doomed. Those contributors are essential to pushing the design system forward, and they can channel feedback from teams directly to the core team or even propose or introduce changes to the system in collaboration with the core team.
Are you tracking your design system? If you had to choose one metric to measure the success of your design system, what would it be and why?
If I had to pick a key measure, I'd choose adoption rate and satisfaction. So, how widely and frequently are the elements used, and what are the satisfaction levels of designers and engineers? It's crucial to gauge how user-friendly the system is and identify areas for improvement. The system's time savings are important, especially when discussing with stakeholders. However, user satisfaction influences other aspects like adoption and usage. I hope we will reach the point at Babbel to have valuable data soon. Maybe next year. 😊
If you could go back and change one decision you made in your design system journey, what would it be and why? How would that affect your design system journey?
Three years ago, I would tell myself to be more confident when talking to stakeholders. I hid underground for many years with the design system work I had been doing, which was frustrating and blocked me from moving forward. It is probably part of the growth. It also made a huge difference when I met more people working in the design systems field. I wish it happened sooner; it would also help me get more confident about myself sooner. No matter what, I am still grateful for the journey!
Do you use any kind of automation or AI tools?
We will look into AI at some point; some low-hanging fruit might be in documentation; for example, we can use AI to help users get answers and guidance more easily. We do use some automation in the testing area, but we can automate more, and I think we will be looking into that topic next year.
Where do you see design systems heading in the next few years?
In the next few years, I anticipate that design systems will evolve significantly through increased automation, likely aided by advancements in AI. The focus will shift away from the manual labor of building components towards more strategic activities like engaging with users, comprehending their needs, and responding more swiftly to those needs.
We'll also see improvements in how we track and analyze the adoption and usage of design systems. AI could play a significant role here, providing deeper insights from the data we collect. I expect that out-of-the-box solutions will start to take over some of the more repetitive tasks within the design system workflow.
I'm excited about these developments. They promise a future where we can concentrate on the more critical and impactful areas of design system work, such as strategy, accessibility, and integration across platforms and teams.
What's one thing you wish more people understood about design systems?
One thing I wish more people grasped about design systems is their full scope. To some, it appears merely as a component library, while others see it just as a Figma library. Often, individuals only recognize the facet of the design system they interact with. Ideally, I'd like to provide a clearer picture, showing how all the elements interconnect. However, perhaps it's not necessary for everyone to see the whole picture as long as the system is user-friendly and addresses their needs effectively.
What I truly desire is for the design system to bridge gaps between different people, fostering better understanding and collaboration. By reducing frustration and improving communication, the design system can enhance the workflow significantly. Reflecting on my past experience, when I juggled product team responsibilities with developing design systems, I recall the frustration stemming from others not seeing the design system's value that I so firmly believed in. Often, initiatives related to design systems were turned down because they didn't promise immediate financial returns, making it challenging to demonstrate their long-term worth.
I know many teams out there are still trying to communicate the value of design systems to their businesses. It's paradoxical—design systems are widely used and needed, yet investment in them is frequently overlooked. I've felt this disconnect many times. I wish more leaders recognized the value of design systems and the effort that goes into them.
What's one piece of advice that you would like people to remember from this interview?
One piece of advice I'd like to leave with the audience is this: the heart of successful design system work lies in the community. Cultivating trust and forging strong connections with both contributors and users is paramount. These relationships have been the driving force behind my progress, from the days when design system development was a part-time endeavor or a side project, to now, as I focus on it full-time with a dedicated team. Effective communication and relationship-building with your design system's audience are crucial. Without the community and its users, a design system simply wouldn't have its purpose.
What's your favorite thing to do when you are not in design systems?
Outside of design systems, I have a myriad of interests. A significant portion of my leisure time is spent outdoors, enjoying nature with my dog, or journeying through Europe in my van. Remote work has become a part of my lifestyle, allowing me to traverse various European locales by car, accompanied by my dog and friends. The post-COVID-19 era has opened up the possibility for these extended adventures, which I find particularly fulfilling.
Despite my travels, Berlin is where I'm usually based. My passions extend to music and film, and I'm an avid cyclist, often found pedaling through the city's streets. Culinary experiences are another joy—I take pleasure in cooking for friends and seeking out new restaurants, places, and architectural wonders. Additionally, I invest time in the local design system community, organizing meetups in Berlin, which connects me further with local enthusiasts and professionals.