Designing For Development: Building A Design System At Brainly

Patrycja Rozmus at UXDX Europe. Video: https://youtu.be/I-SA6AGmDIQ

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introduction

[00:00:00] Hi, my name is Patrycja Rozmus. I'm a Design System Lead at Brainly, the biggest online learning community in the world. We are still a relatively small company, but at the same time we make products that are used by over 250 million users in 35 countries, which interestingly creates tensions in development. I will tell you what making a design system looked like in this environment.

[00:00:23] From this talk you will learn what the development of our design system looked like and how we sold the idea to the business. I will also talk about our design principles and our famous design system tools made at Brainly, about the structure of our teams and actual buy-in across the company, and finally about the design system's secret sauce that makes it all work for us. I hope you will be able to use some of those insights in your organization. Let's get started.

The design and development ping-pong

[00:01:01] The story begins in 2015, when our developers made the first commits to a Brainly open source style guide. Unfortunately, it was one-sided, and designers used their own UI kits, which after some time resulted in problems during implementation. Our designs contained elements that were older or newer than those in the style guide. So after two years, our implementation process started to look a little like this. Does this ping-pong look familiar to you? During the handoff, both parties had to decide whether given elements should be changed in the designs or in production. Developers were often unable to make the product look like it did in the mockup, and it was tiring for both teams, or even for the stakeholders, who didn't understand why the final product differed from the prototypes they accepted. So it was a problem.

[00:01:55] Seeing those problems, I made an inquiry into our teams' work with the style guides. All members of the design and front-end teams participated in workshops during which everyone could share their biggest problems and prioritize them. We ended up with a bunch of Post-its that described our issues, and there it is: our biggest problem. The workshop confirmed that the biggest issue was the lack of shared libraries and of logical structure in them. We decided we had to address this, and started working on the design system, with a shared language between the teams as a priority.

[00:02:44] After some research, I came up with this. The Brainly design system needs to focus not only on the product but also on marketing. It's not so common, but in our case it was necessary, as we didn't have a marketing team. This kind of work is done by our community managers, and they are not designers. Strange, I know, but this is how we roll, and we still managed to get that growth. Imagine that. So to help non-designers design for Brainly, we also needed libraries, guides and templates for marketing initiatives. In detail, it looked like this: we have the brand at the heart of the design system, with all the elements you would find in a more advanced brand book. The guidelines and patterns for product and marketing emerge from the brand. This is how our design system is actually built now.

Selling the design system to the business

[00:03:32] But before we started, I needed to sell the idea of the design system to the business, and it wasn't easy. This was the typical reaction when I said those mysterious words, "design system." Nobody knew what it was. Today it is much easier, as design systems have become an industry standard, but then they were not.

[00:04:01] One of the main selling points was the quality of our product and its consistent branding, which are now more important than ever. In today's digital world of social media, users have become brand ambassadors through their feeds, for example, and they have more impact on a brand's popularity. Advertising agencies are becoming more and more supplementary in the time of this digital and social revolution. This is the model that Brainly chose, as we didn't use TV ads or outdoor advertising but relied on the product itself. So having a design system was quite appealing to the business.

[00:04:39] The second selling point, and even more convincing, was the fact that without a shared language between design and front-end, we were losing money, because we were in so-called design and technical debt, and it was increasing with every implementation. We not only produced unnecessary code, but it was slowing us down. We didn't get full business support then, but we got a cautious one, with limited time for developing our shared language.

HTML-Sketchapp: a shared language

[00:05:11] Shared language sounds easy, right? It wasn't trivial. We were super lucky to have a front-end genius on board, Konrad Dzwinel. He spent some time getting to know Sketch and found out that this tool has an open file format, so he, as a programmer, could understand it and play with it. He thought: if Sketch files are JSONs, maybe JSONs could be Sketch files. Maybe I can translate HTML to Sketch. And he did it. He started small, from a simple rectangle export, and it took us weeks to make the complete usable tool. It was the world's first open source tool to export HTML code to Sketch.

[00:06:03] HTML-Sketchapp gave us a chance to export the entire style guide to the Sketch library: colors, text styles, symbols, all with proper naming, so that both teams could not only build from the same components but also name them the same way. Here's how the style guide exported to the design library works. The designer can make a design in minutes, and remember, it's all consistent with the style guide. Also, developers, seeing the names of text styles and components in the handoff, can implement it quickly. And finally, the product can look like the mockup, and our biggest issue is fixed. Creating shared libraries will cost you some time, but it will surely repay.

