UX de IA sin trucos: diseñar asistentes en los que los usuarios realmente confían | Blanche

La mayoría de las funciones de IA no fallan porque el modelo sea “malo”. Fallan porque la UX es ambigua.

Los usuarios no saben qué hará el asistente, qué se le permite hacer, en qué basa su respuesta o cómo recuperarse cuando se equivoca. Así que o no lo usan, o confían demasiado en él hasta que algo se rompe.

Este artículo es una biblioteca práctica de patrones para diseñadores de producto y founders que están llevando IA a flujos de trabajo reales: cómo estructurar interacciones, cómo hacer legible la confianza y cómo diseñar para el fallo sin matar el impulso.

Por qué la mayoría de las funciones de IA se sienten pegadas con cinta

Mucho de la “UX de IA” es solo un chatbot pegado en la esquina de una app. Eso rara vez es el primitivo correcto.

Esa sensación de “pegado” viene de tres desajustes:

Desajuste de intención: los usuarios llegaron para completar una tarea, pero la IA les pide que chateen.
Desajuste de control: la IA puede hacer demasiado (arriesgado) o demasiado poco (inútil).
Desajuste de responsabilidad: cuando algo sale mal, no hay rastro de qué pasó o por qué.

La solución no es una ventana de chat más bonita. Es diseñar la IA como un conjunto de patrones de interacción que encajen con el modelo mental de tu producto.

El objetivo no es “IA en todas partes”. El objetivo es menos esfuerzo con resultados predecibles.

Aprendizaje concreto

Antes de diseñar la UI, escribe una frase:

“Los usuarios confiarán en esta función de IA cuando puedan predecir qué hará, verificar por qué lo hizo y deshacer qué cambió.”

Si no puedes respaldar esas tres cosas, estás lanzando una demo, no un producto.

Una biblioteca de patrones para interacciones con IA

Piensa en la IA como un espectro desde la sugerencia hasta la acción autónoma. La mayoría de los productos deberían empezar a la izquierda y ganarse el derecho de moverse a la derecha.

Patrón 1: Sugerencias vs. acciones

Las sugerencias son salidas de IA que requieren confirmación explícita del usuario para aplicarse. Las acciones son cambios iniciados por la IA en el sistema.

Usa sugerencias cuando:
- el coste de equivocarse es moderado/alto (legal, financiero, reputacional)
- las preferencias del usuario son matizadas
- el dominio tiene múltiples respuestas “correctas”
Usa acciones cuando:
- el resultado es reversible
- el usuario ya expresó una intención clara
- puedes previsualizar cambios y ofrecer una pista de auditoría

Mecánicas de UI que hacen que las sugerencias se sientan utilizables:

Sugerencias en línea (no chat modal): correcciones gramaticales, ediciones de código, autocompletado de campos en CRM
Aplicar con un clic + deshacer con un clic
Vista comparativa (antes/después)

Referencia del mundo real: GitHub Copilot funciona porque es principalmente un motor de sugerencias dentro del editor. El usuario se mantiene en flujo y la aceptación es explícita.

Patrón 2: Borradores vs. piloto automático

Una trampa común es saltar directo al piloto automático: “Genera todo”. Los borradores suelen ser un mejor producto.

Modo borrador: la IA produce un artefacto editable (email, PRD, esquema, consulta SQL, copy de diseño).
Modo piloto automático: la IA ejecuta un flujo de trabajo de varios pasos (cambios de archivos, envío de mensajes, despliegue de código, actualización de registros).

El modo borrador gana al principio porque:

hace visible la calidad
reduce el miedo (“puedo editar esto”)
crea un paso natural de revisión

Patrones de UX de borradores que funcionan:

Borradores estructurados (secciones, encabezados, marcadores) en lugar de muros de texto
Chips de “pedir revisión”: más corto, más formal, añade ejemplos, ajusta a la voz de marca
Restricciones visibles desde el inicio: tono, longitud, audiencia, política de fuentes

El piloto automático debería estar restringido por:

