Diseño conversacional para asistentes que conversan y actúan

Diseñar un sistema conversacional no consiste en redactar lo que dirá el asistente. Consiste en decidir qué tareas merecen una conversación, qué puede hacer el sistema, cómo se reparten los turnos, qué necesita la persona para avanzar, cómo se recupera la interacción cuando falla y qué ocurre cuando la conversación no basta.

Quien viene de la lingüística llega con buena parte del trabajo hecho. El análisis de la conversación lleva medio siglo describiendo cómo las personas se turnan, se corrigen, abren y cierran un intercambio. La pragmática explica por qué una respuesta verdadera puede ser inútil. La sociolingüística sabe que el registro adecuado depende de la situación. Este taller traduce esos conocimientos a decisiones de diseño.

1. Qué es el diseño conversacional

Google lo define como el diseño del flujo y la lógica completos de una interacción, que puede incluir voz, pantalla y otros componentes, no solo las frases que se pronuncian. La definición importa porque desplaza el foco: el texto que dice el asistente es la parte visible de algo más amplio.

Una conversación con un sistema es a la vez tres cosas:

• una interfaz de lenguaje: la persona expresa lo que quiere con sus palabras y el sistema responde con las suyas
• un modelo de interacción: hay turnos, esperas, confirmaciones y estados que alguien tiene que haber previsto
• un servicio: detrás hay datos, herramientas, equipos humanos y políticas que hacen posible (o imposible) lo que el diálogo promete

En los asistentes actuales, construidos sobre modelos de lenguaje, parte de la experiencia ocurre fuera del diálogo visible: el sistema busca, consulta, prepara una acción, la ejecuta, espera una respuesta o la verifica. Por eso hay que diseñar el recorrido completo y sus estados, no solo los mensajes.

2. Qué cambia cuando el sistema actúa

Durante años, los asistentes se construyeron como árboles de decisión: el equipo escribía cada respuesta y el sistema elegía la rama según la intención detectada (el artículo sobre cómo los chatbots clasifican intenciones lo explica con ejemplos). Con los modelos de lenguaje cambian tres cosas que afectan directamente al diseño.

Las respuestas ya no están escritas de antemano. Un modelo genera salidas plausibles a partir del contexto; no recita un guion. El diseñador ya no controla cada frase: define criterios, ejemplos, límites y comprobaciones. Lo que antes era «escribir el guion» se parece más a escribir una buena guía de estilo y una buena política, y buena parte de ese trabajo se hace en las instrucciones del modelo: el taller sobre cómo escribir buenos prompts lo trata a fondo.

El sistema puede hacer cosas, no solo decirlas. Un asistente con acceso a herramientas puede reservar, enviar, borrar o pagar. Eso es lo que se suele llamar un sistema agéntico: uno que decide pasos y los ejecuta con cierta autonomía. La sección sobre agentes explica cómo funcionan por dentro. Anthropic recomienda no empezar por ahí. Primero conviene ver si basta con un flujo predefinido, y dar autonomía al sistema solo cuando la tarea lo requiere de verdad.

Decir no es hacer. Un modelo puede afirmar «he cambiado tu reserva» sin que el cambio haya ocurrido. La distancia entre lo que el sistema dice y lo que realmente pasó en el servicio es el problema central de este taller, y aparecerá en casi todas las páginas.

3. Empezar por la tarea, no por el asistente

Antes de preguntar qué debería decir el asistente, pregunta qué intenta conseguir la persona y qué obstáculo le resolvería una conversación.

Conversar tiene ventajas claras cuando la persona sabe lo que quiere pero no dónde está, cuando necesita combinar varias condiciones («un tren a Sevilla el viernes por la tarde, pero sin transbordo») o cuando tiene que explicar una excepción que ningún formulario prevé. Es una mala elección cuando la tarea es repetitiva, exige comparar muchos elementos a la vez, requiere precisión visual o se completa antes pulsando un botón.

La conversación tampoco es automáticamente más sencilla. El lenguaje natural ahorra aprender menús, pero esconde lo que la pantalla muestra: qué opciones existen, qué límites hay, en qué punto está la tarea. Una interfaz gráfica enseña las posibilidades; una conversación guía mejor una tarea compleja. En muchos productos la mejor solución es híbrida: conversar para explorar o pedir, y usar componentes visuales para elegir, revisar y confirmar.

Estas preguntas ayudan a decidir:

• ¿la persona sabe qué quiere, pero no cómo expresarlo en la interfaz actual?
• ¿la tarea gana con una aclaración gradual o con recomendaciones adaptadas al contexto?
• ¿la persona necesita explicar excepciones que un formulario no recoge?
• ¿el intercambio de turnos ahorra esfuerzo o solo añade pasos a algo sencillo?
• ¿hace falta comparar, editar o revisar varios datos a la vez?
• ¿un error de interpretación puede causar un daño, un coste o un compromiso difícil de deshacer?
• ¿existe otra vía eficaz para quien no quiera o no pueda conversar?

Si la conversación no aporta una ventaja clara, no la añadas por novedad. Y si la tarea mezcla diálogo con selección o revisión, diseña desde el principio una experiencia que combine ambas cosas, no una capa de chat pegada encima del producto.

4. Lo que la lingüística aporta

Cada página del taller se apoya en un concepto que la lingüística conoce bien:

No son analogías decorativas. Las conversaciones con sistemas fallan casi siempre en los mismos puntos en los que fallan las conversaciones entre personas: un turno que no se cede, una pregunta irrelevante, una reparación que no llega, un cierre en falso. La diferencia es que una persona repara esos fallos sin pensarlo y un sistema solo los repara si alguien lo ha diseñado.