Prototipando con IA

Las herramientas de inteligencia artificial generativa (AGI, en sus siglas en inglés) están cambiando la naturaleza de los procesos de desarrollo software y, en consecuencia, la forma en la que diseñadoras/es nos adaptamos al mismo.

Ahora, herramientas como Figma Make, Lovable o Claude permiten generar interfaces interactivas, funcionales y con gran detalle visual a partir de simples descripciones de lo que queremos hacer en lenguaje natural, mucho más rápido, en teoría, que con el modelo de interacción gráfico point-and-click en un patrón de interacción paleta-lienzo, incluso aunque la transición comencemos a verla desde este lugar.

IA esqueumórfica: tu herramienta es tu jaula

¿Diseñas o decoras suposiciones? Por qué la IA aplicada al diseño está replicando vicios del pasado y cómo empezar a diseñar desde la lógica.

Guindo Design BlogSergio

El resultado de lo que podemos conseguir es, en muchos casos, casi indistinguible de un producto final y esto, como vimos en Fundamentos del Prototipado, tiene consecuencias.

Por un lado, trabajar en alta fidelidad implica un gran compromiso con la solución propuesta. No hay ambigüedad, no hay abstracción, es directamente un artefacto que sirve para ser evaluado por personas usuarias y que sirve como especificación concreta para el equipo de desarrollo.

Por otra parte, la generación de estos prototipos a este nivel da la apariencia de velocidad, se puede llegar antes y abarcar más, por lo que inevitablemente cambia la forma de tomar decisiones: ¿cuántos flujos, interacciones, pantallas, etc. son necesarias para probar una hipótesis de diseño? ¿Nos hemos tomado nuestro tiempo para pasar por otros niveles de fidelidad y abrir así la conversación sobre el problema?

En este artículo analizo las implicaciones de usar herramientas de IA generativa para prototipar: qué ofrecen, qué exigen, cuáles son las renuncias y cómo puedes mantener el criterio de diseño cuando la ejecución la hace la máquina.

Herramientas

Antes de entrar en el análisis me gustaría aclarar que si bien muchas de ellas están planteadas para desarrollar producto final, depende de nosotras decidir si la calidad de lo que generan es o no suficiente para ser considerado un producto.

Cuando prototipamos generalmente no tenemos ese tipo de problema, es decir, nuestra aspiración no es crear un producto sino desarrollar un concepto que pueda servir para evaluar, validar, o comunicar ideas (entre otras cosas). Por lo tanto, cualquier herramienta que encuentres disponible podría ayudarte potencialmente a conseguir hacer el prototipo que necesitas.

Lo que sí deberíamos buscar en estas herramientas es su capacidad de comprender y generar interfaces y conceptos:

• Precisión a la hora de generar exactamente lo que le estamos pidiendo. Tiene también relación con su capacidad de entender nuestro vocabulario técnico. Algunas herramientas nos permiten incluso combinar la manipulación directa de elementos con la petición de prompts en el contexto de ciertos elementos preseleccinoados.
• Eficiencia para generar una idea con el menor uso de recursos posibles, sin añadir elementos innecesarios o superficiales de los que posteriormente haya que pasar una revisión o deshacerse por innecesarios.
• Adaptación al lenguaje propio que usemos mientras le demos instrucciones que parecen claras para nosotras. Esto incluye la posibilidad de usar nuestro idioma nativo.
• Contextualización y memoria de instrucciones para elementos específicos para mejorar el entendimiento y la eficiencia.
• Coste relacionado con el uso para resolver cada prompt.

En este artículo no compararemos herramientas, las cuales están lanzándose al mercado a una velocidad inabarcable, iremos como siempre a los fundamentos.

Objetivos

La parte más compleja del diseño de cualquier interfaz o producto es saber qué quieres hacer o qué quieres comunicar, tanto si estás explorando ideas como si estás tratando de ser especificarlas.

Hay personas que desarrollan un diálogo interior según van diseñando y poniendo elementos a la vista: se piensa cuando se mira, se piensa cuando se usan las manos para dibujar en un papel y se piensa obviamente en otros momentos de introspección. Este proceso de pensamiento mientras se crea el propio artefacto es fundamental para formar un criterio propio y darnos espacio para hacer(nos) las preguntas adecuadas: no hay elemento generado por las diseñadoras que no tenga una razón de ser.