[00:06:50] We weren't able to use it right away, however, but as it was an open source tool from day one, other companies were. It was a little frustrating, but also amazing, because to our surprise the tool had some media coverage, for example by Smashing Magazine, and Protopie [?], which put Brainly on the merging of design and development timeline alongside Airbnb, Webflow and Google. We were stunned to see that HTML-Sketchapp was used by companies like SEEK, Yelp and, drum roll, Microsoft, which was quite shocking considering that our tool was made by a team of three people, or actually one person, because Konrad did most of the breakthrough work.

The PENCIL design principles

[00:07:37] Let's go back to the story, and to the design domain for a minute. At the beginning of the work on our design system, Brainly's design principles were defined. The whole design team participated in a workshop where we tackled the areas that are most important for us to achieve better quality in our product, and then I wrote down the principles with the PENCIL mnemonic in them. So the first letters of our principles form the name of our design system, PENCIL. Every principle also has a description and a question you should ask yourself when thinking about whether the principle is fulfilled.

[00:08:14] Later we made cards to help us work with them and give structured feedback at our design critique meetings, which, by the way, are named Sharpener. If the principle is fulfilled, we put the filled side on the table. If the principle is not met, we put the empty side on the table. Working with those cards is difficult during remote work, so one of our interaction designers, Maciek Nowak, created an online version. It works like that. Recently we added custom emojis to our Slack to give design principles feedback daily. And an internal anonymous Brainly design team survey showed that two years after their introduction, these principles are present in the daily work of 100% of our designers.

The circle of life: adding new components

[00:09:13] In the meantime, our developer Patrycja Radaczyńska, who was also a co-creator of HTML-Sketchapp, finished working on the first complete export of our style guide. It became our basic design library, used by all designers, and we could start refactoring elements of the system. This is a good moment to tell you about our process.

[00:09:37] When it comes to the implementation of mockups done within the product teams, our approach is quite classic. After the designers finish mockups done with the shared library, front-end codes it, and we are A/B testing the proposition, because every change is tested at Brainly. In this example, however, you can see the situation when a new component is introduced. The component is not present in the style guide or in the library. When a designer from the product team needs something we don't have in our style guide yet, we do it a bit differently. First, we discuss it within the design system crew, to check if it's possible to add it to our design system logically. Then it is designed and coded as a custom solution and put to test. If the version wins in A/B testing, we add it to our style guide and replace the custom one with this newly added component.

[00:10:37] Adding new components to the style guide without the process was making the design and front-end libraries out of sync in the past, so we created a circle-of-life process to keep those shared libraries up to date in the future, and this is how we roll. Here you can see our basic tooling. First, the designers make a mockup of the new components in Sketch. Then we use Abstract for handoff. Then we collaborate with developers on variant naming and last details, and then the code is made and sent to GitHub. Next, engineers export the newest version of the style guide, with those new components, as a Sketch file, and the design system core team overwrites the old Sketch file with the new one on our Google Drive. From that moment, all designers have an updated version of the library when they open their Sketches. And this circle of life, as some call it, goes on forever.

[00:11:42] If you are interested in how HTML-Sketchapp works, here's a little sneak peek. As you already know, HTML-Sketchapp turns HTML code into Sketch files. We need to create a page where we render components from the style guide, or whatever we want to export. The developers build the page with selected components to be exported. In this example, this will be the page with the color masks and text styles. Then they start Puppeteer, which opens that page and, using HTML-Sketchapp, exports the components to an .asketch.json file. Then we import the already exported files to Sketch using the asketch2sketch plugin. Its full name is Almost Sketch to Sketch. And voilà, color masks and text styles are now available in Sketch, and you can use them as a library for the whole design team.

[00:12:49] This and other processes, and the whole design system documentation, were kept in our Confluence. Later we migrated part of it to the public domain, but I will tell you more about it later.

Refactoring and how the team structure changed

[00:13:04] We had the export and the process, so we started auditing and refactoring. First text styles, then the new layout, spacing, colors, buttons, inputs, labels. Almost all elements had to be A/B tested, so it took us quite a long time. On this slide you can also see that our team grew. We hired interaction and visual designers, and after that we grew some more. Let me tell you how the structure of the teams changed over time.

[00:13:36] In the context of working with the design system, we divide members of teams into system contributors and its users. From this point of view, at first we had only one official contributor, and it was me, and a few product designers working in different product teams. From the beginning, the product teams were cross-functional. They had product designers, frontend and backend engineers, analysts and a product owner on board. It's just a scheme. Our product teams have a lot more people than before.

[00:14:11] After we hired more designers to the design system team, or core team if you will, we were not only making the design system but also supporting all product teams with the UI. At that time we still had fewer interaction designers than product designers. And then we grew more, and new product teams were formed. At this point, interaction designers were transferred to product teams, but they were still the main contributors to our shared libraries.

