Prompts para diseño UX/UI: cómo hablar con la IA para que sea realmente útil

Durante los últimos meses he visto muchos prompts que prometen resultados extraordinarios. Plantillas universales, listas con cien instrucciones imprescindibles y estructuras que, supuestamente, convierten cualquier petición en una respuesta perfecta.

Mi experiencia es bastante menos espectacular.

No creo que exista el prompt definitivo. Tampoco creo que aprender cómo crear prompts para IA consista en descubrir una combinación secreta de palabras. En diseño, los prompts para UX/UI funcionan mejor cuando explican con claridad el problema, el contexto del proyecto y los criterios que utilizaremos para revisar el resultado. Un buen prompt no es un hechizo. Es una manera de explicar un problema con suficiente claridad para que la herramienta pueda trabajar sobre una base útil.

Esto implica saber qué queremos conseguir, para quién estamos diseñando, qué información tenemos, qué límites debemos respetar y cómo valoraremos la respuesta.

Cuando todo esto no está claro, la IA no resuelve el problema. Rellena los vacíos. Y suele hacerlo con soluciones plausibles, correctas y muy parecidas a las que podría ofrecer a cualquier otra persona. La calidad de un prompt no depende de cómo suena. Depende de la calidad de las decisiones que contiene.

Hablar con la IA también es un trabajo de diseño

Cuando preparo un prompt, estoy realizando una parte del mismo ejercicio que haría antes de empezar a diseñar una interfaz.

Tengo que entender el contexto, separar las necesidades reales de las suposiciones, decidir qué es prioritario y qué es secundario, detectar contradicciones y explicar qué resultado espero obtener. Por eso, construir un buen prompt se parece más a preparar un briefing que a escribir una orden. La pregunta no es solo qué quiero que genere, sino:

Este planteamiento coincide con las recomendaciones de la documentación profesional de OpenAI sobre buenas prácticas de prompting, que insiste en proporcionar instrucciones claras, específicas y bien estructuradas. Anthropic también recomienda empezar definiendo los criterios de éxito antes de intentar perfeccionar una instrucción: si no sabemos qué significa obtener un buen resultado, difícilmente podremos dirigir o evaluar el modelo.

En diseño UX/UI esto es especialmente importante. Una propuesta visual puede parecer convincente sin resolver correctamente la jerarquía, la navegación, la accesibilidad o el objetivo de conversión. La facilidad para generar una pantalla no elimina la necesidad de justificarla.

Cómo construir un prompt de diseño UX/UI

No utilizo siempre la misma plantilla. Los prompts para diseño UX/UI deben adaptarse a la tarea concreta: un análisis de arquitectura de contenidos no necesita las mismas instrucciones que una propuesta de microcopy, un prototipo visual o una revisión de accesibilidad. Por eso, cuando explico cómo escribir un buen prompt, no parto de una fórmula cerrada, sino de una estructura flexible que obliga a definir las decisiones importantes. Aun así, suelo preparar los prompts a partir de una estructura estable:

Esta estructura también resulta útil para diseñadores que empiezan a incorporar la IA en su trabajo. Los prompts para diseñadores no deberían limitarse a describir una pantalla o un estilo visual: deben aportar la información necesaria para que la herramienta entienda qué decisión estamos intentando tomar y qué condiciones debe respetar.

No es necesario que todos los bloques sean largos. Deben ser lo bastante concretos como para evitar que las decisiones importantes queden abiertas.

Dónde estamos y por qué estamos trabajando

La IA no conoce el proyecto por el hecho de que nosotros llevemos semanas pensando en él. Cuando abro una conversación nueva, intento contextualizar y explicar el tipo de producto, el sector, el estado del proyecto y la situación desde la que trabajaremos. No es lo mismo analizar una web que todavía no existe que revisar un e-commerce con miles de productos, una arquitectura consolidada y datos reales de comportamiento. Un contexto útil podría ser:

Estamos rediseñando la web de un fabricante B2B de materiales técnicos. La web actual tiene una arquitectura compleja, muchos productos similares y usuarios con niveles de conocimiento muy diferentes. No queremos simplificar eliminando información técnica, sino facilitar que cada perfil encuentre el producto adecuado.