Con las herramientas de IA generativa, no sucede lo mismo. Todas esas ideas se deben traducir a instrucciones concretas y una vez dadas, una vez el modelo genere algo, tendremos que decidir cómo y cuánto tiempo dedicamos a evaluar el resultado generado de modo que nos sirva para crear este espacio de pensamiento propio.

La IA acelera y toma decisiones

Considerar las IA generativas tan solo como una versión más rápida de Figma o Penpot es el primer malentendido sobre estas herramientas. Primero porque no se han integrado en ellas para acelerar o automatizar necesidades que teníamos usando estas herramientas, por ejemplo, la creación sistemática de componentes o de versiones e iteraciones sobre una idea, sino que han venido a cambiar de forma radical la manera en la que se hace el diseño.

Como vimos en los fundamentos del prototipado, la fidelidad de un prototipo se ajusta en cuatro niveles distintos: el visual, el interactivo, el de contenidos y el funcional.

En un proceso de diseño convencional, estos niveles se trabajan de forma progresiva y deliberada, hay una intención en las decisiones que se toman en cuanto al grado de fidelidad que se quiere.

Las herramientas de IA no funcionan así. Cuando le pides a Figma Make o a Claude que genere una pantalla, el resultado llega con un nivel de fidelidad medio-alto en los cuatro planos a la vez: hay una propuesta visual, hay interacciones definidas, hay contenido de ejemplo y hay una lógica funcional implícita. Hayas tomado o no una decisión consciente sobre estos aspectos.

La herramienta no solo ejecuta, sino que rellena los huecos tomando sus propias decisiones, basadas en probabilidad y aprendidas con el diseño de otras personas. Esto, paradójicamente, lejos de eliminar incertidumbre la añade: no sabemos con qué datos ha sido entrenada la herramienta ni qué interfaces han tenido más peso en su aprendizaje.

La jerarquía visual, el diseño de contenidos, su orden, el comportamiento de cada elemento interactivo, el tono de los textos, todo esto lo ha extraído de patrones estadísticos de millones de interfaces existentes, con una coherencia aparente que hace difícil ver dónde esas decisiones tienen sentido para ti o sólo para la máquina.

Como señala el filósofo Daniel Innerarity en su teoría crítica de la inteligencia artificial, los datos no son neutrales: reflejan los intereses y los patrones de quienes los producen. En el mejor caso, el prototipo generado bebe de grandes referencias del diseño. En otros, puede estar reproduciendo decisiones convencionales, sesgos consolidados o soluciones que nadie ha cuestionado precisamente porque son las más frecuentes. La coherencia del resultado no dice nada sobre la calidad de las decisiones que lo sustentan.

Wences Sanz lo formula con precisión en un artículo reciente: "el punto ciego del entusiasmo actual es confundir capacidad de producción con capacidad de visión". Generar algo visualmente competente no es lo mismo que decidir qué merece hacerse, qué tono corresponde a cada contexto o cuándo una solución funciona y cuándo simplemente parece que funciona.

Un prototipo no es solo un artefacto visual. Es la materialización de una hipótesis de diseño. Si no sabes qué hipótesis estás evaluando, el prototipo no tiene propósito, independientemente de lo bien que se vea.

Qué nos dejamos por el camino

Para entender qué decisiones se ven afectadas y por qué importan, conviene recordar para qué sirve cada nivel de fidelidad más allá de producir un entregable.

Trabajar a baja fidelidad visual no es una limitación tecnológica ni una fase que se hace por protocolo, es una decisión deliberada para mantener la conversación abierta. Cuando algo no está definido visualmente, el equipo habla de estructura, de flujo, de lógica. Cuando algo ya tiene aspecto de producto terminado, la conversación cambia: se habla de colores, de tipografía, de si se ajusta a las expectativas o no. El nivel de fidelidad condiciona el tipo de feedback que recibes, tanto desde el equipo como desde una sesión de investigación con usuarias.