permisos (acceso acotado)
previsualizaciones (diffs)
puntos de control (confirmar antes de pasos irreversibles)

Si el usuario no puede revisar el trabajo con facilidad, no construiste piloto automático: construiste una responsabilidad.

Patrón 3: Humano en el bucle por diseño

“Humano en el bucle” no es una casilla de cumplimiento. Es una estrategia de producto: decide dónde los humanos aportan más valor.

Tres ubicaciones comunes del bucle:

Antes (moldeado de entrada): el usuario aporta restricciones, ejemplos o fuentes preferidas.
Durante (dirección interactiva): el usuario aprueba pasos, elige opciones, corrige supuestos.
Después (revisión y confirmación): el usuario valida y aplica cambios.

Ejemplo: en una función de notas de reunión con IA, el bucle podría ser:

Antes: seleccionar asistentes + tipo de reunión (llamada de ventas, daily, entrevista)
Durante: resaltar momentos clave (“esto es una decisión”)
Después: revisar tareas con responsables y fechas límite antes de sincronizar con Asana/Jira

Patrón 4: Interfaces de “cintura estrecha” (el movimiento potente infravalorado)

En lugar de dejar que los usuarios escriban cualquier cosa, dales un conjunto pequeño de entradas de alto apalancamiento:

objetivos en desplegable (resumir, reescribir, extraer tareas)
deslizadores (tono, longitud)
casillas (incluir citas, usar la base de conocimiento de la empresa)

Esto reduce la fragilidad del prompt y hace que los resultados sean más consistentes.

Referencia de herramientas: Notion AI y Grammarly se apoyan en intenciones acotadas, incluso cuando el chat está disponible.

UX de confianza y seguridad (transparencia por diseño)

La confianza no es un sentimiento. En productos de IA, la confianza es el resultado de evidencia + control.

Constructor de confianza 1: Fuentes y citas (con affordances)

Si la IA hace afirmaciones fácticas, muestra de dónde vienen.

Opciones de diseño:

Citas en línea con previsualizaciones al pasar el cursor
Panel de “Fuentes usadas” con enlaces y marcas de tiempo
Extractos resaltados que se mapean a la salida generada

Mejor práctica: distinguir entre:

fuentes recuperadas (docs, páginas web, tickets)
conocimiento del modelo (razonamiento general sin una fuente)

Los usuarios deberían poder ver la diferencia al instante.

Constructor de confianza 2: La incertidumbre como función, no como disculpa

La mayoría de los asistentes o suenan demasiado seguros o demasiado dubitativos. Ninguno construye confianza.

Haz que la incertidumbre sea accionable:

Indicadores de confianza ligados a qué hacer después
“No estoy seguro” acompañado de opciones:
- hacer una pregunta aclaratoria
- proponer supuestos para confirmar
- ofrecer una alternativa más segura (borrador, checklist, plantilla)

Buen patrón de redacción UX:

“Puedo hacer X, pero me falta Y. ¿Cuál de estas opciones es cierta?”

Constructor de confianza 3: Previsualizaciones de cambios (diffs) y acciones reversibles

Si la IA edita algo—copy, código, ajustes, registros—los usuarios necesitan una previsualización.

Patrones sólidos:

Antes/después lado a lado
Resaltado de diff en línea (como los PRs de GitHub)
“Aplicar cambios seleccionados” (casilla por cambio)
“Deshacer” que realmente restaura el estado (no solo “regenerar”)

Referencia del mundo real: la mentalidad de versionado de Figma es el estándar de oro para herramientas creativas; las ediciones de IA deberían heredar esa misma reversibilidad.

Constructor de confianza 4: Pistas de auditoría y controles de memoria

Cuando la IA toca flujos de trabajo de negocio, necesitas trazabilidad:

¿Qué prompt/entrada se usó?
¿A qué fuentes de datos se accedió?
¿Qué salida se produjo?
¿Qué acciones se aplicaron?
¿Quién lo aprobó?

Muéstralo en la capa correcta:

