SUMMARY
Project Description: Design System project for  Descomplica, Brazil's largest Edtech.

Goals: (1) Deliver the first version of Descomplica's design system, including tokens, basic components, and components for the product and marketing teams. (2) Streamline design and development processes. (3) Make interfaces, codes, and experiences across the company more consistent. (4) Scale, document, and centralize the main components and their best practices, and lessons learned. (5) Plan roadmap, product governance, and communication channels.

My Role: I was the UX designer representative of the marketing team, allocated with a product design representative, a design director, and a team of developers.
Process: Mapping Organizational Context > Component Inventory > System Architecture > Roadmap > Design principles > Design Tokens > Components > Documentation > Communication Strategy > Analytics > Continuous Optimization

Results: After some back and forth, and some team changes, the first version of the D.S. was launched in April 2022. The D.S. is being promoted internally in the design and development teams, and a new version should be released after a relevant round of feedback.
PROJECT INTRO & CONTEXT
The largest Brazilian startup focused on distance education, Descomplica started out with courses to prepare students for university admission exams, a country-wide practice called "vestibular" and "Exame Nacional do Ensino Médio — ENEM", then ventured into higher education back with undergraduate and graduate programs, and open courses.
The institution has different teams for each section of education: "ENEM & Vestibulares", Undergraduate and Graduate programs, and Open Courses. In Design, the team had branches for product design, brand design, and marketing (Conversion Rate Optimization — CRO, CRM, Social Media.)
During my time as UX designer in the marketing team, I observed that the different teams share only a few components, but most of the produts have desorganized files with multiple versions of the same component, and knowledge and leanings get lost because they are not widely shared. There is a need for standardizing components, better file organization, process optimization, and better consistency in the interfaces of many sections.
In the section I worked for (CRO/Undergraduate and Graduate programs), the files had no standard and did not follow any style guide. The graduate website did not even have a file on Figma. Brand guidelines and pre-defined text styles were followed with development, but not componentized or named properly.
The company did not yet have a team dedicated to Design Ops, but there was an embryonic initiative to bring together a marketing representative (Me), a product representative and a design director to have discussions with the Dev Ops team and start this project.
As I worked in a CRO team, my working time was divided in the two teams.
COMPONENT INVENTORY
In collaboration with the design team, we started the project by creating a canvas with the main screens of the product each employee worked on (LMS's, CRO, CRM, Checkout, etc.) After centralizing all stages of the main products' flows, we could more easily identify which components we needed, which were the most frequent, which belonged to only a few teams and which were common to all. On the canvas we were also able to document demands and requirements that the design team already had in mind regarding some of these components.
The components were categorized as Core (common to all teams), Marketing or Product (these were team-specific).

Core Components
Accordion, Alert, Avatar base, Banner, Brand, Breadcrumbs, Button, Button Group, Button Icon, Card Base, Input Checkbox, Input Password, Input Radio Button, Input Search, Input Select, Link, Modal, Overflow Menu, Switch, Tab, Tag highlight, Tag select, Tooltip.
Marketing Components
Hellobar, Label, Countdown, Button CTA, Exit Intent, Card Image, Headings Marketing.
Product Components
Avatar Product, Input Text area, Notification, Step, Switch, Headings Product.

Component Inventory: we analyzed the most frequent components and styles in Marketing and Product's interfaces.

SYSTEM'S ARCHITECTURE
After analyzing the inventory, we started creating the Design System's architecture. The Desco System library's organization reflects its distribution in the different sectors of Descomplica: 1) the educational, in which there are teams for ENEM & Vestibulares, the Undergraduate program, the Graduate program, and Open Courses; 2) the Marketing sector, whose focus is on sales and lead capture, CRO, CRM, Marketing, Social, Checkout; and 3) the Product sector, whose focus is optimizing the LMS experience.
With these sectors in mind, we could map the component organization in categories:
Core Components are shared with all teams;
Team Components are team-specific. In Desco System, there were libraries for Marketing Components and Product Components. All the Marketing teams use the same component library, that is different from the component library that all the Product teams use.
Desco System's Design Tokens were divided in Global Tokens, whose values are all the same for all teams, and Brand Tokens, whose values vary between ENEM & Vestibulares Brand Tokens and Undergraduate, Graduate programs, and Open Courses Brand Tokens. In summary, ENEM & Vestibulares brand tokens have light backgrounds and the others have dark backgrounds.
After talking it through with the developers, all Desco System's components and tokens are to be implemented using React and Vue.
In Desco System, we used the following nomenclature:
• Design Tokens are the named variables used to build basic components and are divided in Global Tokens and Brand Tokens.
• Base Components are basic components, created after the tokens, e.g. buttons, inputs, links, etc.
• Components are created by combining base components, or base components and tokens.
Tokens, Base Components and Components are named after the component name + the variable, e.g.: Card + Image + Desktop +Light + Default.