Lo mismo ocurre con el plano interactivo. Definir las interacciones de forma progresiva obliga a tomar decisiones en el orden correcto. Si todo llega junto, es fácil aceptar comportamientos que nadie ha cuestionado porque estaban ahí desde el principio. Y en el plano de contenidos, saltarse la fase de baja fidelidad significa saltarse también la pregunta sobre qué información es realmente necesaria, cuál es el tono, cuál el lugar idóneo. El contenido que genera la IA es aparentemente coherente, pero no es el tuyo ni el de tu organización. Si no lo revisas con criterio, puede acabar condicionando decisiones de arquitectura de información que sí deberían haber sido tuyas.

Lo que se pierde, en resumen, no es solo tiempo de proceso, es el espacio donde ocurre el pensamiento, donde se formulan preguntas que todavía no tienen respuesta, donde una línea mal dibujada abre una conversación que cambia el rumbo del proyecto. Como apuntamos en Prototipando con wireframes, el wireframe es propositivo y ambiguo por diseño. La IA elimina esa ambigüedad antes de que hayas podido aprovecharla.

Cómo podemos adaptarnos

Ni todo lo que se acelera se pierde, ni pone en riesgo el proceso, ni tampoco se conserva sin esfuerzo. Usar la IA en una fase avanzada del proceso —una vez tienes clara la hipótesis que quieres evaluar, el flujo que quieres prototipar y los criterios con los que vas a revisar el resultado— es una forma de aprovechar su velocidad sin sacrificar el pensamiento previo. A veces la velocidad nos permite llegar más lejos, y en diseño, aunque no sepamos el camino que tomará sí podemos tener clara una visión de dónde queremos llegar.

El problema aparece cuando se invierte el orden: cuando el prototipo llega antes que las preguntas y el proceso de definición se da por hecho porque el resultado ya existe y tiene buen aspecto.

Lo que tenemos que proteger y mantener presente es la conversación que habría ocurrido durante el proceso manual. No siempre es posible ni necesaria —si trabajas en solitario, si el problema está bien definido, si el prototipo tiene un propósito muy concreto puede ser un coste asumible— pero conviene ser consciente de la situación.

Por otro lado, el cambio de rol que implica todo esto tampoco es menor. Dejas de ser quien crea el diseño para convertirte en quien lo verbaliza, lo evalúa y lo corrige. No es un rol cómodo ni natural para todos los perfiles, y exige un nivel de experiencia que permita distinguir qué decisiones son acertadas, cuáles son discutibles y cuáles son directamente incorrectas.

Sin ese criterio previo, la revisión del resultado se convierte en una validación superficial. Y además tiene consecuencias a largo plazo: si el rol del diseñador se reduce progresivamente a evaluar y corregir output generado, la práctica activa del diseño disminuye. Y como cualquier habilidad que se ejercita poco, tiende a atrofiarse. No es un argumento contra el uso de estas herramientas, sino una razón más para no delegarles más de lo necesario y para mantener espacios de trabajo donde las decisiones de diseño y el criterio sigan siendo los tuyos desde el principio.

Qué le entregamos a desarrollo

Cuando el prototipo generado por IA tiene un nivel de fidelidad tan próximo al producto final, surge una pregunta que no siempre se hace explícitamente: ¿Esto ya es un entregable para desarrollo?

La respuesta depende de un acuerdo previo que cada equipo tiene que alcanzar por sí mismo, porque las opciones implican roles distintos para el diseño:

1. El prototipo puede funcionar como especificación directa si el código o el diseño generado tiene suficiente calidad técnica y el equipo de diseño ha revisado y validado cada decisión antes de entregarlo. En este caso nos convertimos en editora/es críticos.
2. Puede funcionar también como referencia de comportamiento (demostrando cómo debe funcionar algo en términos de flujos, estados e interacciones) sin ser la especificación visual definitiva, dejando que desarrollo trabaje con el sistema de diseño existente para la implementación. Aquí seremos definidora/es de criterios y comportamiento.
3. O puede usarse principalmente como herramienta de alineación entre producto, diseño y desarrollo, donde el valor está en la conversación que genera, no en el artefacto en sí. Ahora seríamos facilitadora/es de la conversación.

