Recomendaciones para la Adopción del Sistema de Diseño

Orientaciones para que una institución incorpore el Sistema de Diseño en sus productos digitales, coordine a los equipos y proveedores que lo implementan, y sostenga su uso efectivo en el tiempo.

Qué resuelve y a quién está dirigido

Esta guía entrega orientaciones para que una institución incorpore el Sistema de Diseño en sus productos digitales, nuevos y existentes, coordine a los equipos y proveedores que lo implementan, y sostenga su uso efectivo en el tiempo.

A diferencia de una guía de proyecto, que cubre un ciclo con un inicio y un término, esta guía cubre una actividad continua: la institución sigue adoptando, actualizando y verificando el uso del sistema mientras lo mantenga incorporado en sus productos. Su alcance cubre la incorporación del sistema en un producto nuevo o existente, la coordinación con equipos internos y proveedores externos que lo implementan, el seguimiento de sus actualizaciones, y la medición interna de su uso efectivo.

Está dirigida a:

• Contrapartes técnicas de instituciones que adoptan el sistema en sus productos.
• Equipos de desarrollo, propios o de proveedores externos, que implementan el sistema.
• Jefaturas de proyecto que coordinan la incorporación del sistema dentro de un proyecto digital.

Cuándo utilizarlo y cuándo no

Utilízala cuando:

• Tu institución va a incorporar el Sistema de Diseño por primera vez en un producto nuevo o existente.
• Necesitas planificar la migración de un producto que ya está en producción con un estándar visual propio.
• Coordinas el desarrollo del producto con un proveedor externo y necesitas asegurar que use el sistema correctamente.
• Debes mantener actualizado un producto frente a nuevas versiones del sistema, o verificar internamente qué productos lo usan y con qué versión.

No la utilices cuando:

• Necesitas exigir el uso del sistema en una licitación o contrato desde su redacción: consulta Contratación pública y el sistema de diseño.
• Buscas los componentes, tokens o fundamentos en sí: consulta las secciones de Fundamentos y Componentes.
• Necesitas entender las reglas de gobernanza sobre cómo se clasifican y aprueban los cambios del sistema: consulta el Modelo de Gobernanza del Sistema de Diseño.

Reglas o criterios principales

• La adopción requiere capacidad técnica y respaldo institucional a la vez. Contar con componentes bien documentados no basta si la institución no cuenta con el mandato, el tiempo o el equipo para incorporarlos.
• Seguir el estándar publicado evita mantener una versión propia en paralelo. Cuando una institución no sigue las actualizaciones oficiales, tiende a mantener código propio en paralelo, lo que multiplica el problema de fragmentación que el sistema busca resolver.
• La adopción se sostiene si se mide, no si se asume. Sin un registro interno de qué productos propios usan el sistema y con qué versión, no es posible saber si la adopción realmente se sostiene en el tiempo.

Cómo aplicarlo

El ciclo de adopción

1. Incorporación inicial. Proceso mediante el cual una institución o un producto adoptan el sistema por primera vez, ya sea un producto nuevo o uno que aún no lo usa. Actividades clave: revisar el UI Kit y los componentes disponibles, según las reglas de incorporación definidas en el Modelo de Gobernanza del Sistema de Diseño; definir si el producto es nuevo o requiere migración desde un estándar existente; designar formalmente una contraparte técnica institucional responsable de la implementación. Entregable esperado: contraparte institucional designada; decisión documentada sobre si el producto requiere migración.

2. Migración desde el estado actual. Aplica cuando un producto ya está en producción con un estándar visual propio y necesita transicionar hacia el Sistema de Diseño sin interrumpir su operación. Actividades clave: inventariar los componentes propios actualmente en uso y su equivalencia en el sistema; priorizar la migración según el impacto o la visibilidad del componente para las personas usuarias; definir etapas de migración incremental y una fecha de cierre para dejar de usar el estándar anterior. Entregable esperado: inventario de equivalencias; plan de migración incremental con fecha de cierre.

3. Coordinación con equipos internos y proveedores externos. Aplica cuando parte o todo el desarrollo lo ejecuta un tercero. Actividades clave: incluir el uso del Sistema de Diseño como requisito técnico en las bases de licitación o el contrato; dar acceso al proveedor a la documentación y al sandbox de componentes desde el inicio del desarrollo; incorporar la validación de cumplimiento como parte del proceso de aceptación de los entregables. Entregable esperado: requisito técnico incorporado en el contrato; checklist de validación de cumplimiento aplicado antes de la aceptación.

