Unidad 9 / 11

Sistema de Diseño: Inteligencia Artificial en Componente, Token y Documentación

Ganancias:

  • Capacidad para redactar y crear tokens de diseño consistentes, nombres de componentes y reglas de uso con inteligencia artificial.
  • Capacidad para producir rápidamente documentación de componentes, ejemplos de qué hacer/no hacer y textos de uso con inteligencia artificial.
  • Capacidad para comprobar las sugerencias de inteligencia artificial en busca de conflictos con el sistema de diseño existente y preservar la singularidad.

Un sistema de diseño es el lenguaje común que hace que una familia de productos se vea y se comporte de manera consistente: componentes reutilizables (botón, tarjeta, campo de formulario), tokens de diseño (definiciones nombradas de valores como color, espaciado, tipografía) y documentación que explica cómo usarlos. Un buen sistema de diseño permite que diez diseñadores diseñen el mismo producto como si fuera producido por una sola fuente. Instalar y mantener este sistema es un trabajo agotador, repetitivo y que requiere mucho texto; Aquí es exactamente donde brilla la inteligencia artificial. Pero la esencia del sistema es la singularidad y la coherencia; Las recomendaciones de AI no pueden aceptarse sin antes comprobar si entran en conflicto con el sistema actual.

Tokens y naming: la base de la coherencia

Un token de diseño es un valor reutilizable y con nombre de una decisión de diseño: color-primario, espacio-centro, texto-título-capital. Gracias a los tokens, puedes cambiar un color en un lugar y actualizarlo en todo el producto. Pero el poder de las fichas depende de la coherencia de la denominación; Si azul-1, azul principal y azul primario se usan combinados, el sistema fallará.

La IA es buena en dos cosas aquí: revisar su conjunto de tokens existente con un esquema de nombres consistente y sugerir nombres compatibles con el esquema para nuevos tokens. Una solicitud como "Traducir esta lista de tokens a nombres semánticos (basados ​​en el significado)" le ayudará a generar nombres que transmitan significado, como color-action-primary en lugar de blue-500. Pero la decisión final sobre el nombre es el contrato del equipo; El modelo sólo proporciona un esquema.

Consejo: al nombrar tokens para la IA, proporcione de 5 a 6 ejemplos de su esquema actual y diga "mantenga el mismo patrón". La solicitud sin muestra produce nombres que son ajenos a su sistema.

Documentación de componentes: el área más productiva de la IA

La documentación de un componente incluye: qué hace, cuándo usarlo, cuándo no usarlo, sus variantes, estados (predeterminado, flotante, pasivo, error), notas de accesibilidad y ejemplos de "hacer/no hacer". Escribir estos textos a mano lleva horas, por lo que muchos equipos descuidan la documentación.

La IA llena este vacío: cuando se describe un componente, se produce un borrador de documentación, reglas de uso y ejemplos de qué hacer y qué no hacer en un formato coherente. Así, la documentación pasa del "no hay" al "hay borrador, se arreglará", lo cual es una gran ganancia. Sin embargo, el modelo no conoce el comportamiento real del componente; Es su trabajo hacer coincidir las reglas que produce con la realidad del sistema.

fragmento de documento

Contribución de la inteligencia artificial

verificación humana

¿Qué hace?

Definición clara del esquema

Verdadera aptitud para el propósito

cuando usar

Escenarios generales

Reglas específicas del producto

Ejemplos de hacer/no hacer

Pares de draft rápido

Abusos reales

Nota de accesibilidad

Recordatorios estándar

Confirmado por prueba real

Lista de variantes/casos

lista posible

Aquellos que realmente existen en el sistema.

Comprobación de contradicciones: preservar la singularidad

El archienemigo del sistema de diseño es la duplicación: dos botones que hacen el mismo trabajo, dos escalas espaciales diferentes, dos reglas en conflicto. Cuando la IA sugiere un nuevo componente o regla, esa sugerencia puede entrar en conflicto con el sistema existente: no tiene en cuenta todo el sistema modelo. Entonces evalúo cada sugerencia preguntando "¿esto entra en conflicto con algo que ya existe?" Filtrar con la pregunta. También puede utilizar la inteligencia artificial en el escaneo de conflictos: puede proporcionar el resumen del sistema actual y la nueva recomendación y enumerar los conflictos. Pero la decisión final sobre "singularmente correcta" depende del equipo.

tres mini casos

Caso 1: Deuda de documentación liquidada. Sólo 6 de los 24 componentes de un equipo tenían documentación. Se elaboraron borradores de documentos para los 18 componentes restantes con inteligencia artificial; El equipo arregló cada uno en 10 a 15 minutos. El trabajo, que se pospuso durante semanas, se completó en dos días.