Este texto todavía no indica qué tarea debe llevar a cabo la IA. Primero sitúa el proyecto y el problema sobre el que deberá trabajar.

Qué no está funcionando

«Quiero mejorar esta página» es una petición demasiado abierta. Mejorarla podría significar hacerla más clara, más visual, más rápida o más accesible, pero también aumentar la conversión o reducir las consultas comerciales. Por eso intento formular el problema de manera observable:

Los usuarios no entienden la diferencia entre las tres familias de productos y acceden repetidamente a fichas que no corresponden a su aplicación.

A partir de aquí, la IA puede proponer hipótesis o estructuras relacionadas con una dificultad concreta. Sin esta información, probablemente sugerirá cambiar el titular, añadir iconos o crear tres tarjetas. Quizá quede bien, pero no sabremos si responde al problema real.

Evitar la persona genérica

Uno de los riesgos más frecuentes es diseñar para un usuario abstracto que lo entiende todo, tiene tiempo, lee cada texto y actúa exactamente como esperamos. Cuando trabajo con IA, intento describir la situación del usuario y no limitarme a indicar su edad o profesión. También me interesa saber qué intenta conseguir, qué sabe antes de llegar, qué no entiende, qué objeciones puede tener, desde qué dispositivo o en qué situación consulta la información y qué puede hacer que abandone o no continúe el proceso. Por ejemplo:

El usuario principal es un responsable de compras que conoce la aplicación final, pero no domina la composición técnica de los materiales. Necesita comparar opciones y justificar internamente la decisión. Consulta la web desde un ordenador durante la jornada laboral y valora poder descargar documentación técnica.

Esta descripción condiciona la arquitectura, el lenguaje, las comparaciones, los CTA y la documentación que debería aparecer.

Separar los objetivos del usuario y del negocio

Un prompt profesional no debería confundir el objetivo del negocio con el de la persona usuaria. El negocio puede querer conseguir contactos comerciales. El usuario, en cambio, puede necesitar saber si un producto soporta una determinada temperatura.

La solución debe conectar ambos objetivos sin convertir la experiencia en una sucesión de formularios y botones comerciales. Por eso, cuando hay más de un objetivo, los escribo por separado:

Esta separación ayuda a la IA, pero sobre todo me obliga a mí a no dar por hecho que ambas necesidades son la misma.

Trabajar con información real

Cuando existen contenidos, datos, capturas, entrevistas, analítica, requisitos o documentación, los incorporo. Pedir una arquitectura sin facilitar el contenido real suele producir estructuras aparentemente ordenadas, pero desconectadas del volumen, la complejidad y las relaciones que tendrá el proyecto.

También aprovecho para indicar a la IA que utilice únicamente la información proporcionada y que, cuando falte un dato necesario, lo señale como información pendiente. Le pido que no invente funcionalidades, métricas, testimonios ni necesidades de usuario. Esta instrucción no elimina completamente los errores, pero deja claro que prefiero un vacío visible antes que una respuesta aparentemente completa.

Concretar qué debe hacer la IA

Una instrucción como «analiza esta página» describe una acción, pero no define el alcance ni el nivel de profundidad. Cuando encargo una tarea, intento concretar desde qué perspectiva debe abordarse:

Analiza la página desde el punto de vista de la jerarquía visual, la comprensión del contenido, la navegación, la accesibilidad y la continuidad entre el objetivo del usuario y el CTA principal.

Este nivel de precisión es especialmente importante en los prompts para crear interfaces. Pedir una pantalla, una landing o un flujo no es suficiente si no indicamos qué problema debe resolver, qué información debe priorizar y qué comportamiento esperamos de cada elemento. La IA puede generar una composición visual coherente, pero necesita criterios para que esa composición también sea funcional. También especifico qué quiero recibir:

Para cada problema detectado, indica: qué has observado, por qué puede perjudicar la experiencia, qué principio o criterio utilizas para valorarlo, qué mejora propones y qué riesgo o inconveniente podría tener la propuesta.

