Defina decisiones, no solo una galería de estilos
Un sistema de diseño es más que capturas de pantalla. Registra decisiones que se repiten: el espaciado entre secciones, el tratamiento de la acción primaria, cómo funciona un error de formulario y el lenguaje usado tras un acierto o un fallo. USWDS describe los design tokens como paletas discretas para valores como tipografía, espaciado, color, interlineado y opacidad. Documente la regla, el propósito, las variantes aprobadas y el responsable. Empiece por los fundamentos y los cinco a ocho componentes que más se usan en los recorridos importantes; estandarizar cada página de golpe suele generar ruido en lugar de claridad.
Registre roles de color aprobados, tipografías, espaciados, bordes, radios, puntos de quiebre (breakpoints) y decisiones de movimiento que su sitio realmente use.
Use un patrón para una disposición de tareas repetible, como creación de cuenta o resultados de búsqueda, en lugar de para un adorno visual único.
Use tokens para controlar valores repetidos
Un token de diseño (design token) es un nombre legible por humanos asociado a un valor. El Design Tokens Community Group describe los tokens como una forma independiente de plataforma para expresar decisiones de diseño; como mínimo, un token es un nombre y un valor. Use nombres por propósito como color-action-primary o space-section en lugar de esparcir valores en bruto por las plantillas. Mantenga un mapeo documentado desde tokens de propósito a valores base. Los tokens facilitan los cambios coordinados, pero no garantizan contraste, marca o buena jerarquía. Valide cada combinación renderizada y estado de página.
Cree tokens para elecciones repetidas, no para cada excepción; de lo contrario la lista de tokens solo preserva la inconsistencia.
Para un token usado extensamente, liste las páginas afectadas, pruebe pantallas representativas y proporcione orientación de migración o reversión cuando sea necesario.
Construya componentes con comportamiento y límites
Un componente es una parte de interfaz reutilizable con comportamiento, no solo una forma visual. Documente la estructura semántica, entradas requeridas y opcionales, variantes, comportamiento responsivo y todos los estados relevantes: carga, deshabilitado, error, vacío y éxito. Incluya el comportamiento con teclado y orientación de contenido. No obligue a que todo diseño encaje en un componente. GOV.UK evalúa los componentes compartidos por utilidad, singularidad, usabilidad, consistencia y versatilidad; eso es una disciplina útil para decidir qué merece mantenimiento compartido. Un componente muy reutilizado puede propagar un defecto ampliamente, así que pruébelo en las páginas donde la gente lo usa.
Liste cada estado visible para el usuario y muestre etiquetas reales, texto largo y errores para que los límites de implementación sean visibles.
Marque las variantes antiguas claramente, nombre el reemplazo y elimínelas solo después de que los recorridos afectados hayan sido revisados.
Haga de la accesibilidad una condición de lanzamiento
La accesibilidad debe integrarse en el sistema porque las decisiones repetidas pueden repetir barreras. WCAG 2.2 requiere, en Nivel A, operación por teclado para la funcionalidad salvo que la ruta de movimiento sea inherente, y exige un orden de foco significativo cuando la secuencia importa. Haga controles semánticos, foco visible, etiquetas, movimiento lógico de foco, identificación de errores y finalización de tareas sin puntero parte de la guía de componentes. Use comprobaciones automatizadas de forma temprana, luego pruebas manuales con teclado, zoom, responsividad y pruebas de página. USWDS advierte que los componentes accesibles no garantizan un servicio accesible; el código personalizado, el texto, las integraciones y el contexto aún necesitan revisión.
Confirme que las personas pueden alcanzar, operar, entender y abandonar los controles sin un ratón o que no queden atrapadas por el teclado.
Los deberes legales varían según la jurisdicción y el contrato. Busque revisión cualificada en accesibilidad y legal cuando el cumplimiento sea material.
Trate los estándares de contenido como estándares de interfaz
Las palabras son entradas de componente, no decoración añadida después del diseño. Establezca reglas para etiquetas de acción, etiquetas de formulario, errores, encabezados, enlaces, terminología, fechas, números y abreviaturas. La orientación de GOV.UK favorece la voz activa y dirigirse al usuario como «you» cuando sea posible; use el principio de lenguaje claro y consistente, adaptando la voz a su audiencia. Combine las reglas con un modelo de contenido: indique qué campos son obligatorios, guías sensatas de longitud y qué sucede cuando falta información. Ponga la guía en la documentación de componentes y los flujos de trabajo del CMS, donde los editores puedan usarla.
Diga qué falló, dónde ocurrió y la siguiente acción cuando sea seguro y útil hacerlo.
Un límite es una señal para rediseñar o reescribir, no permiso para eliminar significado esencial.
Gobierne el sistema antes de que crezca más rápido que la confianza
La gobernanza es el proceso ligero para la propiedad, solicitudes, revisión, lanzamientos y retiro. Nombre un responsable y un grupo revisor que pueda aportar diseño, ingeniería, contenido y experiencia en accesibilidad. Empareje la evidencia con el radio de impacto. Un patrón local puede necesitar una declaración de problema y prueba en página. Un cambio compartido de botón o token debe incluir recorridos afectados, comprobaciones de accesibilidad, comparación visual, notas de migración e instrucciones de reversión. GOV.UK pide a los contribuyentes demostrar que un componente es útil para muchos equipos, no un duplicado, y probado con usuarios representativos; use eso como modelo práctico en lugar de regla universal.
Guarde el problema, opciones, decisión, responsable, versión afectada y fecha de revisión donde los equipos puedan buscarlo.
Etiquete los cambios como parche, aditivo o rompedor para que los consumidores sepan cuándo se necesita migración y un periodo de compatibilidad.
Prevenga regresiones antes del lanzamiento
Conecte el sistema a la entrega. Requiera que un cambio identifique tokens y componentes tocados, luego pruebe los estados afectados y páginas representativas. La comparación visual, pruebas de interacción, revisión de contenido y comprobaciones de accesibilidad detectan distintos defectos. Priorice recorridos de alta consecuencia así como los de alto tráfico; acceso a cuentas y formularios de contacto pueden ser importantes incluso cuando el tráfico es modesto. Esto apoya el trabajo proactivo de optimización del tiempo de actividad y remediación de Status Is UP al reducir el alcance del defecto y hacer que una corrección aprobada sea más fácil de verificar. No es monitorización de tiempo de actividad ni un sustituto de un plan de incidentes.
Mantenga la versión del componente, resultados de pruebas, hallazgos, aprobaciones y cualquier riesgo aceptado con el registro de lanzamiento.
Conserve la versión estable anterior y pruebe los pasos escritos de restauración y verificación durante mantenimientos de bajo riesgo.