[00:14:45] In product teams, interaction designers work hand in hand with product designers, in a model we are calling "2 in the Box." In this model, designers work on the same features, but they give different perspectives and have different responsibilities. For example, Magda's main job is to satisfy the key needs of our users and to create solutions that will meet business goals. She also documents the development of our product. Maciek supports Magda in the creation of the ideas, and of course by visualizing them and adding delight with interactions and animations. He's also an advocate for the design system in the product team, so he's making sure there are no custom solutions, and if necessary he makes new components and documents them in our design system. The common goal of those pairs of designers is making a product that people love.

Zeroheight, buy-in and the secret sauce

[00:15:51] We migrated the hermetic documentation from Confluence to Zeroheight, with the sexy address design.brainly.com. Brainly people loved this, and then we gained actual buy-in across the whole company. Why? Well, one source of design truth was finally easily accessible for all. All teams, not only product teams, could find their resources, like styles, presentation templates, illustrations, et cetera. We also became visible to the design and dev communities. All that gave our leadership confidence to invest in the area, and we finally got the budget to hire dedicated developers for the design system core.

[00:16:36] design.brainly.com, our design system with HTML-Sketchapp in it, became a benchmark for many. It is a very valuable asset in our employer branding, internally and externally. Every design candidate is amazed by it. Here are a few recent testimonials, with my favorite one from Agnieszka Lewicka, who was our interaction designer candidate and now works at Brainly, who said, "This is so 2025." After the introduction of design.brainly.com, we got the yearly Impact Awards from the rest of Brainly's employees. That kind of recognition for design was unusual and very much needed in the team. On the slide, the beautiful design system crew celebrating this fact.

[00:17:34] And this is the design system secret sauce I was promising to reveal. The secret is dedicated people, and treating the design system not just as an isolated, strict set of design rules and components, but as a thing that connects people: designers, developers and everyone else. It's also good to have a lead who will keep the fire burning, but a lead is nothing without the people. Without them, design systems just don't work. But components are also an important part of the system.

Mobile, COVID and new tools

[00:18:11] In 2019 we continued work on shared libraries of atoms and began working on design libraries of bigger organisms and pages. Then COVID happened and our plans had to change. We couldn't build our team as fast as we would like, and we focused on supporting developers from product teams. We started making the foundation for the design system on mobile, with logic for things like dark mode, for example, delivered by Dina Sabat, our interaction designer.

[00:18:47] But when it comes to implementation of the mockups in mobile apps, there are challenges. While Brainly designers and developers working on web can collaborate seamlessly thanks to shared libraries made with HTML-Sketchapp, 2025 processes our got our new designer coded [?] on mobile apps. We have a similar situation to the one we had on web in 2017. Remember the ping-pong. With every implementation there is a lot of bug redlining that takes hours, or sometimes even days, to correct. We would love to see happy collaboration of designers and developers on the mobile app teams as well. We are planning to invest more in shared language development on mobile too.

[00:19:37] But as Brainly has very smart people on board, even in these difficult lockdown times our team was able to deliver something awesome while developing the product. One of our engineers, Bartosz Lorek, with the design support of Dawid Lewandowski, created a tool that gives designers full control over making lightweight, production-ready animated SVGs. So after HTML-Sketchapp, we had another tool from Brainly, SVG Animates [?], and like HTML-Sketchapp it is open source and free to use for all. The tool was used to update our homepage with a juicy animation of the Brainly community. On our Medium you can find an article with details, like this comparison of similar tools. This might be a game changer for your team, as the animations are light, with better control over your vectors. You can even use the puppet warp tool in Illustrator.

[00:20:46] With this new tool, we are planning to make a system for illustrations that can be easily edited and then animated to delight our users. We also started working on a design system for motion. For example, an effect [?] like this one can be standardized, described in detail when it comes to timing and these things, and used in other places on the platform for a coherent experience for our users.

[00:21:15] There is a lot of educating to do to connect all Brainly people through design, and to make quality that students, their parents and teachers will love. Olga Wysopal, our visual designer, is the design system's main educator, but the whole team is doing it as well. We are Brainly; we love educating.

Key takeaways

[00:21:42] To wrap it up, the key takeaways would be, first, how to convince stakeholders to start making a design system. Our world is changing fast, and users demand a product that not only works but works better than yesterday. Users appreciate consistency and delight, and a design system can help achieve that faster. Designers and developers are also changing. Today it's important to care not only about user experience but about employee experience as well, and a design system can improve it.

[00:22:16] If you are already developing a design system or starting to develop one, the key takeaways would be: shared language between design and development is the key. Use tools like HTML-Sketchapp to make it a process. Add gamification through your tools, like design principles cards; people like to play. Let people see what awesome things you are doing. Communication is crucial for design systems to get the necessary buy-in and adoption. Finally, treat the design system not as a strict library and set of rules, but as a thing that connects people. And that's all from me. Thank you.