Castle: A Design Ops Project and the Processes in Developing a Successful Design System 🚀

About

This article is a summary of the main concepts absorbed during the Meiuca Design System & Ops training. I will share a bit about my experiences, process tracking, and the final result of my project.

Since it will be a long article, I’ve separated the main topics covered so you can consume them at your own pace:

Module 1: Setup

• Company Overview

Module 2: Discovery

• Brand Selection and Properties

• Design Principles

• Component Inventory

Module 3: Design

• Design Tokens

• Components

• Component Handoff

Module 4: Development

• Technology Choices

Module 5: Documentation

• Types of Documentation

Module 6: Design Ops

• Team Responsibilities

• Tools Radar

• Ops Processes

Module 1: Setup

⚡️ Company Overview

In this initial activity, the focus was to understand the current scenario of my company and map out the roles that are currently defined, just to grasp how this organization would look in real life and start seeing something tangible.

Structure of the fictional squad

In my case, I followed the scenario of a consultancy that serves various clients, as it is the context I am currently in professionally. I tried to anticipate all the main questions and map out the processes, priorities, and the overall company culture, in addition to listing the stakeholders who interact with this system in some way.

Module 2: Discovery

🤩 Brand selection and properties

After this initial setup, we now dive into the actual objective of the course, which involves creating a Design System from scratch. With that, we step out of the context of my current company and enter a fictional activity where we choose a major market brand and start developing its DS.

Among the brand options to choose from in the training, I went with Airbnb, which is well-known and was assigned for this exercise as an intermediate-level challenge for creating the DS, due to its team divisions, which made the inventory process a bit more difficult.

For curiosity's sake, the other market brands that could be chosen were Pinterest (beginner level) and WhatsApp/Instagram (advanced level).

For this second activity, our goal was to review the brand guidelines and specify everything it currently offers: typography, colors, application, and accessibility.

After validating the colors, I focused on identifying the variations of typography weights and suggested an optimized web font family with some use cases already mapped.

🎨 Design Principles

At this stage, it was necessary to think about the Design Principles I identified for Airbnb. The idea is to help build the brand experience and guide the team toward common goals.

In addition, it was also time to define a look and a name for my DS. As I already gave a spoiler at the beginning of the article, 🏰 Castle was the name chosen, and I'll provide more context on the reason now.

Airbnb has an extensive catalog with various types of apartments, houses, and even, as some know, castles! Now thinking in a more abstract way, any house can be your own "personal castle": a place where we feel safe and comfortable, regardless of the physical size of the space. Our castle would be a very well-structured and organized place, perfect for the owner, containing everything needed for their experience.

I believe the brand offers exactly that with its purpose. No matter where the user is, the idea is that they will always feel welcome and truly at home in their own castle. It also serves as a guide, where you can easily identify if you're lost and the castle's flag up high directs you where you need to go.

🧐 Component Inventory

Now it starts to get a bit more laborious. In this step, the focus is to identify the needs of the DS and think about the component backlog, that is, the list of features I would want my DS to have, both for Web and for App. These are very different libraries, and so in this phase, I had to consider both variations and their specific needs.

So, like a kind of "reverse engineering," I started taking screenshots of Airbnb's current interfaces (already provided by the course) and trying to break down what I could identify in terms of components, patterns, and what might actually be some kind of inconsistency.

Exemplos de algumas inconsistências encontradas

It was also requested that we divide these components into two fictional teams for the purpose of the exercise. In the case of Airbnb, we had the possibility to split them between the "Find" team, responsible for the journey until the user completes a booking, and the "On Trip" team, which handles the experience from the moment the booking is confirmed.

Examples of components identified for both teams

Just as we thought about inconsistencies that could be categorized as "Not in DS" and the team-specific components (Team Components), it was also necessary to think about what would be the core components, meaning the components that act as key elements and serve both teams.

Module 3: Design

📐 Design Tokens

Now, as I entered the design module, I delved deeper into the concept of Design Tokens, which is essentially a type of standardization between styles and their possible variables.

I also started to better understand the role of component naming and why this is so important in a design system. By the way, it’s a very relevant guideline from the course that’s worth emphasizing here when thinking about this definition:

What + Variable + Semantics (e.g., $color-brand-light)

This helps a lot when thinking about naming to keep it as generic as possible, allowing the component to be reused in various contexts.

So, I started defining in the context of Airbnb where I initially wanted to go, focusing on colors and typography.

I brought a slightly different color standardization logic than usual, using the MailChimp DS as a base, where I separated them as follows:

• Brand Color: the main color of the brand as a whole;

• Functional Colors: these are colors that complement and support the main color in certain contexts;

• Feedback Colors: also support colors, but with a clear purpose of providing feedback like success, alert, error, and notification.

