The Design System at Qulture.Rocks, Part I: (re)organizing an existing Design System

Illustration made for this article by me.

When I arrived at Qulture.Rocks, in mid march of 2021, I was aware of some of its challenges as an expanding start-up, on its rapid way to becoming a scale-up. Fast growing teams, onboarding new members almost weekly, and the need for new and more official processes were all laid out on the table from day one. There was one challenge I was particularly excited to face: revisiting their existing Design System, its components, definitions, and documentation.

A Design System (which will be referred to as DS, from now on) is, in short, a set of design definitions and patterns that translate to code, aiming at creating a library of reusable UI components. It is usually accompanied by its own documentation and style guide.

As a Product Designer, I wasn’t new to Design Systems. I’ve had some experience with it in my previous job, and honestly the term became somewhat of a sensation since 2016, when Brad Frost published his book Atomic Design. It’s worth noting, though, that companies and brands have been using pattern languages and design definitions like the ones we find in a Design System since the 1960s.

So when I started looking into the Design System we already had here at Qulture.Rocks, I was more than looking forward to the challenge, and in this article I’ll share some of the things I’ve learned in the process.

What is Qulture.Rocks’ Design System?

Even though Qulture.Rocks was founded in 2015, it was only in 2018 that a product design team was officially put together. By this time, however, we already had a few products in store, and a digital platform to hold them all together. Fast forward to 2021, we are now a company with more than 150 employees, and 3 Product Designers onboard. Today, we offer an operating system for people management, and we have on our portfolio products for performance reviews, OKRs, feedback, 1:1 meetings, individual development goals, succession, climate surveys, among many others. We aim to help Human Resources and People Management teams become more strategic and better understand their employees.

It is only fair to imagine the amount of complexity there is in designing, building, and maintaining so many different products. Working out better definitions and guidelines to achieving that perhaps was the natural start; and with that was born our official Design System. It holds together all of our design decisions, regarding user interface design and user experience, transformed into reusable libraries with coded components and patterns. It helps scale and speed up design and development work, while aiming for a better and more coherent experience for our users.

Why are we revisiting our Design System?

While it must work for our teams and their products, we understand our Design System also as a product on its own: it has users, it solves specific problems and it should be constantly iterated and improved. It’s part of the process to revisit your design system as time goes by and your products and organization change.

We understand our Design System as a product on its own.

When I first laid eyes on Qulture.Rocks’ Design System, it already had a starting point. A lot of components were already defined and even coded, both from the design and the engineering perspectives. My job was not to build something new “from the ground up”. I took upon the excellent work already done by my fellow designers and engineers, and aimed to make it better, taking it one step further. How could I make it more organized, less redundant, clearer on its rules and decisions, more accessible? This was the real challenge at hand.

While running a component inventory for our app, we found out that we had more than 20 different types of buttons across our screens. Between text buttons, icon buttons, links, each one with different colors, borders, corner radius, icons, sizes, margins, paddings, etc. This not only meant that for each type of button someone had to design, code, and implement it, but also that our users were being exposed to these many buttons, perhaps for the wrong reasons.

Some of the (numerous) buttons we had on our app.

Some of the questions I asked myself and the team were: do we really need these many buttons? Is it clear to everyone involved why one type of button should be used in any given context and not the other? Is there a way to classify and justify every type of button we want to use? Shouldn’t we be reusing assets more than creating new ones from scratch?

In short, and to expand on that, I would say that there are four main reasons why we are showing some love to our Design System right now:

1. We aim to improve our user’s experience by:

• improving our visual coherence across multiple products and features;
• reviewing accessibility aspects of our components;
• modernizing some “old” components (still coded in angular);

2. We want to close the gap between our product and Qulture.Rocks’ new marketing brand identity, as much as possible;

3. We want to make product designers’ and software engineers’ lives better by:

• organizing our components and documentation;
• laying out our usage guidelines for each component and element we use;

4. We understand that a Design System is a product in itself: we are never truly done with our Design System, and it should always be improved and iterated over.

