Digital Ecosystem: Politécnico GC

When we began the diagnosis, Politécnico had a Figma file with some usage guidelines and a corporate color palette. Each development team made their own decisions about components, typography, spacing, and interface behavior. The result was predictable: visual inconsistency, fragmented experiences, and technical debt accumulated over years that hindered any incremental improvement.

My approach proposed five interdependent stages — from user understanding to technical implementation and continuous evolution:

1. Understand

   Interviews with users and behavior analysis to identify real friction points.

2. Design

   Accessible components based on real user needs.

3. Implement

   Design Tokens, Angular component library, Docusaurus portal, and Storybook as a bridge between design and code.

4. Document and scale

   Governance that allows teams to adopt the system autonomously.

5. Evolve

   UX metrics structure and continuous feedback process—the system improves with use.

Segmented group interviews were conducted by profile — on-campus and online students, faculty, and administrative staff — to identify where the digital ecosystem created friction, cognitive load, and abandonment. The exercise was complemented with community characterization data: predominant devices, connectivity levels, and access contexts. The findings were synthesized into research deliverables: user personas by segment and empathy maps that allowed the team to align design criteria with real needs and make evidence-based decisions.

In parallel, I conducted an audit of the existing system to understand the technical starting point: what components existed? How many were consistent with each other? What patterns repeated? Where did color contrast fail? What flows lacked error or loading states? This diagnosis was critical to prioritizing what to build first and what level of refactoring each part of the system required.

With research findings as the foundation, I transformed the Figma file with basic guides into a comprehensive, scalable, and adoptable system. The work was organized into three layers:

• Token layer. I defined a design token system based on primitive and semantic variables that centralizes all style decisions — colors, typography, spacing, radii, elevations — and exports directly to the Angular seed project. Any change to the design system automatically propagates to code, eliminating the disconnect between Figma and production.
• Accessibility layer. I built contrast matrices to validate WCAG 2.2 AA compliance across the entire palette in light mode and frequently used combinations. Based on recommendations from an external auditor, I led the redesign of critical components — forms, tables, modals, status messages — documenting accessible states and decisions in each case.
• Figma component layer. The library evolved with consistent naming, properly structured variants, and token-linked properties, also detailing usage and editing flows.

With AI tools support, I developed the technical deliverables that convert the design system into something development teams can consume real and autonomously.

• Token architecture with Style Dictionary. Tokens defined in Figma are exported and transformed via Style Dictionary into three levels: primitive variables store pure values as they exist in Figma; semantic variables express usage — with name and description — so a developer understands purpose without consulting the designer; components consume only semantic variables, ensuring consistency and ease of maintenance. This pipeline ensures any Figma change propagates in a controlled manner to code.
• Angular component library. Each component reflects exactly the properties and variants defined in Figma, maintaining the correspondence between design and implementation. The library is distributed through Azure Artifacts, enabling versioned management and orderly adoption by the institution's different development teams.
• Accessibility linters. Specific linters were integrated to validate WCAG 2.2 AA compliance during development, reducing dependency on manual reviews and catching accessibility issues before they reach production.
• Seed repository. Base front-end project with examples of the most common patterns and screens, so teams can start new projects with the correct architecture from the start.

A design system without accessible documentation is ignored. The goal of this stage was to convert all technical deliverables into a shared source of truth for designers, developers, QA teams, and leadership, and lay the groundwork for the system to expand beyond current applications.

• Documentation portal (Docusaurus). The gateway to the design system for the entire institution. The portal organizes general principles, visual and technical foundations, installation, usage and migration guides from the previous version, detailed description of each component with its properties, and direct links to components in Figma and their Storybook stories. It's designed to grow: the goal is to eventually cover other institution products and channels — communications pieces, virtual learning objects, simulators, and social media — under the same consistency and accessibility principles.
• Component documentation in Figma. Each component is organized for design teams with complete variants, contrast tests against system surfaces, component anatomy, and use cases with examples of what to do and what to avoid. The goal is for a designer to make correct decisions autonomously.
• Technical documentation in Storybook. Each Angular component is linked to its Storybook entry, where development teams find specific documentation, applicable accessibility principles, interactive stories, and code examples.
• Accessibility documentation for the entire organization. An introduction to digital accessibility prepared by the external expert was incorporated into the portal, along with protocols, guides, and checklists adapted to four different profiles: executive teams, design, development, and QA.
• Knowledge transfer. To ensure the system didn't remain in documentation but in real practice, knowledge transfer sessions were held with Politécnico's internal teams, with emphasis on digital accessibility. Project closure ensured teams could work autonomously.

The measurement strategy closes the project loop: it allows the design system to evolve with real evidence rather than assumptions. I developed a comprehensive UX/UI measurement strategy for Politécnico to continuously evaluate application quality and make data-driven decisions.

• Measurement stack. The strategy combines four complementary tools:
  • Google Analytics 4 with Google Tag Manager for behavior data and conversions at scale
  • Microsoft Clarity for heatmaps and session recordings that reveal real interface friction
  • NPS and CSAT surveys integrated into key flows to capture satisfaction at the right moment
  • Core Web Vitals monitoring (LCP, INP, CLS) integrated into the CI/CD pipeline to ensure technical performance doesn't hinder experience
• Seven key indicators. The strategy defines KPIs organized into seven categories:
  • Efficiency (success rate and time per task)
  • Friction (errors, rage clicks, abandonment)
  • Satisfaction (NPS, CSAT, SUS)
  • Conversion (key flows like enrollments and applications)
  • Accessibility (WCAG 2.2 AA compliance)
  • Retention (users who return)
  • Engagement (frequency and depth of use)
  Each indicator has concrete metrics, defined targets, and assigned ownership.
• Continuous improvement cycle. Data feeds a systematic four-phase cycle: measure, analyze, prioritize, and act. Prioritization is supported by an impact-effort matrix to focus resources on what affects the most users. Each implemented change is documented with its improvement hypothesis so the next cycle can evaluate its effect.
• Governance and privacy. The strategy includes clear roles and responsibilities for Politécnico's multidisciplinary team, a quarterly reporting cadence to leadership, and privacy guidelines aligned with Law 1581 of 2012 — data anonymization, informed consent, and exclusion of sensitive personal information from all measurement tools.

The result is a design system conceived as the foundation of a continuous improvement process: each iteration of Politécnico's digital ecosystem can rely on real data from its 50,000 users to make more precise and justified design decisions.