<
Back to design systems
Uniandes Design System
Client:
Universidad de los Andes
Role:
Lead design system
Tools and Skills:
Figma, UI Design, Token architecture, Storybook
The Uniandes Design System is the backbone of the university's web initiative. The organization had accumulated around 500 websites built across different technologies, each with its own visual language and interaction patterns. The result was a web presence that felt like many different institutions rather than one. The system was built to close that gap, establishing a shared visual foundation and a consistent set of interaction patterns with Drupal as the common platform.
Before
uniandes.edu.co
After
uniandes.edu.co
The challenge
The core challenge wasn't technical. It was human. The teams responsible for maintaining those 500 sites had wildly different skill levels: some had no design background at all, others had dedicated designers, and a few had their own developers. Building a system that could serve all of them without alienating any of them required a distribution strategy that met each team exactly where they were.
On the technical side, Drupal is one of the most secure CMS platforms available but one of the least flexible. Modern headless architecture wasn't viable, and the development team was junior level. Every component had to be built in plain HTML, CSS, and vanilla JavaScript with no frameworks. That constraint shaped every decision in the system.
Team and role
The system started with a team of three designers including me, plus an external contractor handling development. As the system matured and we took ownership of it internally, my role shifted toward leading its evolution, defining where it needed to go next and building the governance structure to get it there.
Eventually I was leading the central team alone, working directly with two developers and a mid-level designer. That meant being responsible for the technical direction, the component review process, and the relationships with every team consuming the system across the university.
Token architecture
Token architecture came later in the project, and it solved a specific problem: how to bring the faculties and schools into the system without erasing their individual identities. The economics and medicine schools each had their own visual language that meant something to their communities. Tokenization made it possible to onboard them without compromising the integrity of the core system, which was a significant win.
The key decision was defining the boundaries of personalization. Tier one established the core values: color, typography, spacing, viewport, border, and border width. Within the theme-specific tier one, only color and typography could be changed. That boundary was deliberate. Flexible enough to accommodate distinct identities, structured enough to keep everything recognizably Uniandes.
Uniandes Core Design System
uniandes.edu.co
Medicine faculty tokens applied
uniandes.edu.co
Economy faculty tokens applied
uniandes.edu.co
Library structure
The library structure followed the same paradigm as the CMS itself, which turned out to be the right decision. The base design system file was built for design teams with the knowledge to use it at a component level. Alongside it, a building blocks file organized content into pre-assembled blocks, a card grid with title and pagination for example, that a web administrator could drag and drop directly into the CMS without any design knowledge. The spacing, margins, and structure were already resolved. They just had to feed content into it.
This was a deliberate departure from how atomic design is typically applied. Instead of shipping full page templates, we shipped building blocks, giving web admin teams flexibility without opening the door to inconsistency.
Design System file (Figma)
Components and tokens
Aa
Building block file (Figma)
Sections
News
Component and documentation in StoryBook
uniandes.edu.co
Drag and drop administration in Drupal
uniandes.edu.co
Distribution and governance
Much of the work was done with external contractors who couldn't be inside our Figma team directly. We managed this by maintaining versioned, always up-to-date shared files for both the design system and the building blocks library, so contractors were always working from the right source.
A dedicated Teams channel became the main communication layer with all system users, covering announcements about new deployments, deprecated components, and ongoing support. We also ran onboarding sessions for web admin teams, covering how the system worked, its advantages, and the content formats it supported.
Governance was clear and centralized at the review stage. Every new component had to pass through me before entering the system. There were two main workflows: components designed by others and developed by us, and components designed and developed by third parties. Both required review. When development came from outside the team, a front-end developer also reviewed the code before anything was accepted.
Documentation
Documentation was the hardest part to keep under control. A hybrid distribution model with multiple audiences and external contributors made it difficult to maintain a consistent standard across the board. The CMS added another layer, as components inside it needed documentation written specifically for web administrators, which was a completely different register from anything written for designers or developers.
The solution was to accept that one document couldn't serve everyone and build four distinct documentation streams: design documentation for designers, design documentation for developers, technical documentation for external developers and system consumers, and CMS documentation for web administrators.
CMS component documentation
uniandes.edu.co
Outcome
The design system changed how the university thought about its web presence. Faculties, schools, and administrative units that had been building independently started to see the value of a coherent visual language and a more usable CMS. Nine previously independent websites moved inside uniandes.edu.co, a concrete result that made the systemic approach visible and defensible to leadership.
The next phase was already defined before I left: making the system CMS-agnostic, moving toward a headless architecture that could support web applications and mobile products. The foundation was built to outlast the platform it started on.