Como muchos, paso buena parte del día trabajando con IA. La uso para explorar, ordenar, revisar, comparar, escribir, analizar. A veces para desarrollar una idea más rápido. A veces para no partir desde cero. Y otras para mirar un problema desde un ángulo que no estaba viendo.
Pero cada vez que una actividad empieza a repetirse, me pregunto: ¿cómo hago para no volver a explicarlo todo desde cero la próxima vez?
Esta inclinación a sistematizar tareas no nació con la IA. Ahí están las plantillas, los procesos, los checklists, los documentos que vuelvo a usar. Pero con IA la situación toma otro nivel, porque ya no sistematizo sólo una forma de ordenar trabajo: también puedo sistematizar parte de la interacción con una herramienta que interpreta, ejecuta y produce.
Ese cambio parece pequeño, pero para mí es uno de los saltos más importantes en el trabajo con IA. Una cosa es usar un chat para resolver una tarea puntual. Otra cosa es sistematizar una actividad para que pueda repetirse, revisarse, ajustarse y mejorar con el tiempo.
Ahí el problema deja de ser la respuesta y empieza a ser el flujo.
Y en ese punto el asistente de chat normal empieza a quedar corto, porque la conversación ya no alcanza para sostener una actividad completa. Empiezan a importar otras capacidades: leer archivos, operar sobre carpetas, usar scripts, conservar artefactos, ejecutar pasos, revisar salidas y retomar trabajo sin reconstruir todo desde cero.
Por eso herramientas como Codex o Claude Code, que muchas veces se leen sólo como asistentes para programar, también empiezan a ser relevantes para diseño: no por el código en sí, sino porque permiten trabajar con un proceso completo.
¿Qué evidencia necesita el modelo? ¿Qué criterio debería aplicar? ¿Qué parte conviene resolver con una regla? ¿Qué parte requiere interpretación? ¿Cuándo tiene que intervenir una persona? ¿Qué salida debería producir para que otro humano, otra herramienta o un agente posterior pueda seguir trabajando?
Eso es lo que entiendo por convertir criterio de diseño en flujos con agentes.
Y eso es justamente lo que trabajamos en el curso Agentes y Skills para Diseño.
No partimos desde una definición abstracta de “agente”. Partimos desde actividades reales del proceso de diseño: revisar una interfaz, evaluar accesibilidad, validar lenguaje, contrastar una pantalla contra un sistema de diseño, analizar respuestas abiertas de research, consolidar hallazgos y decidir qué queda fuera porque la evidencia no alcanza.
La pregunta que me interesa no es si un agente puede “hacer diseño”, sino qué partes de un proceso de diseño pueden convertirse en herramientas que ayuden a decidir mejor sin sacar al diseñador del circuito.
Ése es el punto: crear condiciones para aplicar criterio profesional donde más importa.
El punto de partida: una tarea de diseño que se repite
Una buena forma de entender el curso es partir por una tarea conocida: revisar una interfaz.
Cualquier equipo de diseño hace esto todo el tiempo. Mira una pantalla, detecta problemas, discute prioridades, compara contra criterios de usabilidad, revisa texto, comprueba accesibilidad, pregunta si algo respeta el sistema de diseño, decide qué cambiar y qué puede esperar.
Esa revisión puede hacerse de manera informal, como tantas otras cosas en diseño: alguien mira, comenta, marca problemas, propone ajustes. A veces alcanza. Pero cuando la tarea se repite, aparecen problemas conocidos.
El criterio no siempre queda escrito. La severidad depende de quién revisa. La evidencia se pierde entre comentarios. Algunas dimensiones se mezclan: usabilidad, accesibilidad, lenguaje, consistencia visual, voz de marca. Y cuando vuelve una pantalla parecida, hay que reconstruir buena parte del proceso.
En el curso hacemos algo distinto: convertimos esa revisión en un flujo para hacer explícito el sistema de trabajo que la sostiene, no para reemplazar la mirada humana.
Primero definimos qué significa evaluar. Después qué evidencia necesita cada evaluación. Luego qué parte puede resolverse con reglas, qué parte requiere juicio asistido por un modelo y qué parte debe volver a una persona. Finalmente, cómo se consolidan resultados distintos en un reporte que sirva para decidir.
Aunque ese recorrido parece técnico, en realidad es profundamente de diseño.
Porque diseñar una herramienta de IA no es sólo escribir instrucciones. Es decidir qué cuenta como buen trabajo.
Del criterio informal a una herramienta
Aquí voy a contarte cómo lo trabajamos en el curso, pero también puedes leerlo como un proceso aplicable en general.
La primera capa del curso trabaja el paso desde una actividad repetida hacia una herramienta persistente.
Un prompt puede resolver una conversación. Una herramienta necesita algo más: intención, criterio, proceso, guardrails y formato de salida.
La intención define para qué existe. El criterio define qué mira y contra qué estándar evalúa. El proceso ordena los pasos. Los guardrails dicen qué no debe hacer, qué no puede afirmar y cuándo debe detenerse. El formato de salida hace que el resultado sea usable por una persona o por otro agente.
Y esto cambia la forma de pensar la IA.
Si le pido a un modelo “revisa esta pantalla”, delego una tarea mal definida. Si diseño una herramienta de evaluación, tengo que decidir cosas más intencionadas: qué tipo de problemas estoy buscando, qué evidencia acepto, qué severidad puede proponer, qué confianza debe declarar, qué queda como pendiente y qué necesita revisión humana.
En clase, ese cambio se vuelve práctico, porque no hablamos de criterios en abstracto: construimos evaluadores.
Por ejemplo, un evaluador de usabilidad no debería limitarse a opinar si una pantalla “funciona”. Necesita un marco de revisión, una lista de chequeos, una escala de severidad, evidencia por hallazgo y un mecanismo para que una persona confirme, ajuste o rechace lo que el modelo propone.
Ahí aparece una idea clave del curso: el agente no es valioso porque decide más. Muchas veces es valioso porque prepara mejor la decisión.
Evidencia antes que opinión
Una de las diferencias más importantes entre pedir una respuesta y diseñar un flujo es la evidencia.
Cuando una persona le pide a la IA que revise una interfaz, muchas veces recibe una lista de recomendaciones. Algunas pueden ser buenas. El problema es que no siempre queda claro desde dónde salieron.
¿El modelo vio la pantalla completa? ¿Leyó el DOM? ¿Analizó sólo texto? ¿Tenía una captura visual? ¿Pudo inspeccionar estados interactivos? ¿Está evaluando una URL viva o una descripción que alguien pegó en el chat?
En el curso tratamos esa diferencia como parte del diseño del flujo.
Un mismo evaluador puede tener distintos proveedores de evidencia. Puede trabajar con una captura simple, con texto extraído, con una inspección local más reproducible o con un reporte externo. Cada camino habilita cosas distintas y deja otras fuera.
La herramienta tiene que declarar eso.
Si sólo tiene texto, no debería fingir que evaluó jerarquía visual. Si no pudo revisar interacción, no debería declarar que no hay problemas de interacción. Si no tiene una referencia de sistema de diseño, no debería inventar una regla estética y llamarla incumplimiento.
Esto es menos vistoso que decir “un agente audita tu producto”. Pero es mucho más útil.
Porque en diseño, saber qué no se pudo evaluar es parte de la calidad del diagnóstico.
Un flujo central: validación agéntica de diseño
El caso central del curso es un flujo de validación de diseño.
La idea es simple de decir y rica de construir: distintos skills revisan una propuesta desde dimensiones distintas y un orquestador consolida el resultado.
Una dimensión mira usabilidad. Otra accesibilidad. Otra escritura. Otra voz y tono. Otra consistencia con el sistema de diseño. Cada una trabaja con su propio criterio, su propia evidencia y su propio contrato de salida.
Esto evita una trampa común: pedirle a un único agente —o a un solo skill— que revise “todo”.
Cuando todo queda dentro de un solo agente, las responsabilidades se mezclan. Usabilidad empieza a sonar como opinión general. Accesibilidad queda reducida a recomendaciones obvias. Voz y tono se confunde con corrección lingüística. Sistema de diseño se vuelve gusto visual. Y el reporte final termina siendo una lista prolija, pero difícil de auditar.
Separar dimensiones obliga a precisar.
Una auditoría de accesibilidad necesita distinguir verificaciones automáticas, criterios manuales, nivel WCAG y cobertura. Un validador de lenguaje necesita separar ortografía, claridad, variante regional y escritura de interfaz. Un auditor de voz y tono necesita una referencia explícita, no sólo una sensación de “suena bien”. Un verificador de sistema de diseño necesita tokens, componentes, variantes, estados y reglas de uso.
Después aparece el orquestador.
Su trabajo no es reemplazar a los evaluadores especializados. Su trabajo es coordinar: preparar la corrida, detectar insumos faltantes, delegar tareas, recolectar resultados, validar salidas estructuradas, normalizar prioridades sin convertir todo en un promedio falso y encontrar patrones transversales.
Ese punto es importante: un orquestador no es un agente mágico que hace todo. Es una pieza de coordinación.
Y coordinar también es diseñar.
Otros flujos: research, sistema de diseño, lenguaje
El flujo de validación de diseño es el caso principal del curso, pero no es el único ejemplo que usamos para pensar.
Un caso similar es el análisis de research.
En el artículo Investigar con IA no es pedirle análisis al modelo planteé una distinción que se conecta directamente con este curso: investigar con IA no debería ser subir un archivo y pedir “dame los insights”. El problema no es usar IA para analizar. El problema es no saber qué parte fue cálculo, qué parte fue interpretación, qué evidencia lo sostiene y qué quedó fuera.
Ese mismo principio puede convertirse en una herramienta.
En un flujo de research, los números no deberían salir de la imaginación del modelo. Las frecuencias, porcentajes y cierres deberían venir de operaciones determinísticas. El modelo puede ayudar a interpretar respuestas abiertas, proponer categorías o sintetizar tensiones, pero no debería inventar conteos. Y antes de ejecutar un análisis, una persona debería aprobar el método, entender qué se va a calcular y qué limitaciones tendrá el resultado.
Ahí se ve el patrón: cálculo por un lado, interpretación por otro, validación humana en el punto correcto y reporte trazable al final.
Otro ejemplo es sistema de diseño.
La versión floja sería pedirle al modelo: “revisa si esta interfaz respeta el design system”. La versión más seria exige una referencia: tokens, tipografías, componentes, variantes, estados y reglas de uso. Sin esa referencia, la herramienta puede describir lo que observa, pero no debería declarar cumplimiento.
Esto enseña una lección transferible: una herramienta de IA no puede evaluar contra un criterio que nadie explicitó.
Lo mismo ocurre con voz y tono.
No alcanza con pedir “revisa si suena bien”. Primero hay que convertir muestras, guía de marca o criterios editoriales en un perfil auditable. Después se puede comparar una pieza contra ese perfil. Algunas cosas serán reglas bastante verificables: términos prohibidos, tratamiento, promesas absolutas, exceso de exclamaciones. Otras serán juicio interpretativo: adecuación del tono, distancia respecto de la voz esperada, ajuste a un escenario.
Y con lenguaje pasa algo similar. No todo problema textual es igual. Un signo de apertura faltante tiene una verificabilidad distinta a una frase confusa. Una variante regional no es un error universal. Un microcopy puede estar gramaticalmente correcto y aun así ser débil para la acción que debe sostener.
Estos ejemplos importan porque muestran que el curso no trata de memorizar una herramienta o una plataforma, sino de aprender a diseñar la distribución de trabajo entre reglas, modelos, documentos, evidencia y personas.
El diseñador sigue en el medio
Hay una forma fácil de vender agentes: prometer autonomía.
Agentes que revisan. Agentes que deciden. Agentes que producen. Agentes que hacen el trabajo completo.
Esa versión puede sonar atractiva —especialmente para el nivel ejecutivo—, pero para diseño, como la mentira, tiene patas cortas. Se rompe rápido cuando aparecen contexto, ambigüedad, consecuencias o responsabilidad.
En diseño, muchas decisiones dependen de contexto, consecuencias, usuarios, estrategia, restricciones de producto, deuda acumulada y criterio profesional. No todo eso está en una pantalla, un archivo o un prompt.
Por eso, en el curso no trabajamos la idea de sacar al diseñador del proceso.
Trabajamos algo más concreto: construir herramientas para que el diseñador intervenga donde tiene más valor.
Eso cambia el lugar de la intervención. El diseñador no desaparece: define el criterio, decide qué evidencia sirve, revisa los casos ambiguos, corrige el método y toma decisiones cuando hay consecuencias para usuarios, producto o negocio.
No repitiendo instrucciones cada vez. No reconstruyendo contexto desde cero. No revisando manualmente cosas que una regla puede detectar mejor. No aceptando sin evidencia una síntesis que suena razonable.
Sino definiendo criterios, revisando excepciones, aprobando métodos, ajustando severidades, decidiendo qué hallazgos importan y qué recomendaciones tienen sentido para el producto.
Un buen flujo con agentes no elimina la responsabilidad profesional. La vuelve más visible.
Qué se trabaja, en detalle
Dicho de forma más directa, en el curso trabajamos esto:
Primero, cómo detectar una actividad del proceso de diseño que vale la pena convertir en herramienta. No todo merece sistematizarse. Algunas cosas viven bien en el chat. Otras se repiten tanto, dependen de tanto criterio o tienen tanto costo de error que conviene convertirlas en un recurso reusable.
Después, cómo escribir ese criterio. Qué mirar, con qué estándar, en qué orden, con qué límites y con qué formato de salida. Esta parte parece prompting, pero no es sólo prompting. Es diseño de comportamiento.
Luego, cómo decidir qué parte debe resolver una regla y qué parte debe resolver un modelo. Esto aparece en accesibilidad, research, lenguaje y sistema de diseño. Hay cosas que conviene calcular, validar o capturar de forma determinística. Hay cosas que requieren juicio. Mezclarlas produce reportes elegantes, pero frágiles.
También trabajamos cómo probar una herramienta. Qué casos usar, cómo registrar resultados, cómo detectar varianza, cómo saber si una salida es estable y cuándo no conviene confiar demasiado.
Más adelante, separamos responsabilidades. En vez de construir un agente enorme que haga todo, dividimos el trabajo en piezas especializadas: un evaluador por criterio, un contrato de salida, un resumen estructurado que otro agente pueda leer, un orquestador que coordine.
Después externalizamos criterio. Lo que estaba dentro de un prompt empieza a vivir en documentos: perfiles, specs, reglas, schemas, bases de conocimiento. Esto es clave porque el criterio profesional no debería quedar enterrado en instrucciones imposibles de mantener.
Finalmente, armamos el flujo completo: agentes especializados, handoffs, memoria de decisiones, gobernanza mínima y consolidación de resultados. Ahí entran con más sentido herramientas como Codex o Claude Code: no como promesa de programación para diseñadores, sino como entornos donde un agente puede trabajar con archivos, instrucciones persistentes, scripts, reportes y evidencias.
No para construir una máquina autónoma que decide por todos, sino para construir un sistema de trabajo donde humanos, modelos y herramientas cumplen roles distintos.
Por qué esto importa profesionalmente
Para mí, éste es el cambio más interesante.
Durante una primera etapa, trabajar con IA en diseño significó aprender a pedir mejor: mejores prompts, más contexto, ejemplos, formatos, restricciones. Eso sigue siendo útil. Pero cuando el trabajo se vuelve recurrente, pedir mejor no alcanza.
Ahí empieza otra capacidad: diseñar sistemas de trabajo con IA.
Esa capacidad no pertenece sólo a perfiles técnicos. Un diseñador con criterio, experiencia y conocimiento de su proceso tiene mucho que aportar, precisamente porque sabe qué se está evaluando, qué consecuencias tiene una mala recomendación, qué límites no deberían cruzarse y qué decisiones no se pueden delegar sin más.
La dificultad es que ese criterio muchas veces vive de forma tácita.
Está en la cabeza, en conversaciones, en hábitos de revisión, en ejemplos pasados, en estándares no escritos, en documentos dispersos. El curso trabaja sobre esa materia: cómo convertir parte de ese criterio en herramientas que otros puedan usar, revisar, corregir y mejorar.
Eso cambia la relación con la IA.
Ya no se trata sólo de usar una herramienta. Se trata de diseñar cómo trabaja esa herramienta dentro de un proceso.
Si te interesa construir este tipo de flujos
Agentes y Skills para Diseño es un curso práctico para diseñadores y profesionales de producto que ya usan IA y quieren avanzar hacia herramientas propias, skills, agentes y flujos de trabajo.
Durante seis clases en vivo construimos, paso a paso, un flujo agéntico de validación de diseño. A partir de ese caso, usamos otros ejemplos para entender cómo se transfiere el patrón a research, escritura, voz y tono, sistema de diseño y documentación.
No hace falta saber programar. Sí hace falta tener ganas de trabajar con más precisión: explicitar criterio, probar resultados, separar responsabilidades y decidir qué no conviene automatizar.
Si la IA te interesa, pero sientes que te faltan bases, mira IA para Diseñadores.