Usuarios: “Historial” y “¿Por qué estoy viendo esto?”
Admins: logs, exportación, políticas de retención

Y haz explícita la memoria:

qué recuerda el asistente
cómo editar/eliminar la memoria
cuándo se usa la memoria en las salidas

En B2B, “confianza” a menudo significa: ¿puedo explicar esta decisión a mi jefe, a mi cliente o a un auditor?

Modos de fallo y recuperación elegante

Los fallos de la IA son inevitables. La pregunta de UX es si el fallo se convierte en un callejón sin salida o en un desvío guiado.

Modo de fallo 1: Rechazos que dejan al usuario varado

Los rechazos a veces son necesarios (política, seguridad, permisos). Pero “no puedo ayudarte con eso” es una experiencia rota.

Diseña los rechazos con:

un motivo breve en lenguaje claro
lo que el asistente sí puede hacer en su lugar
un camino a seguir (plantilla, alternativa segura, escalado)

Ejemplo de patrón de rechazo:

“No puedo generar consejo médico. Puedo ayudarte a redactar preguntas para hacerle a un profesional, resumir las guías que me proporciones o dar formato a tus notas.”

Modo de fallo 2: Alucinaciones y afirmaciones sin fundamento

No puedes depender de que los usuarios detecten alucinaciones. Necesitas barreras a nivel de producto.

Patrones de UX + sistema que reducen el daño:

Exigir citas en modos fácticos (o etiquetar claramente “no se usaron fuentes”)
Respuestas con recuperación primero para consultas a la base de conocimiento
Affordances de “calidad de respuesta”: marcar, reportar, solicitar fuentes
Fomentar la verificación: “Abrir los extractos de la fuente”

Cuando el asistente no puede encontrar evidencia, hazlo explícito:

“No pude localizar esto en tus docs. ¿Quieres que busque en la web, le pregunte a un compañero o redacte un esquema de mejor esfuerzo marcado como supuestos?”

Modo de fallo 3: Finalización parcial silenciosa

Los flujos autónomos a menudo fallan a mitad de camino (permisos, errores de API, campos faltantes). La peor experiencia es cuando la IA finge que completó.

Diseña para claridad transaccional:

rastreador de pasos (“1/3 actualizado, 2/3 pendiente de aprobación”)
mensajes de error claros con próximos pasos
reintentar + alternativa (“exportar como CSV”, “crear un borrador”, “abrir en el editor”)

Modo de fallo 4: Sobrepersonalización y comportamiento inquietante

Si el asistente hace referencia a algo que el usuario no sabía que conocía, la confianza se derrumba.

Solución:

chips “Usando: [fuentes de datos]” visibles antes de generar
toggles: “Usar mis mensajes anteriores” / “Usar docs del espacio de trabajo”
explicaciones de “¿Por qué esta sugerencia?”

Aprendizaje concreto

Cada función de IA necesita un storyboard de estados de fallo:

¿Qué pasa cuando el modelo está inseguro?
¿Qué pasa cuando está bloqueado?
¿Qué pasa cuando se equivoca?
¿Qué pasa cuando no puede completar la acción?

Si no puedes responder a eso, estás lanzando magia frágil.

Evaluación: qué medir y cómo probar

Las métricas de vanidad (mensajes enviados, tokens consumidos) no te dirán si la función funciona.

Mide resultados que reflejen valor real y riesgo real.

Métrica 1: Tasa de finalización de tareas (con umbrales de calidad)

Define la tarea. Define “terminado”. Define “calidad aceptable”.

Ejemplos:

Agente de soporte: “Ticket resuelto sin escalado” + CSAT
Analista: “Consulta generada que ejecuta” + comprobaciones de corrección
Marketer: “Borrador aprobado con <=2 ediciones”

Añade una compuerta de calidad:

rúbrica de valoración humana (precisión, relevancia, tono)
comprobaciones automatizadas cuando sea posible (linting, validación de esquema, checks de política)

Métrica 2: Tiempo hasta el valor (TTFV)

La IA debería reducir el tiempo desde la intención hasta una salida útil.

