UX Designer / UX Researcher: qué cambia la IA en el oficio

Dos temas que conviene no confundir

Hoy conviven dos conversaciones distintas sobre IA y diseño. La primera trata de las herramientas: generar variantes, producir maquetas más rápido, resumir verbatims de investigación. La segunda, mucho menos tratada, trata del objeto diseñado: qué le ocurre a una interfaz cuando el sistema que hay detrás produce un resultado variable, a veces falso y casi siempre verosímil. Es esa segunda pregunta la que redefine de verdad el oficio de diseñador y de investigador.

Diseñar con la incertidumbre como material

En una interfaz clásica la incertidumbre es una excepción: una carga, un error de red, un campo inválido. En una interfaz apoyada en un sistema de IA es permanente. El sistema no siempre sabe que se equivoca y el usuario no siempre puede comprobarlo. Diseñar consiste entonces en hacer manejable esa incertidumbre en lugar de ocultarla.

• Mostrar en qué se apoya la respuesta cuando existe una fuente que puede abrirse.
• Diferenciar visualmente lo que ha producido el sistema de lo que ha escrito la persona.
• Tratar la ausencia de respuesta como un estado diseñado, no como un vacío.
• Hacer que modificar sea tan accesible como aceptar.
• Evitar formulaciones de autoridad cuando el sistema no puede garantizar la respuesta.

Una regla útil: la interfaz nunca debe mostrar más certeza de la que el sistema tiene realmente. Es tanto una cuestión de credibilidad de producto como de ética.

Explicar lo que el sistema sabe y no sabe hacer

La mayoría de los fracasos de adopción vienen de un desajuste de expectativas: el usuario cree hablar con un sistema que lo entiende todo, choca con un límite arbitrario y abandona. El papel del diseño es fijar el alcance en el momento del uso, no en una página de ayuda.

• Una primera pantalla que muestre tres usos reales en lugar de un campo vacío.
• Ejemplos clicables que enseñen el alcance sin textos explicativos largos.
• Un mensaje claro y sin culpabilizar cuando la petición queda fuera de alcance.
• Una indicación de frescura cuando la respuesta depende de datos con fecha.

El campo libre es la promesa más amplia que puede hacer una interfaz. Si el sistema solo cumple una parte, es mejor acotar la entrada que decepcionar en la salida.

Buscar confianza calibrada, no confianza máxima

El objetivo no es que el usuario confíe lo máximo posible, sino que confíe en el nivel adecuado. Un exceso de confianza produce errores aceptados sin revisar. Una confianza insuficiente produce abandono, o una doble verificación que anula el beneficio. La calibración se construye con señales constantes y honestas.

• Coherencia: el sistema se comporta igual en situaciones parecidas.
• Verificabilidad: confirmar una respuesta cuesta un gesto, no cinco.
• Reconocimiento del límite: el sistema dice qué no encontró en lugar de rellenar el hueco.
• Reparabilidad: un error se corrige sin perder el trabajo hecho.

Errores, respuestas imperfectas y estados de repliegue

Diseñar un producto de IA es, sobre todo, diseñar sus estados degradados. La mayoría de las maquetas que se presentan en revisión muestran el caso ideal; la experiencia real ocurre en otra parte. Cuatro familias de estados merecen dibujarse explícitamente, con el mismo cuidado que el estado nominal.

• Respuesta parcial: el sistema encontró parte de la información y lo dice.
• Respuesta incierta: la respuesta existe pero conviene comprobarla, y se ofrece el camino para hacerlo.
• Sin respuesta: el sistema se abstiene y propone una alternativa útil (búsqueda, contacto, plantilla vacía).
• Respuesta falsa detectada por el usuario: aviso inmediato, corrección posible, traza conservada.

El último estado es el más olvidado y el más decisivo. Quien detecta un error y no puede hacer nada con él pierde la confianza de forma duradera; quien lo corrige en un gesto se convierte en contribuyente de la calidad del sistema.

Mantener al usuario en control

Recuperar el control no es un recurso de emergencia, es una parte central de la experiencia. Se diseña en tres planos: antes de la acción (elegir el alcance, ajustar la petición), durante (interrumpir, reformular, acotar) y después (modificar, deshacer, volver al estado anterior).

• Toda acción irreversible pasa por una validación explícita, nunca por un encadenamiento automático.
• Toda salida generada es editable en la propia superficie donde aparece.
• El historial permite entender qué se produjo, cuándo y a partir de qué.
• El usuario puede desactivar la asistencia sin perder la funcionalidad de base.

Human-in-the-loop: diseñar el gesto de supervisión

Cuando una organización decide que una persona valide las salidas del sistema, esa validación se convierte en un recorrido de usuario real, con su carga cognitiva y su propio riesgo. Un dispositivo mal diseñado produce una validación de fachada: se pulsa «aceptar» sin leer y el control solo existe sobre el papel.

• Hacer visible lo que debe comprobarse primero, en vez de toda la salida.
• Diferenciar los elementos críticos (importes, fechas, compromisos) del resto del texto.
• Limitar el volumen a validar por sesión: más allá, la atención cae.
• Hacer que rechazar sea tan sencillo como aceptar, y registrar el motivo cuando sea útil.

Un control que puede ejecutarse en un segundo sin leer no es un control: es una firma. El diseño decide cuál de los dos existe realmente.

El feedback del usuario como bucle de producto

