Mejora del sistema de diseño

Contexto

El producto había crecido entre varios equipos y áreas funcionales, pero los patrones de interfaz no se habían mantenido completamente alineados. Botones, tarjetas, formularios y primitivas de layout similares se comportaban de forma distinta según dónde se implementaban.

El trabajo no era un rediseño visual. El objetivo era crear una base frontend más sólida para que los equipos pudieran entregar UI con mayor rapidez sin añadir nuevas inconsistencias, regresiones de accesibilidad o lógica duplicada.

Problema

Un sistema de diseño pierde valor cuando los equipos no pueden confiar en él. Si los componentes son difíciles de extender, poco claros en casos límite o desconectados de necesidades reales del producto, los equipos terminan creando variantes locales.

El producto necesitaba una capa compartida de componentes que resolviera estados reales de interacción, comportamiento responsive, marcado accesible y consistencia visual sin obligar a cada equipo a resolver los mismos problemas de UI otra vez.

• Existían patrones repetidos con pequeñas diferencias de comportamiento.
• Las APIs de componentes necesitaban límites más claros y contratos tipados.
• Los tokens debían sostener decisiones consistentes de espaciado, color y tipografía.
• Los estados de formulario, foco, carga, vacío, deshabilitado y error necesitaban defaults predecibles.
• La documentación debía explicar cuándo y cómo usar cada patrón.

Enfoque

Traté el sistema de diseño como infraestructura de producto, no como una galería de componentes. El primer paso fue identificar patrones repetidos con riesgo real: formularios, botones, tarjetas, layouts, feedback y navegación.

Cada componente se definió alrededor de un contrato estable: qué renderiza, qué estados controla, qué debe seguir siendo componible y qué decisiones pertenecen a las pantallas de producto.

• Audité patrones repetidos y los agrupé por intención de producto.
• Refiné componentes reutilizables con props tipadas y variantes explícitas.
• Mantuve flexibles las primitivas de layout y consistentes los estados de interacción.
• Alineé tokens con restricciones de implementación, no solo con valores visuales estáticos.

Decisiones de accesibilidad

Los componentes compartidos son un punto de alto impacto para mejorar accesibilidad porque un patrón fuerte evita muchos defectos repetidos. La mejora priorizó HTML semántico, foco visible, teclado y etiquetado claro.

El sistema evitó ocultar decisiones de accesibilidad únicamente en estilos visuales. Los componentes expusieron estructura y props para que los equipos pudieran aportar etiquetas, descripciones y mensajes de estado significativos.

• Los componentes interactivos usaron elementos semánticos antes que comportamiento custom.
• Los estilos de foco visible se mantuvieron consistentes entre temas y estados.
• Los controles de formulario soportaron etiquetas, descripciones, validación y estados deshabilitados.
• El color no fue la única señal para estados destructivos, de alerta, selección o error.

Rendimiento y mantenibilidad

Un sistema de diseño debe reducir trabajo frontend, no añadir coste en runtime. La implementación se enfocó en componentes pequeños, composición predecible y evitar abstracciones que dificultaran optimizar pantallas.

La mejora también redujo riesgo de mantenimiento al hacer visibles los casos límite en APIs y documentación. Los equipos podían ver variantes soportadas sin investigar detalles internos de implementaciones locales.

• Componentes compartidos acotados para evitar APIs genéricas demasiado pesadas.
• Separación entre tokens de estilo, datos de producto y lógica de negocio.
• Reducción de código UI duplicado moviendo estados repetidos a primitivas compartidas.
• Comportamiento responsive y de tema más predecible entre familias de componentes.

Por qué importa este caso

Este proyecto muestra ingeniería frontend más allá de implementar páginas: arquitectura de componentes, accesibilidad, colaboración con diseño y sistemas UI mantenibles que ayudan a los equipos a avanzar más rápido.

Para managers de ingeniería y equipos de producto, la señal clave es el método: identificar patrones repetidos, definir contratos fiables, documentar usos reales y construir componentes que hagan más fácil la implementación correcta.