Haz seguimiento de:

tiempo desde abrir la función hasta el primer artefacto utilizable
número de iteraciones hasta la aceptación
puntos de abandono (donde los usuarios se rinden)

Si el TTFV es peor que el flujo manual, tu UX está añadiendo fricción.

Métrica 3: Tasa de recuperación ante errores

Cuando algo sale mal, ¿los usuarios se recuperan?

Mide:

% de ejecuciones fallidas que llevan a un resultado exitoso en N minutos
categorías de fallo más comunes (contexto faltante, permisos, reportes de alucinación)
uso de “deshacer” y satisfacción (deshacer es una señal de confianza, no un fallo)

Cómo probar UX de IA (sin engañarte)

Combina tres modos de prueba:

Pruebas de usabilidad basadas en escenarios
- Dales a los usuarios tareas reales y contexto desordenado
- Observa: ¿saben qué hacer, qué pasó y en qué confiar?
Sondeo estilo red team (especialmente para dominios de riesgo)
- Prueba prompts adversariales, instrucciones ambiguas, casos límite
- Valida la UX de rechazo y alternativas seguras
Evaluaciones en producción con guardrails
- A/B test de patrones de interacción (borrador vs piloto automático, citas on/off)
- Usa despliegues por etapas y feature flags

Referencias de herramientas:

Analítica de producto: Amplitude, Mixpanel
Experimentación: LaunchDarkly
Observabilidad/logging: Datadog
Flujos de evaluación de LLM: LangSmith, Braintrust, OpenAI Evals-style harnesses

Si no puedes evaluarlo, no puedes mejorarlo—y definitivamente no puedes escalarlo.

Una checklist de lanzamiento para una UX de IA responsable

Úsala como una comprobación instintiva antes de lanzar.

Diseño de interacción

¿La UI principal es un patrón nativo del flujo de trabajo (en línea, editor, barra lateral), no solo chat?
¿Elegimos el nivel de autonomía correcto: sugerencia, borrador o piloto automático?
¿Hay restricciones e inputs claros (intenciones, toggles, ejemplos)?
¿Los usuarios pueden aprobar antes de que se apliquen los cambios?

Confianza y transparencia

¿Hay fuentes/citas disponibles cuando las afirmaciones son fácticas?
¿Mostramos qué datos está usando el asistente (y permitimos excluirse)?
¿Los usuarios obtienen previsualizaciones/diffs para ediciones y acciones?
¿Hay un deshacer real y/o historial de versiones?
¿Hay una pista de auditoría para admins y equipos?

Fallo y recuperación

¿Los rechazos son útiles con alternativas y próximos pasos?
¿Manejamos la incertidumbre con preguntas aclaratorias o salidas seguras?
¿Evitamos fallos silenciosos y confusión por finalización parcial?
¿Hay una ruta alternativa (flujo manual, exportación de borrador, escalado)?

Medición

¿Seguimos la finalización de tareas con umbrales de calidad?
¿Medimos tiempo hasta el valor y el recuento de iteraciones?
¿Medimos recuperación ante errores y señales de confianza del usuario (deshacer, aperturas de fuentes, clics de verificación)?
¿Tenemos un plan de evaluación continua y actualizaciones del modelo?

Conclusión: La confianza es el producto

La mejor UX de IA no se siente como IA. Se siente como si el producto de repente entendiera lo que el usuario intenta hacer—y ayudara de una forma predecible, revisable y reversible.

Si estás diseñando un asistente en el que los usuarios realmente confían, céntrate menos en la personalidad y más en los fundamentos:

sugerencias antes que acciones
borradores antes que piloto automático
transparencia antes que persuasión
rutas de fallo como UX de primera clase

¿Quieres una forma rápida de poner a prueba tu función de IA? Mapea tu flujo con tres preguntas:

¿Qué hará?
¿Por qué lo hizo?
¿Qué pasa si se equivoca?

Si tu UI responde a eso con claridad, no estás añadiendo un truco: estás construyendo una capacidad.