Designing For Development: Building A Design System At Brainly

10 Jun11:20 – 11:50 UTCStage: Main StageTalk
Slides

Checking session availability…

Hang tight while we load the latest updates.

Design Systems offer an opportunity to consolidate processes, improve collaboration and speed up product delivery.
In this talk, Patrycja, guide us through the journey of how a small team from Brainly sparked a design system revolution in the world of developers and talk about struggles on the way to establishing a full blown Design System for the startup.

Designing For Development: Building A Design System At Brainly

Patrycja Rozmus at UXDX Community: Eastern Europe. Video: https://youtu.be/VgOKUJZVMck

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.

Why Brainly needed a design system

[00:00:04] 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 a product that is used by over 200 million users in 35 countries, which interestingly creates tensions in development. I will tell you how making a design system looks like in this environment. Today you will learn, obviously, how development of the design system looks like, and how we sold the idea to the business. I will also talk about design principles and our famous design system tools made in Brainly, and about the structure of our teams, actual buy-in across the company, and about the design system secret sauce that makes it all work. I hope you will be able to use some of those insights in your organization.

[00:00:54] Let's get started. The story begins in 2015, when our developers made the first commits to Brainly's 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 scenario look familiar to you? During the handoff both parties had to make decisions if given elements should be changed on the designs or on the production. Developers were often unable to make the product look like it did on mock-ups, and it was tiring for both teams, or even for the stakeholders who didn't understand why the final product differs from the prototypes they accepted. So it was a problem.

[00:01:48] Seeing those problems, I made an inquiry about our team's work with the style guide. All members of design and frontend teams participated in the 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 workshops confirmed that the biggest issue is lack of shared libraries and logical structure in them. We decided we have to address this, and started working on the design system with the shared language between the teams as a priority.

Brand at the heart, and selling it to the business

[00:02:28] After some research I came up with this. You see, Brainly's design system needs to focus not only on the product but also on marketing. It's not so common, but in our case 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 still manage to get that growth. Imagine that. So, to help non-designers design for Brainly, we needed also libraries, guides and templates for marketing initiatives. In detail it looked like this. We have brand in 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.

[00:03:22] But before we did start I needed to sell the idea of the design system to the business, and it wasn't easy, as some of you might know. 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 became an industry standard, but then they were not. One of the main selling points was the quality of the product and its consistent branding, that now are more important than ever. In today's digital world of social media, users become brand ambassadors for their brands, for example, and they have more impact on their 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 don't use TV ads or outdoor advertisements but rely on the product itself. So having a design system was quite appealing to the business.

[00:04:26] The second selling point, and even more convincing, was the fact that without 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 rather a cautious one, with limited time for developing our shared language.

html-sketchapp and the shared language

[00:04:58] Shared language, easy, right? Actually it wasn't easy, nor trivial. We were super lucky to have a frontend 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. Of course he started small, from a simple rectangle export, and it took us weeks to make the complete usable tool.

[00:05:37] html-sketchapp was giving us a chance to export entire style guides to a Sketch library: colors, text styles, symbols, all with proper naming, so that both teams can not only start building from the same components but also call them the same way. Here is how the style guide exported to a 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 very quickly, and finally the product will look like it does on mockups. Creating shared libraries will cost you some time but it surely will repay.

[00:06:19] We weren't able to use it then, 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 Prototypr[?], 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, drumroll, 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.

Pencil: the design principles

[00:07:05] At the beginning of the work on our design system, branding design principles were defined. The whole design team participated in a workshop where we tackled areas that are the most important for us to achieve better quality of our product. Then I wrote down the principles with the Pencil mnemonic in it, so the first letters of our principles form the name of our design system, Pencil. Every principle has also a short description and a question you should ask yourself when thinking if the principle is fulfilled.

[00:07:49] 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 are putting the filled side on the table. If the principle is not met we put the empty side on the table. Obviously working with those cards is difficult during remote work, so one of our interaction designers, Maciek Nowak[?], created their online version. It works like that.

[00:08:24] In the meantime our developer Patrycja Radachinska[?], who was also co-creator of html-sketchapp, finished working on the first complete export of our style guide. It became our basic design shared library used by all designers, and we could start refactoring elements of the system.

The circular process and the audits

[00:08:45] This is a good moment to tell you a few words about our process. We created a circular process to keep those shared libraries up to date in the future. This is how we roll. Here you can see our basic two links. First the designers make mockups in Sketch, and then we use Abstract for handover. Then the code is made and sent to GitHub. Next, designers export the newest version of the style guide as a Sketch file, and we overwrite the old file with the new one on 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. This and other processes, and the whole design system documentation, are kept on our Confluence. Later we migrated part of it to the public domain, but I will tell you about it later.

[00:09:46] We had the export and the process, so we started audits and refactoring. First text styles, then layout, spacing, colors, buttons, input labels. Almost all elements had to be tested in A/B testing, because everything is tested at Brainly, so it took us quite a long time. On this slide you can see our team grew. Brainly hired interaction and visual designers, and after that we grew some more.

How the teams are structured

[00:10:14] Let me tell you how the structure of the teams changed over time. In the context of working with the design system we divide members of teams into system contributors and its users. From the design point of view, at first we had only one official contributor, 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 of course a product owner on board. By the way, this is just a scheme. Our product teams have a lot more people than before.

[00:10:52] After we hired more designers to the design system team, our 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 also new product teams were formed. At this point interaction designers were transferred to product teams, but they were still main contributors to our shared libraries.

[00:11:22] In product teams, interaction designers work hand in hand with product designers in the model we are calling two in the box. In this model designers work on the same features, but they are giving different perspectives and have different responsibilities. For example, Magda's job is to satisfy 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 by visualizing the ideas and adding delight with interactions and animations. He's also an advocate of the design system in the product teams, so he's making sure that there are no custom solutions, and if necessary he makes new components and documents it in our design system. But the common goal of that pair of designers is of course making a product that people love.

Getting buy-in, and the secret sauce

[00:12:22] Coming back to the design system story, we migrated our hermetic documentation from Confluence to zeroheight, with a sexy address, design.brainly.com. Brainly people love this. And then we gained an actual buy-in across the company. Why? Well, one source of design truth was finally easily accessible. All teams, not only product teams, could find their resources, like styles, presentation templates, illustrations. We also became visible by design and dev communities. All that gave our leadership confidence to invest in the area, and we finally got budgets to hire developers for the design system team.

[00:13:10] And we also got the yearly impact award from the rest of Brainly employees. That kind of recognition for the design domain was unusual and needed. On this slide, the beautiful design system crew celebrating this fact. And this is the secret design system 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 the lead is nothing without the people, and solitary models of design system just don't work.

Covid, SVG animation and what's next

[00:13:52] With increased motivation 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 to, and we focused on working with and supporting developers from product teams. We started making the foundation for the design system on mobile, with logic for stuff like dark mode delivered by Dina Sabat[?], our interaction designer.

[00:14:28] But as Brainly has very smart people on board, even in these difficult 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 by Brainly, SVG Animate, and like html-sketchapp it was open source and free to use for all.

[00:15:05] The tool was used to update our home page 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 also for your team, as the animations, as I said, are light. With better control over your vectors you can even use the Puppet Warp tool in Illustrator. With the new tool at our stable we are planning to make a system for illustrations that can be easily animated to delight our users. And still 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. Ogave Sopow[?], 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. And that's all from me. Thank you.

Speaker