Este último punto es importante. Si solo pedimos soluciones, la IA tiende a presentarlas con mucha seguridad. Cuando también le pedimos riesgos, objeciones o alternativas, obtenemos una respuesta menos complaciente y más crítica y fácil de revisar.

Definir restricciones

Las restricciones sirven para delimitar las decisiones que la IA puede tomar y evitar que complete la propuesta con suposiciones que no se corresponden con el proyecto. Puedo indicarle que no modifique una arquitectura ya validada, que no elimine contenidos técnicos, que no invente funcionalidades ni testimonios o que no utilice patrones visuales que entren en conflicto con el sistema de diseño existente. También puedo pedirle que marque claramente cualquier información que falte en lugar de sustituirla por un contenido inventado. Las restricciones no garantizan que el modelo no cometa errores, pero hacen visibles los límites del trabajo y facilitan la revisión posterior.

El formato también forma parte del prompt

No pido una tabla porque sí, sino cuando necesito comparar información de forma clara. Tampoco pido siempre una respuesta breve, porque el formato debe responder a la decisión que tendré que tomar después y facilitar el trabajo posterior.

Según la tarea, puedo necesitar una auditoría priorizada por impacto y esfuerzo, varias arquitecturas alternativas con sus ventajas e inconvenientes, un flujo explicado paso a paso o una primera propuesta seguida de una autocrítica. En otros casos, puede resultarme más útil obtener un inventario de componentes, separar las hipótesis de los hechos confirmados, identificar las preguntas pendientes antes de continuar o recibir una respuesta preparada para convertirse en documentación.

La documentación de Google sobre el uso de modelos de lenguaje en escritura técnica muestra precisamente que una instrucción detallada y orientada al resultado evita que el modelo tenga que adivinar la intención del usuario. No se trata de controlar cada frase, sino de dar forma a la respuesta para que sea más fácil de revisar, comparar, documentar y compartir con el resto del equipo. Esta claridad también es esencial para conseguir una buena comunicación entre diseñadores y desarrolladores.

Establecer criterios de revisión

Antes de aceptar una respuesta, necesito saber cómo voy a valorarla. Puedo pedir que la propuesta se revise desde el punto de vista de la usabilidad, la accesibilidad, la coherencia con la marca, la simplicidad, la viabilidad técnica o la relación entre el objetivo del usuario y el del negocio. También puedo solicitar que la IA separe los hechos proporcionados de las inferencias y las recomendaciones, que señale los riesgos de cada propuesta y que indique qué cuestiones todavía necesitan validación. Los criterios de revisión no convierten la respuesta en correcta, pero ayudan a evitar que la primera solución plausible se presente como una decisión definitiva.

Cómo conseguir respuestas más útiles

Explicar el criterio, no solo el resultado

En lugar de utilizar prompts genéricos para diseñar webs, como «crea una landing minimalista», prefiero explicar qué significa la simplicidad en ese proyecto y qué decisiones debe ayudarme a resolver la propuesta:

Propón una landing con una jerarquía visual clara y un número reducido de decisiones simultáneas. La simplicidad debe provenir del orden y la priorización, no de eliminar información necesaria.

Dar referencias interpretadas

Las referencias son útiles cuando explico qué me interesa de cada una.

De la primera referencia me interesa la manera de presentar las categorías. De la segunda, el ritmo visual y la relación entre texto e imagen. No quiero reproducir su tipografía, sus colores ni su estructura exacta.

Esto ayuda a separar los principios, el estilo y el contenido. Una referencia sin comentarios puede interpretarse como una petición de imitación. Una referencia explicada funciona como una decisión de dirección creativa.

Proporcionar ejemplos

Cuando necesito un formato o un nivel de calidad concreto, suelo incluir un ejemplo breve.

OpenAI y Anthropic recomiendan utilizar ejemplos cuando la forma esperada de la respuesta no es evidente. Nielsen Norman Group lo resume mediante la estructura CARE (context, ask, rules, and examples): contexto, petición, reglas y ejemplos. Un ejemplo no solo enseña qué queremos. También ayuda a mostrar qué consideramos una buena respuesta.

Dividir los problemas complejos

