DATE:
2025
ROL:
Design System Specialist
ABOUT THE PROJETC
Journeys is a design system specialized in digital solutions for the tourism sector. The central objective was to develop a solid visual foundation that ensured consistency and scalability across the ecosystem. The system was conceived to articulate two products with distinct needs: a camping network app in Spain (focused on managing stays, activities, and events) and a department registration and management platform.
Journeys is a design system created for digital products in the tourism industry. The main goal of this project was to design and develop a visual foundation that ensured consistency and scalability across different digital products. The system was conceived to support two different brands, each with its own visual identity, while maintaining coherence without sacrificing flexibility.
DATE:
2025
ROL:
Design System Specialist
FIRST STEPS
FIRST STEPS
The first step was to analyze the company's ecosystem, a firm in the tourism sector that had previously developed its products in isolation through external teams. This led to a critical need to unify components to ensure both consistency and technical scalability.
To address this challenge, I proposed starting with a UI inventory, collecting and documenting all existing components and design patterns. This process provided a clear overview of the products' current state, helped identify inconsistencies, and established the solid foundation required to build the system.
The first step was to analyze the company's ecosystem, a firm in the tourism sector that had previously developed its products in isolation through external teams. This led to a critical need to unify components to ensure both consistency and technical scalability.
To address this challenge, I proposed starting with a UI inventory, collecting and documenting all existing components and design patterns. This process provided a clear overview of the products' current state, helped identify inconsistencies, and established the solid foundation required to build the system.
The first step was to analyze the company's ecosystem, a firm in the tourism sector that had previously developed its products in isolation through external teams. This led to a critical need to unify components to ensure both consistency and technical scalability.
To address this challenge, I proposed starting with a UI inventory, collecting and documenting all existing components and design patterns. This process provided a clear overview of the products' current state, helped identify inconsistencies, and established the solid foundation required to build the system.
THE CORE CHALLENGE: TWO BRANDS, ONE FOUNDATION
THE CORE CHALLENGE: TWO BRANDS, ONE FOUNDATION
The real challenge wasn't just building a design system, but creating one that worked for two visually opposite products. The camping app required a warm, natural identity with friendly typography, while the property management platform demanded a corporate, clean, and functional aesthetic for daily professional use. The risk was ending up with two separate systems, doubling maintenance and losing the efficiency of a common foundation.
To solve this, I proposed separating the architecture into two layers: a shared foundations layer (taxonomy, spacing, breakpoints, and component logic) and an independent identity layer per brand, implemented via Figma color modes. This allowed a single component to exist once while adapting visually to each brand.
The real challenge wasn't just building a design system, but creating one that worked for two visually opposite products. The camping app required a warm, natural identity with friendly typography, while the property management platform demanded a corporate, clean, and functional aesthetic for daily professional use. The risk was ending up with two separate systems, doubling maintenance and losing the efficiency of a common foundation.
To solve this, I proposed separating the architecture into two layers: a shared foundations layer (taxonomy, spacing, breakpoints, and component logic) and an independent identity layer per brand, implemented via Figma color modes. This allowed a single component to exist once while adapting visually to each brand.
The real challenge wasn't just building a design system, but creating one that worked for two visually opposite products. The camping app required a warm, natural identity with friendly typography, while the property management platform demanded a corporate, clean, and functional aesthetic for daily professional use. The risk was ending up with two separate systems, doubling maintenance and losing the efficiency of a common foundation.
To solve this, I proposed separating the architecture into two layers: a shared foundations layer (taxonomy, spacing, breakpoints, and component logic) and an independent identity layer per brand, implemented via Figma color modes. This allowed a single component to exist once while adapting visually to each brand.
Foundations
DESIGN TOKEN TAXONOMY
DESIGN TOKEN TAXONOMY
A clear and well-structured taxonomy for design tokens was developed to serve as a common language for the entire system. We based it on the methodology proposed by Nathan Curtis, adapting it to the specific needs of the project and the team’s technical capabilities. This made it possible to create a flexible and practical structure, facilitating the management of colors, typography, spacing, and other visual attributes.
A clear and well-structured taxonomy for design tokens was developed to serve as a common language for the entire system. We based it on the methodology proposed by Nathan Curtis, adapting it to the specific needs of the project and the team’s technical capabilities. This made it possible to create a flexible and practical structure, facilitating the management of colors, typography, spacing, and other visual attributes.
COLORS
COLORS
Color palettes were defined, including primary, base, and feedback colors, among others. For the primary colors, two main palettes corresponding to each brand were used, implemented through color modes in Figma. This setup facilitates the reuse of the same components across different visual identities. To organize the colors, two collections were created in Figma:
Globals: Groups general categories (primary, base, feedback) that serve a global function in the design.
Alias: Assigns a specific and semantic use to each color, defining its exact application within the interface.
Color palettes were defined, including primary colors, base colors, and feedback colors, among others. For the primary colors, two main palettes corresponding to Brand 1 and Brand 2 were used, implemented through color modes in Figma. This setup makes it easier to reuse the same components across different visual modes.
To organize the colors, two collections were created in Figma. The first, called “Globals,” groups primary, base, feedback, and other general color categories that serve a global function in the design. The second collection, named “Alias,” assigns a specific and semantic use to each primary color, specifying its exact application within the interface.
TYPOGRAPHY
TYPOGRAPHY
Tokens were defined for the various typographic attributes: font family, sizes, weights, line height, and letter spacing. These act as independent variables that ensure consistency across the entire system. Since Figma does not yet support composite typography variables, once these tokens were created, specific text styles were defined by combining them.
Text styles are named semantically to make them easier to use (title, body, caption, or link), each with size and weight variations tailored to its specific function.
Tokens were defined for the different typographic attributes: font family, sizes, weights, line height, and letter spacing. These tokens act as independent variables that help maintain consistency across all text in the system. Since Figma does not support combined typography variables, once these tokens were created, specific text styles were defined by combining them.
The text styles are named semantically to make them easier to use and understand, using categories such as title, body, caption, or link, each with variations in size and weight according to their function.
SPACING AND BREAKPOINTS
SPACING AND BREAKPOINTS
A spacing system based on an 8px grid was defined. Some intermediate multiples, such as 4px and 12px, were included to provide greater flexibility in layout composition and allow for more precise adjustments when needed.
Additionally, key breakpoints were established to ensure the design adapts to different screen sizes, guaranteeing an optimal and consistent experience across mobile, tablet, and desktop devices.
An 8px-based spacing system was defined. Some intermediate multiples, such as 4px and 12px, were included to provide greater flexibility in layout composition and allow for more precise adjustments when needed.
Key breakpoints were defined for the products, enabling the design to adapt to different screen sizes. These ensure an optimal and consistent experience across mobile devices, tablets, and desktop screens.
ICONS
ICONS
Five general icon sizes were standardized to maintain visual consistency across all interfaces. Together with the team, we agreed to use the Material Icons library, as it best fit the project’s needs and offered a wide variety of assets.
To optimize management and usage, we developed a Figma library based on slots, allowing both icon instances and sizes to be swapped easily and efficiently.
Five general icon sizes were standardized to maintain visual consistency across all interfaces. Together with the team, we agreed to use the Material Icons library, as it best fit the project’s needs and offered a wide variety of icons.
To optimize icon management and usage, we developed a Figma library that uses slots, allowing icon instances and sizes to be easily swapped.
Components
COMPONENT PRIORITIZATION
COMPONENT PRIORITIZATION
When planning the system, I proposed prioritizing the development of the most frequently used components to ensure a solid foundation before moving on to more complex elements. We started with essentials such as buttons, inputs, checkboxes, and dropdowns.
This approach ensured consistency in interaction patterns from the early stages and enabled the team to build functional screens more quickly, optimizing both design and development timelines.
When planning the system, we prioritized the development of the most frequently used components, ensuring a solid foundation before moving on to more complex elements. We started with essential components such as buttons, inputs, checkboxes, and dropdowns.
This approach made it possible to ensure consistency in interaction patterns from the early stages. In addition, by having these components defined from the beginning, the team was able to build functional screens more quickly and optimize time in both design and development.
LIBRARY ORGANIZATION
LIBRARY ORGANIZATION
We defined a modular architecture using multiple libraries to optimize maintenance and scalability. The Foundations Library centralizes all styles and variables, acting as the system's "single source of truth." Meanwhile, the Component Libraries directly consume these styles, significantly reducing maintenance effort.
We defined the structure and organization of the Design System. We worked with multiple libraries to optimize maintenance and scalability. A Foundations library was established, centralizing all styles and variables (such as colors, typography, spacing, etc.) and acting as the single source of truth for the system.
Component libraries directly consume the styles and variables from the Foundations library, ensuring visual consistency and reducing update effort. This modular architecture allows any change in the foundations to automatically propagate across all components and products that rely on them.
COMPONENT DEVELOPMENT
COMPONENT DEVELOPMENT
To avoid overloading a single canvas in Figma, we distributed component development across different pages. Each component includes detailed information regarding its intended use, types, variants, and states. Additionally, a direct link to the documentation and development handoff is provided to eliminate ambiguity during implementation.
To optimize the workflow and avoid overloading a single canvas, component development was distributed across different pages within the Figma file. This segmentation allows for more organized work.
Each component includes detailed information such as its intended use, different types, variants, and states as required. Additionally, a direct link to the documentation and development handoff is provided. This ensures that every component is fully specified and ready for implementation without ambiguity.
Documentation & Handoff
Documentation & Handoff
DOCUMENTATION
DOCUMENTATION
Documentation was developed in Supernova, allowing all information to be centralized in a clear and accessible way for the team. Each component includes its functional description, visual specifications, usage guidelines, and variants. The integration of direct links from Figma to Supernova facilitates the handoff to the development team, reducing errors and improving efficiency during implementation.
The documentation was developed in Supernova, which allowed all information to be centralized in a clear and accessible way for the team. Each component includes its functional description, visual specifications, usage guidelines, variants, and more.
Additionally, direct links from Figma to the corresponding documentation in Supernova were included, facilitating the handoff to development. This integration reduces errors and improves efficiency during implementation.
ADOPTION & GOVERNANCE
ADOPTION & GOVERNANCE
To ensure the effective implementation of the system, together with the team, we proposed an adoption strategy specifically designed for an environment where both design and development are executed by external teams. We organized training sessions and workshops to align technical criteria.
Additionally, we defined direct feedback channels so these teams could report inconsistencies or suggest improvements, with the objective of transforming the system into a living resource.
The documentation was developed in Supernova, which allowed all information to be centralized in a clear and accessible way for the team. Each component includes its functional description, visual specifications, usage guidelines, variants, and more.
Additionally, direct links from Figma to the corresponding documentation in Supernova were included, facilitating the handoff to development. This integration reduces errors and improves efficiency during implementation.
Get in touch
mail: ruizrocio.e@gmail.com
Get in touch
mail: ruizrocio.e@gmail.com