Caso 2: la denominación de los tokens se volvió coherente. En un sistema, los colores se mezclaban como azul1, azul principal, azul de marca. La IA tradujo 40 tokens existentes en un esquema semántico; El equipo lo revisó y cambió a un estándar único. Los errores de color se redujeron notablemente en diseños posteriores.

Caso 3: Se rechazó el componente conflictivo. AI propuso un nuevo componente llamado "botón de acción secundaria". Cuando el equipo buscó contradicciones, descubrió que hacía el mismo trabajo que el "botón fantasma" existente y rechazó la sugerencia. Lección: no todas las sugerencias añaden un nuevo componente al sistema; A veces es correcto utilizar lo que está disponible.

Indicaciones copiables

Su rol: administrador del sistema de diseño. Documente este componente: <<componente y su comportamiento>>.Formato: ¿Qué hace? Cuándo utilizar | Cuándo NO utilizar |Variantes | Situaciones | Notas de accesibilidad | 2 Hacer / 2 No dar ejemplo. Inventa comportamientos que no conoces; Escriba "el equipo debe completar".

Traduzca esta lista de tokens a un esquema de nomenclatura semántica (basada en el significado). Mis ejemplos de esquema actuales: <<5-6 ejemplos>>. Continuar con el mismo patrón. Para cada token, proporcione el nombre anterior -> nombre nuevo -> tabla de justificación. Lista: <<fichas>>

Busque contradicciones: Resumen de mi sistema de diseño actual: <<summary>>. Nuevo componente/regla propuesta: <<sugerencia>>. ¿Esta sugerencia entra en conflicto con el sistema existente (componente que hace el mismo trabajo, regla en conflicto, token duplicado)? Enumere los conflictos y su sugerencia.

Genere pares de ejemplos de "hacer/no hacer" para este componente: uso correcto realista y escenarios de uso incorrecto realistas. Para cada par, explica en una oración por qué es verdadero/falso. Componente: <<nombre y finalidad>>

Aviso débil / Aviso fuerte

Débil: "Escriba documentación para este botón".

Resultado: un texto general formateado sin conexión con el sistema.

Fuerte: "Documente este botón en el siguiente formato (qué hace/cuándo no usar/variantes/casos/accesibilidad/no hacer); invente un comportamiento que no conoce, escriba 'el equipo debe completarlo'".

Resultado: Manuscrito editable, con formato consistente y espaciado adecuado.

Diferencia: formato de aviso fuerte + prohibición de fabricación + avisos de hacer/no hacer.

Errores comunes

  • Solicitar nombres de tokens sin ejemplo. El modelo genera nombres que son ajenos a su sistema; Se rompe la consistencia.
  • Agregar componentes sin buscar contradicciones. La duplicación es el archienemigo del sistema.
  • Suponiendo que el comportamiento inventado por el modelo es correcto. La IA no conoce el comportamiento real del componente.
  • Aceptar la calificación de accesibilidad sin realizar pruebas. El recordatorio estándar no sustituye a las pruebas reales.
  • Escribir la documentación una vez y no actualizarla. El documento debe actualizarse a medida que cambia el sistema.

En resumen

El sistema de diseño es la infraestructura de coherencia y escalabilidad; pero su mantenimiento a menudo se descuida porque requiere mucho texto y es repetitivo. La IA aborda esta deuda produciendo rápidamente documentación de componentes, ejemplos de qué hacer/no hacer, scripts de uso y borradores de nombres de tokens. Pero la esencia del sistema es la singularidad y la coherencia: cada nombre de token debe verificarse con el esquema de muestra, cada propuesta de componente debe escanearse en forma contradictoria, cada descripción de comportamiento debe verificarse con la realidad. Utilice el modelo como un redactor eficiente; El equipo toma la decisión individual correcta.

Tarea de aplicación

  1. Seleccione un componente al que le falte documentación y produzca un borrador de documento con el primer mensaje.
  2. Complete los campos marcados "El equipo debe completar" con el comportamiento real.
  3. Con el segundo mensaje, convierta sus 8-10 tokens al esquema semántico y cree una tabla de nombres nueva/antigua.
  4. Para encontrar una idea de componente nuevo, busque contradicciones con el tercer mensaje.
  5. Con el cuarto mensaje, genere pares de ejemplo de hacer/no hacer para un componente y agréguelos al sistema.

lista de verificación

  • [] Vinculé el nombre del token al esquema de ejemplo.
  • [] Escaneé los nuevos componentes en busca de conflictos.
  • [ ] Verifiqué los comportamientos elaborados por el modelo con la realidad.
  • [] Planeaba confirmar las notas de accesibilidad con pruebas reales.
  • [] Mantuve la documentación en un formato coherente.
  • [] Preservé la singularidad y evité la duplicación.