Blog de Metlivi

¿Cómo deberían reconocer los productos de chat de compañía cuándo un usuario quiere parar?

Un producto de chat de compañía debe tratar un mensaje claro de detención como una instrucción, reconocer cuándo se ha completado la actividad solicitada y permitir que el usuario haga una pausa sin tener que explicar por qué. Cuando el intercambio finaliza, debe cerrar brevemente y dejar el siguiente paso en manos del usuario. Una forma práctica de diseñar esto es ordenar las señales según su nivel de claridad, dar prioridad a las solicitudes explícitas y evitar hacer suposiciones a partir del estado de ánimo o del silencio del usuario.

30 de septiembre de 20266 min readLectura, arte y culturaPor Metlivi Editorial Team
Sección 1

Empiece por las palabras del usuario, no por una teoría sobre su estado de ánimo

Mensajes como «basta», «ya terminé», «es suficiente», «adiós» o «dejémoslo aquí» son pruebas directas de que el usuario quiere finalizar el intercambio. Incorpore estas frases, junto con sus variaciones naturales, en el control de detención del producto. Trátelas como instrucciones de control a lo largo de toda la conversación, incluso durante una actividad creativa o mientras el sistema formula una pregunta.

Esto sigue las pautas establecidas para el diseño de conversaciones. Google recomienda respetar expresiones como «ya terminé» y «olvídalo», e indica no dudar de alguien que quiere abandonar una tarea inconclusa cuando se perdería poco progreso. Amazon Lex define de forma similar una intención de detención para las frases que indican que el usuario desea finalizar una interacción. (Directrices de Google sobre el cierre de conversaciones; intención integrada de detención de Amazon Lex)

La respuesta del producto debe reconocer la instrucción una sola vez y luego finalizar el turno. Por ejemplo: «Entendido. Lo dejamos aquí». No acompañe ese reconocimiento con otra pregunta, una invitación a seguir hablando o una solicitud para justificar la decisión. Una orden de detención no debe convertirse en una pequeña negociación en la que el usuario tenga que repetirse.

Sección 2

Trate la finalización como un punto de cierre natural

Un usuario puede terminar sin decir «basta». Puede pedir un cuento corto y recibirlo, elegir una idea para una actividad de fin de semana o terminar de revisar un mensaje. Una vez entregado el resultado solicitado y cuando no queden partes pendientes en la tarea, el sistema puede cerrar con una breve declaración como «Aquí tienes la versión final» o «Eso te deja un plan para el sábado». No es necesario añadir automáticamente «¿Qué más te gustaría hacer?».

Esta es una deducción de diseño a partir de las pautas que sugieren mantener las respuestas conversacionales breves, relevantes y centradas en la tarea. La lista de comprobación de diseño de conversaciones de Amazon recomienda pasos mínimos y mensajes relevantes, y aconseja no interrumpir una experiencia con una oferta no relacionada. Aplicado al chat de compañía, esto sugiere supeditar las preguntas de seguimiento a un siguiente paso real, en lugar de adjuntar una a cada respuesta completada. (Principios de diseño de conversaciones de Amazon Alexa)

Existen excepciones. Si la solicitud consta de varias partes, el producto debe completar las partes prometidas o indicar claramente qué queda pendiente. Si un usuario pide un borrador y una revisión, devolver solo el borrador no constituye una tarea completada. Pero una vez satisfecho el alcance acordado, una pregunta abierta puede hacer que una interacción finalizada se sienta incompleta. Un cierre conciso evita que el sistema amplíe sutilmente la tarea del usuario.

Sección 3

Haga que pausar sea fácil de expresar y fácil de reanudar

Pausar es diferente de finalizar. «Hagamos una pausa», «volveré a esto luego», «un momento» o «guarda esto para después» pueden indicar que el usuario desea un descanso conservando el trabajo realizado. Si el producto admite el historial de conversaciones o los borradores guardados, puede confirmar en un lenguaje sencillo qué quedará disponible. Si no puede conservar el estado actual, debe advertirlo antes de que el usuario se marche, siempre que esa limitación sea relevante.

Mantenga la pausa bajo el control del usuario. No exija explicaciones ni sugiera una razón para la interrupción. Si el producto cuenta con un control visible de pausa o cierre, etiquételo con claridad y asígnele un resultado predecible. La guía del W3C sobre el control del usuario señala que los cambios de contexto deben ser iniciados por el usuario o contar con un mecanismo para desactivarlos; este principio respalda el uso de controles claros y comportamientos predecibles en torno a las transiciones. (Guía del W3C sobre Cambio a petición)

El producto también debe distinguir una pausa de una detención explícita mediante las palabras y acciones disponibles en la interfaz. Una pausa puede preservar un borrador o la posición dentro de una tarea si la función lo permite. Una detención debe finalizar la interacción actual. No afirme que una conversación está guardada a menos que realmente lo esté, y no interprete que salir de la aplicación o quedarse en silencio sea una solicitud para enviar más mensajes.