El pulgar arriba o abajo es el grado cero del feedback: indica insatisfacción sin decir de qué tipo. Un dispositivo útil capta la naturaleza del problema con esfuerzo mínimo y se conecta con el trabajo de evaluación de producto e ingeniería.

• Ofrecer dos o tres motivos concretos en vez de un campo libre: falta información, información incorrecta, tono inadecuado, fuera de tema.
• Captar la corrección real cuando el usuario reescribe la salida: es la señal más rica.
• Cerrar el bucle: indicar que el aviso se ha tenido en cuenta cuando es cierto.
• No pedir feedback en cada interacción; el muestreo basta.

Transparencia útil sin recargar la interfaz

Explicarlo todo equivale a no explicar nada: un aviso permanente se vuelve invisible en una semana. La transparencia pertinente es contextual y progresiva: una marca breve junto a la respuesta, acceso a la fuente en un clic y detalle completo solo para quien lo pide.

Conversacional: una elección, no un reflejo

El chat se ha convertido en la forma por defecto de las funcionalidades de IA, a menudo sin motivo. La conversación encaja cuando la petición es imprevisible, exploratoria o iterativa. Encaja mucho menos cuando la tarea es repetitiva y conocida: ahí, un formulario, un botón contextual o una sugerencia en línea resultan más rápidos y más fiables.

• Tarea conocida y acotada: acción contextual o campo estructurado.
• Tarea exploratoria con formulación libre: conversación.
• Tarea repetitiva de alto volumen: automatización con revisión por excepción.
• Tarea crítica: recorrido guiado con verificación explícita.

Copiloto o automatización completa

Elegir entre asistir y automatizar es una decisión de diseño, no un nivel de madurez. Un copiloto deja la decisión al usuario y gana en aceptabilidad lo que pierde en ahorro de tiempo. La automatización completa maximiza el beneficio pero supone que el error sea raro, detectable y reversible. En medio, la automatización con revisión por excepción trata sola los casos seguros y envía a una persona los inciertos.

El papel del diseñador es hacer visible esa elección al equipo, con sus consecuencias: quién responde de la salida, qué ve el usuario del trabajo realizado y qué ocurre cuando el sistema se equivoca sin que nadie lo note.

Investigar un recorrido no determinista

La investigación clásica se apoya en un recorrido estable: varias personas realizan la misma tarea en la misma interfaz. En un producto de IA, dos participantes que formulan la misma pregunta pueden recibir respuestas distintas. El protocolo debe adaptarse sin perder rigor.

• Probar una tarea y un objetivo, no una pantalla fija: lo que cuenta es si la persona llega.
• Preparar de antemano varias salidas posibles —buena, parcial, falsa— y observar la reacción a cada una.
• Introducir deliberadamente un caso de error: es la única forma de saber si el usuario lo detecta.
• Distinguir la incomprensión del sistema de la incomprensión de la interfaz.
• Documentar el contexto exacto de cada sesión: versión, datos disponibles, respuesta obtenida.

Dos medidas merecen atención especial: la detección de errores —¿detecta el usuario una respuesta falsa?— y el exceso de confianza —¿acepta una respuesta verosímil sin comprobar?—. Dicen más sobre la viabilidad de una funcionalidad que una nota de satisfacción.

Caso concreto: una recomendación que se equivoca

Una herramienta interna de gestión de contratos propone una cláusula tipo a partir del contexto del expediente. En la versión inicial, la cláusula se inserta directamente en el documento sin indicar su origen. En una prueba, un participante valida una cláusula inadecuada para su caso: estaba bien redactada, parecía coherente y nada invitaba a comprobarla. El problema no es la calidad del modelo, es la ausencia de diseño alrededor del error.

Lo que prevé la versión revisada:

• La propuesta aparece en un estado distinto del texto validado mientras no se acepta.
• Indica la plantilla de referencia utilizada y la fecha de su última actualización.
• Los elementos variables (duración, importe, jurisdicción) se destacan como puntos a verificar.
• Cuando el contexto es incompleto, el sistema propone una cláusula vacía en lugar de una verosímil.
• Un rechazo en un clic, con motivo opcional, alimenta la revisión de calidad semanal.
• El historial conserva quién aceptó qué y a partir de qué propuesta.

Ninguna de estas decisiones depende del modelo. Todas dependen del diseño de la experiencia, y son las que deciden si la funcionalidad es utilizable en un contexto crítico.

Trabajar con producto e ingeniería de IA

En este tipo de producto, la frontera habitual entre diseño, producto y técnica se desplaza. El comportamiento del sistema es en parte una decisión de diseño: qué pasa ante la duda, qué se muestra, qué se rechaza. A la inversa, una restricción técnica —latencia, coste, frescura de los datos— se convierte en una restricción de experiencia.

• Participar en la definición de los casos de prueba: los casos límite de producto suelen ser casos límite de interfaz.
• Pedir ver salidas reales, incluidas las fallidas, antes de dibujar pantallas.
• Expresar las necesidades de interfaz como comportamiento esperado, no como componentes.
• Anticipar el coste de experiencia de la latencia: lo que tarda varios segundos se diseña de otro modo.

Un diseñador que ha visto cien salidas reales de un sistema diseña una interfaz radicalmente distinta a la de quien ha visto tres ejemplos de demostración. Probablemente sea el cambio de método más útil de toda esta lista.

• Experiencia IA
• Human-in-the-loop
• Copilotos