No suelo pedir en una sola instrucción que la IA investigue, defina la arquitectura, redacte todos los contenidos, diseñe la interfaz y genere el código final. Cuando concentramos demasiadas decisiones en un mismo prompt, cualquier interpretación incorrecta al principio puede condicionar todo el resultado. Prefiero dividir el proceso en fases que pueda revisar: primero entender y resumir el contexto, después detectar la información que falta, formular hipótesis, proponer estructuras, comparar alternativas y, solo cuando la dirección está clara, desarrollarla y revisar su coherencia y accesibilidad. Esto me permite intervenir antes de que una suposición errónea se convierta en la base de toda la propuesta.

Cuando un prompt recurrente puede convertirse en una skill

Dividir un proceso en fases también tiene otra consecuencia interesante: algunas instrucciones dejan de ser prompts puntuales y se convierten en formas de trabajo que repetimos proyecto tras proyecto.

Figma está llevando esta idea directamente a su agente con las Custom Skills, que permiten agrupar workflows recurrentes en conjuntos reutilizables de instrucciones. Esto evita tener que explicar cada vez los mismos pasos, convenciones o criterios y abre la puerta a convertir en una skill procesos como una revisión de accesibilidad, una crítica de diseño o la comprobación de una interfaz según las reglas del design system del equipo.

Esto no elimina la necesidad de escribir buenos prompts. Lo que cambia es que una parte del contexto y de las instrucciones puede dejar de estar dentro de cada petición y pasar a formar parte de un proceso reutilizable. Para mí, este es un paso importante: pasar de saber dar una buena instrucción a saber definir una buena manera de trabajar con la IA.

Qué intento no decirle

«Hazlo moderno»

«Moderno» no describe una necesidad ni define una estética concreta. Puede significar utilizar una tipografía sans serif de grandes dimensiones, animaciones, degradados, formas tridimensionales o cualquier patrón visual que el modelo asocie con las tendencias actuales. Prefiero explicar qué debe transmitir la interfaz, qué tipo de relación debe establecer con el contenido y qué percepción queremos generar en el usuario.

«Hazlo más UX»

La UX no es una capa que pueda añadirse al final de un diseño. Puedo pedir que se reduzca la carga cognitiva, que el estado del sistema sea más visible, que se facilite la recuperación ante un error o que se prioricen mejor las tareas principales. En cambio, pedir que una propuesta sea «más UX» no aporta ningún criterio concreto que pueda analizar, aplicar o contrastar.

«Sorpréndeme»

A veces dejo espacio para explorar. Pero sorprender no debería ser el único objetivo de una experiencia. Si utilizo esta indicación, la limito:

Explora una alternativa menos convencional, pero mantén visibles las acciones principales, respeta los patrones de interacción necesarios y explica qué valor aporta cada desviación.

La innovación sin justificación puede convertirse rápidamente en fricción.

«Actúa como el mejor diseñador del mundo»

Asignar un rol puede ayudar a situar una perspectiva, pero no sustituye el contexto. Decirle que actúe como un diseñador UX sénior no explica el proyecto, el usuario ni los criterios de calidad. Puede influir en el vocabulario y en el tono de la respuesta, pero no aporta la información necesaria para tomar buenas decisiones. Cuando utilizo un rol, intento concretar la responsabilidad que debe asumir: por ejemplo, revisar una propuesta antes de presentarla al cliente, diferenciar los problemas observables de las hipótesis y no validar una decisión únicamente porque parece visualmente coherente. El valor del rol no consiste en atribuir una autoridad ficticia a la IA, sino en definir desde qué punto de vista debe analizar la tarea.

«No te equivoques» o «no inventes nada»

Puedo indicarlo, pero no lo considero una garantía. Los modelos generativos construyen respuestas plausibles a partir del contexto disponible y pueden ofrecer información incorrecta o presentar una inferencia como si fuera un hecho. Por eso, en lugar de confiar únicamente en una prohibición, prefiero establecer mecanismos de control y pedir que separe los hechos proporcionados, las inferencias y las recomendaciones, y que indique qué afirmaciones necesitan verificación externa. La revisión sigue siendo responsabilidad mía.