Defining a structure

One of the first books I read while studying Design Systems, back in 2019, was Brad Frost’s Atomic Design. In it, Frost’s approach to dividing a Design System is very, well, systematic: he suggests a Design System should be divided into atoms, molecules, organisms, templates, and pages, according to the level of complexity of the component.

Another thing that I read in the book that really stuck with me, was that it was OK if those names and categories didn’t work for you and your organization. Defining a structure for your Design System must work for you, your teams, and your products.

With that said, I wholeheartedly faced the structure we had on our Design System at Qulture.Rocks. It was divided into two broad categories: one called Style, with color, icons and illustrations, and one called Web, composed of absolutely everything else: buttons, cards, forms, grid, shadows, typography, wizards, etc.

Those categories were too broad and not clear enough for me. So my team and I took it upon ourselves to rename and redefine what would fit into what category. We benchmarked other solutions and, taking under consideration the level of complexity of our elements, we ended up with 3 categories:

1. Foundations: where our design principles and variables of style live. This is where people will find our design tokens as well (which is a topic for another article, given the tremendous work we had in renaming our tokens). Here we have definitions of Space (grid, stack, inline, inset), Color, Typography (line height, font size, font family, font weight, among others), Border, Shadow, Icons and Illustrations.
2. Components: this category encapsulates all the smaller, indivisible parts of our UI. Here we have Buttons, Links, Breadcrumbs, Tags, Checkboxes, Radio buttons, Tooltips, Toggle switches, and many others.
3. Patterns: and lastly, we decided to gather all the more complex parts, formed from one or more components put together: Modals, Toasts, Cards, Menus, Tables, Filters, etc.

This new structure is meant to facilitate reading our DS documentation. It’s OK that we didn’t follow Brad Frost’s “atomic division”. We came up with a structure that works for us, and part of the effort in building or revisiting a Design System is finding a logic that works best for you.

Keeping engineers in the loop

I really hope this is not the first time you are hearing this, but as a Product Designer, you should always be in touch with developers and software engineers, especially when building a DS. This is a product aimed not only for the design in itself, as I’ve said before. Tech folks will also use your company’s DS, even if it’s just to access the coded elements of it. However, all the definitions and structure holding your DS together are indirectly affecting their work: if a rule or guideline is not clear, it’s their job that gets slowed down.

Here at Qulture.Rocks we constantly communicate with engineers when building our products, and while revisiting our DS, I would always consult with them and listen to their valuable suggestions. Even while they were working on coding our buttons, a lot of new questions were raised, and the answers to these questions became new policies on our design documentation.

Honestly, some of the best work I’ve done was only possible because front-end developers were also interested and invested in revisiting our DS’s definitions (a special shout out to Jonathan Suzuki for his excellent work). Remember: the coded part of your DS will be built by software engineers, so it is very important to establish a constant stream of communication between design and development from the beginning of any DS project or initiative.

Let’s call it a day and talk about next steps

If you could take away one thing from all that I’ve shared in this article, I would suggest it be this:

Design Systems are a lot of work.

I still want to share on how we designed the documentation for our DS, or how we named our design tokens, but that’s subject for another time.

At the end of the day, something we should keep in mind is that Design Systems are extremely helpful in maintaining consistency and improving productivity, but they are not a silver bullet for building interfaces. Even though they help, they don’t solve all the problems we face when designing and coding products. When studying other companies’ journey with their own DS, we notice that each one is different, and that the definitions of a DS and how you implement one always change according to the context, and the design and engineering maturity. I try to face our DS from this perspective.

Our next steps are bountiful: we’ve only just started to cover our elements and components, and we still have a lot of definition to do. However, so far, I am happy with Qulture.Rocks’ journey with its Design System. I’ll say our foundations are well laid out, and I am looking forward to what we’ll be building next.

You can connect with me on LinkedIn, and if you liked my illustration for this article, feel free to check out my art at fernandaperalta.com ;)