4. Seguimiento de actualizaciones del sistema. Corresponde a cómo la institución se mantiene al tanto de los cambios que la SGD publica al sistema, y cómo planifica su propia actualización interna. La forma en que esos cambios se clasifican y aprueban se define en el Modelo de Gobernanza del Sistema de Diseño. Como referencia, conviene revisar el registro de cambios cada vez que se publica una nueva versión. Actividades clave: revisar periódicamente el registro de cambios (changelog) publicado por la SGD; evaluar si un cambio afecta a alguno de los productos propios antes de actualizarlos; planificar y probar la actualización en un ambiente de prueba antes de aplicarla en producción. Entregable esperado: registro interno de qué cambios se revisaron y cuáles requieren actualización en los productos propios.

5. Medición interna de uso efectivo. Etapa continua que permite a la institución saber si sus propios productos efectivamente usan el sistema, y con qué vigencia. Como referencia, este registro interno se actualiza de forma periódica (mensual o trimestral). Actividades clave: registrar qué productos propios usan el sistema, con qué versión y desde cuándo; comparar la versión en uso contra la última versión disponible en el registro de cambios; usar este registro interno para priorizar qué productos propios actualizar primero. Entregable esperado: registro interno de productos, versiones y fechas de actualización.

Roles y responsabilidades

Esta sección detalla los roles que una institución debe asumir o designar para adoptar el sistema.

Contraparte institucional. Persona designada dentro de la institución que adopta el sistema, responsable de coordinar su implementación con la SGD y con el equipo de desarrollo propio o externo.

Equipo de desarrollo (propio o proveedor). Implementa técnicamente el sistema en el producto, ya sea que pertenezca a la institución o a un proveedor externo contratado.

Recomendaciones para el sector público

• Incorpora el cumplimiento del sistema en los contratos de desarrollo externo. Gran parte del desarrollo digital del Estado se ejecuta a través de proveedores externos con contratos de duración acotada; sin una cláusula explícita en el contrato, no existe mecanismo de exigencia una vez terminado este.
• Mantén un registro interno que no dependa de una persona específica. Tanto los equipos de desarrollo externos como las contrapartes técnicas dentro de las instituciones cambian con los ciclos de contrato y de personal. El registro de productos y versiones debe quedar disponible para quien asuma la contraparte después.
• Incluye el seguimiento de actualizaciones como parte del mantenimiento contratado. Si el desarrollo de un producto está a cargo de un proveedor externo, conviene que el contrato de mantención incluya explícitamente la revisión periódica del changelog y la actualización oportuna de componentes, y no solo la corrección de errores.

Ejemplos recomendados y no recomendados

• Incorporación inicial — Recomendado: adoptar los componentes junto con la lógica de accesibilidad y estructura semántica que los sustenta. No recomendado: adoptar visualmente los componentes (solo la apariencia) sin ajustar esa lógica, perdiendo el beneficio real del sistema.
• Migración — Recomendado: definir etapas de migración incremental con una fecha de cierre para dejar de usar el estándar anterior. No recomendado: migrar de una sola vez sin plan incremental, generando errores visibles para las personas usuarias, o mantener ambos estándares indefinidamente sin fecha de cierre.
• Coordinación con proveedores — Recomendado: incluir el requisito de uso del sistema en el contrato y validar su cumplimiento como parte de la aceptación de cada entregable. No recomendado: descubrir el incumplimiento del sistema al final del contrato, cuando ya no queda margen de ajuste con el proveedor.
• Seguimiento de actualizaciones — Recomendado: revisar el changelog en cada versión publicada y evaluar su impacto antes de actualizar. No recomendado: ignorar los avisos de cambios y descubrir la incompatibilidad cuando el producto ya falla en producción.
• Medición interna — Recomendado: mantener un registro actualizado de qué productos usan el sistema y con qué versión. No recomendado: asumir que un producto sigue actualizado sin verificarlo, acumulando una brecha de versiones difícil de resolver de una sola vez.

Consideraciones de contenido y accesibilidad

• Adoptar el sistema no es solo copiar la apariencia visual de un componente: incluye su estructura semántica y su lógica de accesibilidad (roles ARIA, foco, contraste, textos alternativos). Omitir esto anula el principal beneficio del sistema.
• Al migrar desde un estándar propio, revisa que los componentes migrados mantengan o mejoren el nivel de accesibilidad que tenían antes, no solo su apariencia.
• Exige a los proveedores externos evidencia de que el componente implementado corresponde efectivamente al código y a la documentación oficial del sistema, no solo a una réplica visual.

Checklist de implementación o revisión

Recursos y contenidos relacionados

• Contratación pública y el sistema de diseño.
• Modelo de Gobernanza del Sistema de Diseño.
• Changelog.
• Fundamentos y Componentes.
• Guía de gestión ágil de proyectos digitales.

Evidencia o fuentes

Esta guía corresponde a una orientación propia de la Secretaría de Gobierno Digital (SGD) para la adopción institucional del Sistema de Diseño Digital de Gobierno.