Un prompt no es una conversación cerrada

Uno de los errores que cometía al principio era intentar preparar una instrucción tan completa que no fuera necesario seguir hablando con la herramienta. Ahora prefiero entender el prompt como el inicio de un proceso. La primera respuesta me sirve para comprobar qué ha entendido la IA, qué suposiciones ha hecho y cómo ha interpretado las prioridades. A partir de aquí puedo corregir, profundizar o cambiar de dirección.

Durante esta fase suelo pedirle que resuma qué ha entendido antes de proponer soluciones, que señale las contradicciones y que identifique la información que necesita para evitar una respuesta genérica. También me resulta útil hacer visibles las principales suposiciones de la propuesta, pedir una alternativa que contradiga la primera dirección o revisar la solución desde la perspectiva de un usuario con pocos conocimientos técnicos. Otras veces le pido que valore qué eliminaría para simplificar la experiencia o que no continúe desarrollando la propuesta hasta que la estructura esté validada. Esta manera de trabajar me permite dirigir la herramienta sin delegar en ella todo el proceso.

Pedir una crítica es mejor que pedir una validación

Las herramientas conversacionales tienden a seguir la dirección que les planteamos. Si presento una idea y simplemente pregunto si es buena, es fácil obtener una justificación convincente que refuerce mi propuesta inicial. Por eso intento formular preguntas que permitan cuestionar y que obliguen a buscar sus puntos débiles.

Puedo preguntar qué motivos harían que una estructura fracasara, qué necesidades de usuario quedarían mal resueltas, qué partes dependen de una suposición no validada o cuál sería la alternativa más simple. También puedo preguntar qué podría interpretar mal una persona que llega por primera vez o qué decisiones visuales todavía no tienen una justificación funcional. No busco que la IA tenga la última palabra, sino que me ayude a ampliar la cantidad y la calidad de las preguntas que soy capaz de plantearme.

No todos los errores se resuelven mejorando el prompt

A veces una respuesta no funciona porque la instrucción es ambigua, pero también puede fallar porque falta información, porque el modelo no es adecuado para esa tarea o porque estamos intentando automatizar una decisión que necesita investigación real. La documentación de Anthropic advierte que no todos los problemas de rendimiento se resuelven mediante prompt engineering. Antes de reescribir indefinidamente una instrucción, conviene comprobar si disponemos de buenos criterios de éxito, pruebas y datos suficientes.

Si quiero saber por qué los usuarios abandonan un proceso de compra, puedo utilizar la IA para analizar entrevistas, agrupar incidencias o formular hipótesis. Lo que no puedo hacer es sustituir esas entrevistas por una descripción inventada de un usuario y esperar obtener una conclusión fiable. Un prompt puede ordenar el conocimiento disponible. No puede fabricar la evidencia que no hemos recopilado.

Probar un prompt también es investigar

No doy por bueno un prompt porque haya funcionado una vez. Cuando una instrucción va a formar parte de un proceso recurrente, intento probar con situaciones diferentes y observar en qué puntos varía el resultado, qué ambigüedades aparecen y qué partes dependen demasiado de la interpretación del modelo.

Nielsen Norman Group defiende que las herramientas de IA deben probarse con escenarios reales de diseño y que sus resultados deben evaluarse mediante una metodología explícita, en lugar de basarse únicamente en demostraciones atractivas. En un entorno profesional esto significa comprobar cómo responde el prompt en un caso sencillo y bien documentado, pero también ante información incompleta, requisitos contradictorios, un volumen de contenido superior al habitual, necesidades específicas de accesibilidad o datos poco fiables. Estas pruebas permiten descubrir si la instrucción es realmente útil o si solo funciona en el caso ideal para el que la hemos preparado.

Los prompts también pueden convertirse en parte del sistema de trabajo

Este cambio es especialmente interesante cuando trabajamos en equipo. El 13 de agosto de 2026, Figma anunció en sus Release Notes que las Agent Skills se abrían a la Community, con más de 50 skills orientadas a distintos procesos y con la posibilidad de crear nuevas a partir del contexto de un archivo.