So, I didn’t use the common association of coral color for Guest and turquoise for Host. Because, when navigating the site, even knowing this detail and understanding the context in which it was applied, it is still possible to see coral included in those pages as well. So, for me, there is still a need to highlight the main color, and in my view, I see turquoise more as a functional color rather than the main one, regardless of the category. But of course, this is just my interpretation in this study.

Example of a screen created for the host using coral for some highlights.

And for the typography design tokens, I chose the Poppins font as the primary one because it’s a font I really like and use frequently (useless trivia: it’s even the name of my cat haha) and Roboto as the secondary font.

We also considered variations in size, weight, and line height. It's interesting to observe the chosen nomenclatures for each category.

Components

In this activity, I understood in practice the difference between Base Components and Components, where Base Components are the essential components of your DS designed from the Design Tokens, and Components are the elements that can be built from the base. That’s why it needs to be done in this specific order, thinking from the smallest to the largest.

Base components example.

Pattern components example.

I also planned some templates to help me define the components, considering the context in which they would be inserted.

🔍 Component Handoff

In the last activity of the design module, it was time to think about the handoff to the technical team, that is, to specify all the variables and other details that we want to make very clear for the developers. This step is very helpful and makes all the difference for the tech team (and they will probably cry tears of joy if you share such material with them).

Here I brought an example of handoff for just the base component of a generic card. Notice how many variables a single component can and should contain. The green and orange details are spacing variables, also documented in this material.

This design module was certainly the most challenging, precisely because it required defining and mapping every detail of the components, but at the same time, it was the most fun to do and to be able to complete its activities over the set weeks.

Module 4: Development

Technology Choices

All set, ready to code? Not yet! It’s time to better align with the tech team and check all the necessary information to make some of the key decisions for the design system.

Defining the stack, frameworks, whether it will be a hybrid or native language, squad structure, and even hierarchy are some of these points.

Example of a scenario to be addressed with the tech team.

And no, you don’t need to know how to code or understand all this content. But it is extremely important to be 100% aligned with the tech team, at least to identify the points above and feel confident with these decisions, because this will have a significant impact on how you’ll map out the next steps of this process.

Module 5: Documentation

🗂 Types of Documentation

My favorite part, who guessed right? At this stage, it’s important to gather everything that has been mapped and categorize all this information according to the profiles and contexts of each type of documentation. We have a few types to consider:

• Conceptual documentation: This is the entry point for people to your DS and focuses on presenting and contextualizing the processes behind its development in a playful, simple, and visual way. It could be an open website for the market, for example.

• Functional documentation: This is where we specify instructions with styles, principles, and processes. It can be done in Zero Height, for example.

• Technical documentation: This is where we define all the more detailed specifications about the DS and involve a lot of technical terminology. It can be done in Storybook, for example.

Types of documentation defined for Castle

It is ideal that each documentation gathers the main specifications of other documentations, even if it seems redundant initially, as it is necessary to reinforce the main concept of each of the definitions.

Module 6: Design Ops

🙋🏻‍♀️ Team Responsibilities

This stage is about understanding the role of the team within this design ecosystem in the company and helping to know what to expect by addressing questions like:

What is / What is not / What it does / What it doesn't do / What it will do

In addition to thinking about the structure of this team: levels, profiles, formats, etc.

Example of a structure focused on consultancy serving an external client.

✏️ Tool Radar

This stage is about ensuring good tool choices and a consistent process. In this case, it's necessary not only to define which tools will be used but also to map what can be tested and monitored for the near future. Remember to avoid making major changes frequently, as this will impact the entire design team, and consequently, the technology team. Is it the right time to migrate to Figma, for example? How will it affect your design processes? Everything needs to be evaluated.

👩🏻‍💻 Ops Processes

Lastly, but not least, it's important to understand the role of Design Ops as a team itself.

It’s crucial to list all processes, imagining that your users are the team members themselves, and map each one as you believe the ideal flow would be. Always thinking about how to improve them and make them more efficient.

For the exercise, we chose one of these processes and specified what the possible success metrics would be to validate its performance. But of course, in a real context, it would be necessary to foresee all scenarios and structure metrics for each one of them.

And we mapped one of the chosen processes in a flowchart to understand its journey as a whole, the necessary actions, and most importantly, the tools involved in each stage.

Flowchart based on the Vanilla Pattern for creating a new component and potential tools outlined.

Final Considerations

Below, I share the material with all the specifications of components, variables, and processes used throughout the development of Castle. It was a really cool experience to create it from scratch, and I believe this practice gave me a more advanced view of how to design and analyze this and other design contexts.

It was a long process, as I believe you could notice, but very rich and worthwhile to undertake. I recommend going through each step and taking time to understand each of these concepts, as it will make all the difference in your growth as a designer and in your overall perspective.

You can find the complete Figma file here