Sistema de componentes

SNAPSHOT

Rol
UX / UI + Frontend

Tipo de proyecto
Arquitectura UI · Design System · Refactor

Tecnologías
Vue.js · Ant Design · Figma · Storybook

Contexto
Sitio público en proceso de evolución

CONTEXTO

Un producto que creció sin sistema

El sitio público evolucionó durante años incorporando componentes de forma incremental, sin un estándar unificado entre diseño y desarrollo.

Esto derivó en un ecosistema fragmentado, donde múltiples soluciones coexistían para resolver los mismos problemas.

PROBLEMA

Fragmentación visual y técnica

Durante una revisión inicial se detectaron problemas estructurales:

• múltiples componentes para un mismo propósito
• inconsistencias visuales entre pantallas
• divergencia entre Figma y producción
• variantes implementadas como componentes independientes

Esto generaba deuda técnica, complejidad de mantenimiento y una experiencia inconsistente.

Screenshot duplicidad técnica (modals)

Tablas inconsistentes

Figma vs producción

DIMENSIÓN DEL PROBLEMA

Cuantificando la deuda

Se realizó una auditoría de componentes para entender el impacto real.

Se identificaron múltiples versiones de componentes críticos, especialmente en formularios y estados de éxito/error, con alta cantidad de invocaciones distribuidas en distintas capas del proyecto.

Tabla (tu Excel resumido)

MI ROL

Liderando la estandarización

Lideré he impulse la planificación y definición del proceso de estandarización, incluyendo:

• auditoría de componentes
• definición de criterios
• diseño del sistema
• alineación Figma ↔ desarrollo
• planificación de implementación

Timeline o flujo simple

ENFOQUE

No todo se unifica

El objetivo no fue eliminar la diversidad, sino construir un sistema coherente y flexible.

Se definieron criterios para:

• consolidar
• extender
• excluir componentes

DECISIONES CLAVE

Diseñando un sistema, no componentes aislados

Consolidación

Se unificaron múltiples implementaciones en un solo componente base con variantes.

Exclusión estratégica

• card directorio → visualmente distinta
• card fondos → bajo uso + alta variabilidad

Extensión del componente

• soporte iconos + imágenes
• mayor flexibilidad

Cards antes vs después
Variantes de card (las 2 imágenes que enviaste)

IMPLEMENTACIÓN

De componentes rígidos a sistema reutilizable

Antes, los componentes estaban acoplados a casos específicos.
Después, se construyó una arquitectura basada en componentes reutilizables controlados por props.

Código antes (hardcodeado)
Código después (props + variant)

REGLAS DEL SISTEMA

Gobernanza de componentes

Se definieron reglas claras para mantener consistencia:

• componentes globales en /components
• nombres genéricos (Card, Modal, Table)
• props simples y descriptivas
• variantes alineadas con Figma

Diagrama de flujo (Figma → Dev → Storybook)

RELACIÓN CON FIGMA

Diseño y código como un solo sistema

El sistema se construyó desde el mapeo del sitio real, no solo desde diseño.

Cuando Figma no cubría variantes necesarias, estas se incorporaban desde producción.

Figma vs implementación
ejemplo de variantes

DOCUMENTACIÓN

Escalabilidad mediante Storybook

Se comenzó a implementar Storybook para documentar:

• componentes
• variantes
• uso

screenshot de Storybook (o mock)

IMPACTO

Resultados observables

Mejora en desarrollo

El rediseño del home ya utiliza componentes estandarizados, reduciendo tiempos de implementación.

Reducción de duplicidad

Se eliminaron múltiples componentes redundantes y se limpió el proyecto.

Alineación diseño-desarrollo

Figma y desarrollo ahora funcionan como reflejo directo.

Mantenibilidad

Cambios centralizados con impacto global.

Escalabilidad

Nuevas pantallas se construyen reutilizando componentes existentes.

Elementos

antes vs después conceptual
pequeño gráfico de impacto

REFLEXIÓN

Construyendo base para escalar

Este proyecto no se enfocó en agregar nuevas funcionalidades visibles, sino en fortalecer la base del producto.

La estandarización permite:

• evolucionar más rápido
• reducir deuda técnica
• mejorar colaboración