Prepara tu sistema de diseño para trabajar con IA

Un prototipo generado con IA puede tener botones convincentes y, aun así, cambiar de espaciado o de color entre pantallas. En un artículo publicado el 3 de junio en Smashing Magazine, Vitaly Friedman aborda ese problema: las decisiones que el equipo da por sabidas deben quedar escritas para que la IA pueda consultarlas. Su propuesta recoge el trabajo de Hardik Pandya sobre sistemas de diseño legibles por agentes.

Escribe también cuándo usar cada componente

Una biblioteca de interfaz reúne piezas reutilizables y un sistema de diseño explica cómo combinarlas. Para trabajar con IA hace falta documentar el criterio: cuándo abrir un diálogo, qué mensaje mostrar ante un error o qué estados debe tener un botón.

Friedman recomienda guardar principios, prioridades y ejemplos en archivos Markdown. Es una forma de darle instrucciones explícitas al agente, sin obligarlo a deducirlas de una maqueta. Por ejemplo, la ficha de un formulario de contacto podría indicar que el error aparece junto al campo y que el foco debe seguir siendo visible. Ese detalle permite revisar una respuesta concreta.

Un nombre para cada decisión visual

Los tokens de diseño asignan nombres a colores, tamaños y otras medidas compartidas. La documentación de Atlassian para modelos de lenguaje organiza tokens, componentes, reglas de estilo y pautas de accesibilidad en documentos enlazados. También identifica herramientas para comprobar el uso del sistema.

La utilidad se entiende con una tarjeta: si su separación usa una variable, cambiar el valor compartido puede actualizar varias pantallas. Si cada tarjeta lleva una medida distinta escrita directamente en el CSS, hay que localizar y corregir cada una. Conviene que el nombre explique la función del valor, para que quien lea el código entienda qué está ajustando.

Comprueba el resultado y actualiza las reglas

La guía de Pandya añade una auditoría automática que detecta valores escritos directamente en el CSS y propone el token correspondiente. Las especificaciones viven junto al código; cuando cambia la biblioteca de origen, una rutina señala qué documentos necesitan revisión.

Pandya cuenta una prueba con Atlaskit: encontraron 418 valores directos en 28 archivos y prepararon 64 especificaciones. Son cifras de ese proyecto, no una garantía de que cualquier equipo obtendrá el mismo resultado.

Pasar la auditoría de tokens tampoco demuestra que una interfaz sea accesible o fácil de usar. Sigue haciendo falta probarla con teclado, comprobar sus mensajes y revisar cómo responde en móvil. Para empezar, un formulario pequeño permite ver si las instrucciones bastan y corregirlas antes de extender el método al resto del producto.