Sección 4

Utilice un orden claro para las señales ambiguas y explícitas

Una jerarquía de señales útil para la implementación es:

Detención o despedida explícita: finalice el intercambio de inmediato.

Solicitud explícita de pausa o guardado: pause o guarde si el sistema lo permite y, a continuación, confirme el resultado brevemente.

Solicitud completada: proporcione el resultado solicitado y cierre sin exigir otro turno.

Mensaje poco claro: haga una única pregunta aclaratoria breve solo cuando la ambigüedad bloquee la tarea.

Silencio: espere o finalice la sesión activa según el comportamiento habitual del producto; no deduzca un estado emocional.

Este orden es una propuesta práctica de diseño, no una métrica publicada ni un clasificador universal. Su objetivo es evitar que las instrucciones directas queden anuladas por suposiciones más sutiles. Por ejemplo, «Es suficiente» debe tener prioridad sobre la predicción del sistema de que una sugerencia relacionada podría ser bienvenida. Una pregunta como «¿Te refieres a parar aquí o a guardar esto para después?» solo es adecuada cuando la redacción del usuario deja realmente abiertas esas posibilidades.

Si un producto ejecuta una acción de gran impacto o corre el riesgo de perder una cantidad significativa de trabajo, una confirmación puede ser apropiada para proteger dicho trabajo. Mantenga la confirmación específica y fácil de responder: «¿Deseas parar ahora y descartar este borrador?». En una conversación ordinaria donde apenas se perdería progreso, una confirmación reiterada genera una fricción innecesaria. Las directrices de Google hacen la misma distinción: no vuelva a verificar una salida a menos que se vaya a perder un progreso significativo. (Directrices de Google sobre el cierre de conversaciones)

Sección 5

Mantenga la respuesta de cierre breve y completa

Un mensaje de cierre debe cumplir una sola función: dejar claro que el sistema ha entendido al usuario y que la interacción ha terminado o se ha pausado. Entre los ejemplos adecuados se incluyen:

Detención: «De acuerdo. Lo dejamos aquí».

Tarea creativa completada: «Aquí tienes el poema revisado».

Pausa con trabajo guardado: «Pausado. Tu borrador está guardado en este chat».

Pausa sin función de guardado: «De acuerdo. Puedes volver a este chat más tarde, pero no puedo guardar un borrador independiente».

Utilice únicamente afirmaciones que se correspondan con el comportamiento real del producto. Evite apelaciones emocionales, frases que generen culpa o formular una nueva pregunta. Un cierre puede ser cordial sin pedirle al usuario que tranquilice al sistema ni que continúe la interacción. El objetivo de diseño es lograr un final claro en el que el usuario pueda confiar.

Sección 6

Pruebe los casos límite, no solo las órdenes obvias

Revise ejemplos breves de conversación en situaciones de uso habitual: una detención directa en medio de un relato, un «es suficiente» tras una recomendación, una tarea de redacción finalizada, una solicitud de pausa a mitad de camino y un ambiguo «tal vez más tarde». Compruebe que cada caso conduzca al comportamiento deseado y que no aparezca una pregunta de seguimiento tras una detención clara o una tarea completada.

Compruebe también los falsos positivos. «Deja de usar esa frase y prueba con otra» contiene la palabra «deja», pero es una instrucción dentro de la tarea, no necesariamente una solicitud para finalizar el chat. Interprete las palabras en contexto y mantenga disponible un control específico de detención por si el sistema malinterpreta el lenguaje. La documentación de Amazon describe una intención integrada de detención para frases comunes de parada; un producto de chat de compañía puede utilizar la misma idea básica adaptando el reconocimiento a su interfaz de texto o de voz. (Intención integrada de detención de Amazon Lex)

Haga un seguimiento de fallos prácticos, tales como una solicitud de parada seguida de otra pregunta, una tarea completada que activa una sugerencia irrelevante o una pausa que pierde el trabajo a pesar de haber dado a entender que se guardó. Estas son comprobaciones de comportamiento observables, no juicios sobre lo que siente el usuario. Ayudan a los equipos a mejorar la interacción sin intentar diagnosticar a los usuarios a partir de sus palabras.

Sección 7

Una regla sencilla para un cierre respetuoso

Cuando el usuario dé por finalizado el intercambio con claridad, deténgase. Cuando la tarea acordada esté completa, cierre brevemente. Cuando el usuario pida una pausa, preserve su control y explique el funcionamiento del guardado disponible. Formule una pregunta de seguimiento solo cuando sea necesario para concluir la solicitud o resolver una ambigüedad real. Esto proporciona a los productos de chat de compañía una forma concreta de reconocer los cierres, dejando las elecciones habituales, el ritmo y la continuidad en manos del usuario.

Lecturas relacionadas

Sigue explorando este tema