Esto permite imaginar procesos en los que una parte de los criterios que hasta ahora vivían en documentación, reuniones o prompts personales pueden convertirse en recursos compartidos. Una revisión de componentes, una comprobación antes del handoff o unas directrices específicas del design system podrían dejar de depender exclusivamente de que cada diseñador recuerde y vuelva a escribir todas las instrucciones.

Pero automatizar un criterio no lo convierte automáticamente en un buen criterio. Si una skill parte de un proceso mal definido, simplemente conseguiremos repetirlo con mayor rapidez. La responsabilidad sigue estando en decidir qué merece la pena sistematizar, qué reglas debe seguir y cuándo necesitamos revisar el resultado.

Una estructura práctica para empezar

Cuando necesito preparar una primera versión, suelo usar una estructura como esta:

No es una fórmula obligatoria. Es un punto de partida para no olvidar las decisiones que más condicionan el resultado.

Ejemplo: de un prompt genérico a una instrucción útil

Prompt demasiado abierto

Diseña una home moderna para una marca de bicicletas eléctricas.

Es probable que el resultado incorpore una imagen grande, un titular emocional, tarjetas de producto y diversos CTA. Puede parecer una web real, pero la IA habrá decidido casi todo: el público, el posicionamiento, la arquitectura, el contenido, el estilo y la prioridad comercial.

Prompt trabajado

Estamos rediseñando la página de inicio de una marca europea de bicicletas eléctricas urbanas. La marca quiere transmitir ligereza, tecnología accesible y confianza, evitando una estética agresiva o excesivamente deportiva.

El usuario principal compara modelos y necesita identificar rápidamente qué bicicleta encaja con su altura, el tipo de trayecto y su experiencia de conducción. La dificultad actual es que los modelos parecen demasiado similares y las diferencias técnicas no ayudan a decidir.

Propón la arquitectura de contenidos de la página de inicio. Prioriza la orientación entre modelos antes de mostrar todas las especificaciones. Incluye los contenidos necesarios, el objetivo de cada sección y la transición entre una sección y la siguiente.

No redactes todavía el copy final ni definas el estilo visual. No inventes características de producto. Cuando necesites un dato que no está disponible, márcalo entre corchetes.

Presenta dos alternativas:

1. Una estructura guiada por las necesidades del usuario.
2. Otra organizada por familias de producto.

Compara las ventajas, los riesgos y el tipo de usuario que resuelve mejor cada alternativa. Termina recomendando qué opción investigamos primero, pero no la presentes como una decisión válida.

Este prompt no garantiza una buena arquitectura. Pero hace visibles las decisiones, limita las invenciones y produce un resultado que puedo analizar.

La IA responde. Yo sigo siendo responsable

Puedo mejorar mucho la manera de hablar con una inteligencia artificial. Puedo aportar más contexto, ejemplos, restricciones y criterios. Puedo dividir una tarea, revisar sus suposiciones y probar el prompt con situaciones diferentes. Todo esto reduce la ambigüedad, pero no elimina la necesidad de pensar.

Como diseñadora UX/UI, sigo siendo responsable de comprobar si la propuesta responde a una necesidad real, si deja fuera a algún perfil, si respeta la accesibilidad, si simplifica la experiencia y si encaja con los objetivos del proyecto. La IA no conoce automáticamente las conversaciones con el cliente, los matices de la marca, las limitaciones internas ni las contradicciones que hemos ido descubriendo durante el proceso. Solo puede trabajar con lo que le proporcionamos y con los patrones que ha aprendido.

Por eso no considero que saber escribir prompts sea una competencia separada del diseño. Es una extensión de capacidades que ya necesitábamos: investigar, sintetizar, formular problemas, explicar decisiones, dar feedback y reconocer cuándo una propuesta no es suficientemente buena.

Un buen prompt no resuelve por sí solo un proyecto de diseño. Es una parte más de un proceso en el que seguimos teniendo que entender el problema, observar al usuario y valorar críticamente cada propuesta. Esta es también la idea que desarrollamos cuando hablamos de cómo integrar la IA en el proceso de diseño UX/UI sin perder creatividad, criterio ni visión de usuario.

Cuando la IA también puede utilizar nuestras herramientas

