Patrones y lista de revisión

Esta última página reúne lo anterior en forma de patrones reutilizables, errores frecuentes y una lista de revisión antes de lanzar. Sirve como resumen del taller y como herramienta de trabajo.

1. Seis patrones de decisión

A. Información conocida y tarea sencilla. Responde con el dato, añade una condición solo si cambia el resultado, ofrece una continuación si es útil y cierra sin «¿algo más?».

B. Falta un dato que cambia el resultado. Explica brevemente para qué hace falta, pide ese dato y no otros, espera, acepta respuestas con más información y aprovéchala. Si no se interpreta, acota la pregunta.

C. Varias interpretaciones y una acción con consecuencias. Nombra las interpretaciones, pregunta cuál es, no ejecutes mientras dure la ambigüedad, muestra un resumen antes del efecto externo, pide confirmación explícita y comprueba el resultado.

D. Tarea larga con espera. Explica qué viene y por qué tarda, muestra el progreso si informa de algo, permite salir sin perder lo confirmado, avisa del resultado solo si la persona lo espera y el canal está autorizado, y al volver resume y pide la decisión pendiente.

E. Fuera de alcance. Di qué parte no puedes resolver, no respondas solo con una disculpa, ofrece la vía más cercana a la meta (no una lista de lo que sí sabes hacer) y, si se repite, regístralo como señal para el producto.

F. Fallo repetido. No repitas el mismo mensaje, reconoce que esta vía no funciona, cambia de modo (un ejemplo, opciones, teclado, formulario o una persona) y conserva el contexto para volver después.

2. Errores frecuentes

• construir un asistente generalista para validar una sola tarea: con un alcance tan amplio no se sabe qué hipótesis se está probando
• diseñar solo el camino ideal: el primer silencio, la primera corrección o el primer dato de más revelan si el diseño se sostiene
• terminar todas las respuestas con una pregunta: crea obligaciones de respuesta cuando la tarea ya ha terminado
• preguntar porque el flujo lo necesita, no porque lo necesite la persona: el orden interno se convierte en interrogatorio
• volver a pedir datos ya dados: obliga a la persona a adaptarse al sistema
• una única reparación para todo: no explica qué pasó ni cómo seguir
• reintentar hasta que la persona se rinda: un bucle no es una estrategia
• esconder los límites hasta el momento del fallo: crea expectativas que el sistema no puede cumplir
• tratar la derivación como una derrota: una buena transferencia puede ser el mejor resultado
• decir «hecho» cuando solo se ha iniciado algo: confunde el estado del diálogo con el del servicio
• compensar un mal servicio con personalidad: un tono amable no arregla una transacción fallida
• automatizar decisiones que deberían seguir en manos humanas: que se pueda no significa que convenga
• convertir reglas de estilo en leyes: «máximo cuatro opciones», «una pregunta por turno» o «usa emojis» se prueban en cada canal y tarea
• medir solo la satisfacción final: alguien puede declararse satisfecho sin haber completado bien la tarea

3. Lista de revisión antes de lanzar

Problema y alcance

• la tarea responde a una necesidad observada
• el resultado tiene una definición comprobable
• la conversación aporta algo frente a una interfaz directa
• el alcance está escrito como casos de uso, con disparador, requisitos, resultado y fallos
• se sabe qué queda fuera y quién lo atiende

Turnos y preguntas

• en cada turno se sabe quién actúa después
• cuando el sistema espera respuesta, termina con una pregunta inequívoca y deja de hablar
• no obliga a responder cuando la tarea ya está resuelta
• cada pregunta tiene un motivo y no repite datos ya disponibles
• se aceptan respuestas parciales, datos de más, correcciones y cambios de tema
• las confirmaciones dependen del coste y la reversibilidad de la acción

Reparación y continuidad

• hay reparaciones distintas para silencio, falta de interpretación, fuera de alcance, falta de datos y fallo técnico
• la reparación es específica de cada punto y cambia en cada intento
• cada bucle tiene un límite y una salida
• existen siempre una vía de cancelación y, cuando corresponde, una persona
• una interrupción no borra lo hecho ni duplica acciones
• el sistema distingue entre iniciado, ejecutado, comprobado y fallido
• el cierre resume lo hecho y deja claro el siguiente paso real

Calidad y accesibilidad

• se ha probado en todos los canales previstos
• hay alternativas para quien no puede o no quiere usar la voz
• tiempos, pausas, instrucciones y opciones son comprensibles
• se ha evaluado con personas diversas y en cada lengua
• hay una política clara sobre qué conversaciones se guardan, quién las ve y cuánto tiempo
• cada flujo, fuente y reparación tiene responsable

4. Preguntas para recorrer un flujo

Antes de aprobar un flujo, recórrelo como si fueras alguien que llega por primera vez, alguien que lo usa a diario, alguien con prisa, alguien que no recuerda un dato y alguien a quien el sistema no reconoce bien la voz. En cada caso, pregúntate:

• ¿cómo sé que he entrado en la tarea correcta?
• ¿puedo hacer una pregunta lateral sin perderme?
• ¿qué pasa si no respondo ahora?
• ¿puedo volver atrás, corregir o cambiar de idea?
• ¿qué me pide el sistema y por qué?
• ¿qué significa confirmar aquí?
• ¿cómo sé si la acción empezó, terminó o falló?
• ¿qué pasa si cierro la aplicación o cambio de canal?
• ¿puedo salir sin perderlo todo?
• ¿a quién llega mi información si me derivan?
• ¿qué puede salir mal que no dependa del modelo?