Token organization and component library, according to the Descomplica's sectors that use design assets and work on development. 

DESIGN PRINCIPLES
In a meeting with the Branding team, we determined Desco System's design principles, which were used as guidelines to evaluate our design creations beyond aesthetics. Principles can bring objectivity and scale to day-to-day decision making. Desco System's design principles are the following:
Universal
Learning is for everyone. So our design must be functional to all users, all cultures, all languages, all devices, all stages of life. Our products and visual communications must be inclusive, with accessible and universal discourse, and embrace cultural differences and diverse social contexts.
Fun
We want people to learn that learning is a pleasure, not a sacrifice. We want to captivate and be a community. To amuse, to entertain, to engage. Our communication must emphasize this joyful and motivating quality.
Human

We pledge a high standard of accessibility, honesty and respect to people. We place their needs first.
Objective
Clear and objective communication that guides people through a simple and intuitive journey, where their time and attention are respected.
DESIGN TOKENS
Global Tokens
Tokens whose value are the same for all the teams. Those are divided in:
Brand Tokens
Tokens whose values change according to the team that use them: ENEM & Vestibulares, the Undergraduate program, the Graduate program and Open courses. The Brand Tokens are the following:

• Brand Colors;
COMPONENTS
Core Components
Team Components
MARKETING COMPONENTS
PRODUCT COMPONENTS
COMMUNICATION & STRATEGY
Internal Communications in the Design System Team
The Desco System design team, as a product developer, need to promote the use of the product, communicate its updates, qualitatively and quantitatively test its features, keep documentation for the developers up to date, and optimize its internal processes among the team members.
Onboarding & Design Ops
Initial instructions for new employees were developed so those could help people adopt a frequent and regular use of the design system and better manage its files, folders, and libraries.
Organização de recursos gerais
ANALYTICS FEEDBACK
What is working, what isn't
Even when we seek a frequent dialogue with the design team, we know that we don't always get a feedback on what is working and what isn't. That is why it is important that we look at the component and style data usage.
In Figma, we manage to acess analytical data on the usage of component library to see which are the most used components and which are not being used regularly or at all, so that we can investigate why, if we can discontinue some, or if there are adjustments to be made. Components that are being detached from the main instance may indicate they need to be updated.
How Libraries are used
Como as bibliotecas estão sendo usadas
It is possible to compare the use of 2 or more libraries in a period of time and then compare it to the adoption of a new library and the discontinuation of an old one.
The design system data usage analysis can help us mesure the adoption of libraries in the beginning of the development process of the design system and give insight on the next releases.
DOCUMENTATION
Conceptual and Functional Documentation
We used Zeroheight to document the topics below:
Introduction on the Design System, a summary of the documentation and a shortcut to its most used tools;
News on the latest versions of the DS;
What is it? Concept and Reason for the design system;
of the design system;
Team of who works on maintaining, optimizing and escalating the system.
Frequent Asked Questions on the design system.
Technical Documentation
Figma + Storybook
Design Tokens
List of all DS tokens: color, font-family, line height, font weight, font size, border radius & width, opacity & shadow level, spacing inset, stack, squish, and inline.
Guidelines
Basic description of the DS basic elements: grid, accessibility, content, icons, illustrations and motion.
Components
Use, layout, content, behavior and interaction of all DS components.
CONTINUOUS OPTIMIZATION 
For the release of version 1.0, the access to the concept documentation in Zeroheight was not considered a priority, because we believed the adoption of styles and components in Figma was more important for the design team. As a first step, we selected a few team members of the Product and Marketing teams to use the new libraries as a first percentual test before releasing the product to the entire team.
The main idea of this work is to qualitatively and quantitatively test the use of the libraries, components, and styles. In parallel, we will also expand the components list and optimize the components already in use.
We still do not have many data on usage, but there are a lot of excitement about the new product and its development possibilities.

Veja também:

Back to Top