Lo que es más difícil, independientemente de la opción que se elija, es identificar qué partes del prototipo están suficientemente definidas y cuáles no. Un prototipo generado por IA puede cubrir los cuatro planos de fidelidad de forma simultánea pero no con el mismo nivel de solidez en todos ellos. Puede haber flujos bien resueltos y decisiones de contenido que nadie ha cuestionado, interacciones coherentes y lógicas funcionales que no se han validado. El buen aspecto del conjunto tiende a ocultar esas lagunas, lo que hace especialmente difícil decidir qué merece volver atrás: a redefinir, a cuestionar, a prototipar de nuevo a menor fidelidad.

También hay que considerar que la expectativa general sobre estas herramientas es la aceleración de procesos, lo que pone en riesgo el propio rol del/a diseñador/a convirtiéndose en posible cuello de botella. Sobre esta última idea recordar que aunque no haya diseñadores/a en tu equipo, todo aquel que tome (por acción y omisión) una decisión de diseño está ejerciendo dicho rol, está por tanto diseñando interfaces.

Cómo mantener el criterio cuando la máquina ejecuta

Usar herramientas de IA para prototipar no significa renunciar a la autoría del diseño, significa que la autoría se ejerce de otra manera: no en la ejecución, sino en la definición y en la revisión.

Definir, en este caso, implica verbalizar decisiones de diseño que antes se comunicaban de forma puramente visual. Saber dibujar una pantalla y saber describirla con precisión suficiente para que una IA la genere correctamente son dos habilidades distintas. La segunda exige un nivel de abstracción y de lenguaje específico que no se da por supuesto: requiere construir un vocabulario común con la herramienta, aprender qué tipo de instrucciones producen resultados útiles y cuáles generan resultados que habrá que corregir casi por completo. El trabajo de definición de ese lenguaje no es menor, y forma parte del coste real de usar estas herramientas de forma efectiva.

Antes de generar el prototipo conviene tener resueltas al menos tres cosas:

1. Saber qué pregunta concreta intenta responder: si no puedes formularla, el prototipo no está listo para hacerse independientemente de la herramienta que uses.
2. Definir con precisión el flujo que quieres cubrir: no le pidas a la IA que "diseñe una app de recetas", dile exactamente qué pantallas necesitas, qué acciones deben ser posibles y qué información debe aparecer en cada momento. Cuanto más concreta sea la instrucción, más útil será el resultado generado y más fácil será revisarlo.
3. Tener escritos los criterios con los que vas a evaluar el resultado antes de generarlo: qué debe cumplir el prototipo para ser válido, qué decisiones de diseño son negociables y cuáles no. Tenerlo por escrito te protege de que la apariencia del resultado influya en tu juicio sobre su calidad.

Una vez tienes el prototipo generado, la revisión debe ser activa y estructurada. No se trata de mirar si "queda bien", sino de preguntarte sistemáticamente si cada decisión visible es una decisión que tú habrías tomado, por qué la herramienta ha elegido esa disposición, ese orden, ese comportamiento, y si la hipótesis implícita detrás coincide con la tuya. Las decisiones que no coincidan con tu criterio deben corregirse, no aceptarse sin más. Y las que sí coincidan deben ser conscientes, no accidentales.

En la práctica, esto también implica entender que no hay una única herramienta ni un único momento para usarla.

En resumen, el valor de estas herramientas no se traduce automáticamente en más espacio para pensar, eso es un cliché del que debemos huir. Las organizaciones tienden a interpretar la velocidad de ejecución como capacidad de entregar más, no como una oportunidad para hacer mejor las cosas.

Si no se defiende activamente el tiempo necesario para definir, cuestionar y revisar, la ganancia en velocidad se convierte simplemente en más volumen de trabajo. A nosotras nos interesa liberarnos de tareas repetitivas y tener la oportunidad de comunicar mejor el diseño y validar cuantas más hipótesis mejor.

Ser consciente de eso es también parte del criterio: saber cuándo el proceso necesita una pausa, qué fases pueden comprimirse sin coste y cómo justificar ese tiempo dentro de una organización que mide el éxito en entregas sin perder la calidad que otorga un buen diseño.