Los prompts tampoco están quedando limitados a una conversación con un modelo. Las herramientas de diseño empiezan a conectar los agentes con el entorno real de trabajo.

Figma explicaba el 11 de agosto de 2026 en sus Release Notes que su servidor MCP ampliaba la integración con agentes externos para que pudieran ejecutar herramientas creadas con Figma Weave desde clientes como ChatGPT, Claude o Cursor. Esto permite que el agente identifique la herramienta adecuada, la utilice y devuelva el resultado manteniendo el contexto de la conversación.

Esto puede reducir una fricción muy habitual: tener que trasladar manualmente el contexto entre la conversación con la IA, las referencias y la herramienta de diseño. Pero también introduce una diferencia importante. Cuando la IA deja de limitarse a proponer y puede empezar a ejecutar acciones, definir bien las restricciones, los puntos de revisión y qué puede hacer sin nuestra intervención se vuelve todavía más relevante.

Un buen prompt ya no solo debe explicar qué queremos obtener. Cada vez más, también tendrá que dejar claro qué puede hacer el agente, con qué herramientas y hasta dónde puede llegar antes de volver a nosotros.

Cuándo parar

No utilizo la inteligencia artificial en todas las fases ni para todas las decisiones. A veces necesito observar sin generar nada, leer una entrevista sin resumir inmediatamente, hacer bocetos que no partan de una propuesta calculada o probar una idea sin convertirla todavía en una solución coherente.

También hay momentos en los que la velocidad de la IA puede jugar en contra. Cuando se producen diez alternativas en pocos segundos, es fácil confundir variedad con exploración. Muchas de esas alternativas pueden compartir la misma lógica y limitarse a modificar su forma. Explorar no es acumular respuestas, sino comprender mejor el problema.

Por eso, antes de escribir un prompt, intento preguntarme si la IA es realmente la herramienta que necesito. Tal vez me convenga hablar con un usuario, revisar los datos, observar un proceso o dejar reposar una idea. Saber dirigir la IA es importante, pero saber cuándo no utilizarla también forma parte del criterio profesional.

No necesitamos prompts perfectos. Necesitamos procesos revisables

La conversación sobre prompting suele centrarse en cómo obtener el mejor resultado posible a partir de una única instrucción. A mí me interesa más construir procesos en los que una respuesta mediocre pueda detectarse, cuestionarse y mejorarse antes de convertirse en una decisión.

Un buen prompt ayuda, pero no funciona por sí solo. Necesita información fiable, objetivos claros, criterios de calidad, contraste, pruebas y una persona que asuma la responsabilidad final.

Con el tiempo, probablemente dejaremos de hablar tanto de prompts. Las herramientas comprenderán mejor el contexto, trabajarán con más información y estarán más integradas en nuestros entornos. Pero la necesidad de explicar bien qué queremos conseguir no desaparecerá. Seguiremos teniendo que decidir qué problema estamos resolviendo, para quién lo hacemos, qué consideramos una buena experiencia y qué límites no queremos traspasar.

Esta evolución hacia skills, agentes y herramientas conectadas refuerza todavía más esta idea. La propia documentación de Custom Skills de Figma muestra cómo los workflows pueden dejar de depender de una instrucción puntual y pasar a formar parte de un sistema reutilizable, mientras que las actualizaciones recientes de Figma apuntan hacia agentes cada vez más integrados con el canvas y con otras herramientas.

Probablemente el futuro no consistirá en escribir prompts cada vez más largos, sino en combinar contexto, instrucciones, procesos reutilizables, herramientas y criterios de revisión. El prompt seguirá siendo una forma de comunicar una intención, pero dejará de cargar con todo el peso del proceso.

Por eso creo que saber trabajar con IA en diseño dependerá cada vez menos de encontrar la formulación perfecta y más de saber construir el sistema adecuado a su alrededor: qué información necesita, qué criterios debe respetar, qué podemos automatizar y en qué momentos necesitamos intervenir.

La IA puede interpretar nuestras instrucciones. El criterio para escribirlas, revisarlas y saber cuándo no son suficientes sigue siendo nuestro.