Peticiones de funciones que esconden problemas de UX

"Necesitaríamos poder duplicar un proyecto." El producto permite duplicar proyectos desde hace catorce meses. La petición es real, y lo que describe no es una función que falte.

La respuesta corta. Una parte de las peticiones de funciones, no todas, describe un problema con algo que ya existe: no se encuentra, no funciona como se espera, o exige tantos pasos que no compensa. Construir la función pedida en esos casos añade una segunda forma de hacer lo mismo y deja el problema original intacto.

La tesis, con su límite

Conviene decir el límite antes que la idea, porque la versión sin matizar de este argumento es falsa y bastante dañina.

Muchas peticiones de funciones son exactamente lo que parecen: cosas que el producto no hace y debería hacer. Un equipo que asume que toda petición esconde un problema de usabilidad acaba respondiendo con condescendencia a usuarios que tenían razón, y deja de construir lo que hacía falta.

La afirmación defendible es más estrecha: una proporción no despreciable de peticiones se resuelve sin construir la función pedida, y esa proporción es fácil de identificar si se pregunta antes de estimar.

Seis problemas que llegan disfrazados de petición

Lo que se pide	Lo que puede estar pasando	Cómo confirmarlo
Una función que ya existe	Problema de descubribilidad	Preguntar dónde la buscó
Un atajo para una tarea	El flujo tiene demasiados pasos	Cronometrar la tarea real
Una integración concreta	Falta una vía de entrada o salida de datos	Preguntar qué hará con los datos
Una opción de configuración	El valor por defecto es incorrecto	Ver qué proporción lo cambiaría
Un informe nuevo	No se fía de los datos actuales	Preguntar qué decisión quiere tomar
Un aviso o notificación	Algo falla en silencio	Buscar el fallo silencioso

Los dos últimos son los más interesantes y los que más se construyen a ciegas.

Una petición de informe nuevo suele venir de que el informe existente da un número que el usuario no entiende o no cree. Construir otro informe añade una segunda cifra que tampoco entenderá.

Una petición de notificación suele señalar que algo falla sin decirlo: una importación que se cae a la mitad, una integración que se desconecta. La petición correcta no es "avisadme cuando falle", es que deje de fallar.

La pregunta que separa los casos

Hay una sola pregunta que hace casi todo el trabajo, y hay que hacerla antes de estimar nada:

¿Qué estabas intentando hacer cuando echaste esto en falta?

Es concreta, es fácil de responder y produce una descripción del contexto en lugar de una defensa de la solución propuesta. La respuesta suele encajar en uno de tres patrones:

Describe una tarea que el producto ya soporta. Es descubribilidad.
Describe una tarea que el producto soporta con demasiados pasos. Es diseño de flujo.
Describe una tarea que el producto no soporta. Es una función que falta.

Solo el tercer caso justifica construir lo pedido. Los otros dos se resuelven con cambios más baratos y con mejor efecto sobre la retención, porque afectan también a quienes tuvieron el problema y no escribieron.

Ese último punto merece atención. Quien escribe es una minoría. Si una persona pide un atajo para una tarea de nueve pasos, hay muchas más que abandonaron la tarea sin decir nada.

Por qué esto afecta a la retención

Un problema de descubribilidad tiene una característica desagradable: es invisible en los datos de uso. La función aparece como poco usada, lo que se interpreta como falta de interés, cuando en realidad es falta de hallazgo. La conclusión errónea suele ser despriorizarla, lo que agrava el problema.

Mientras tanto, el usuario que no la encontró concluye que el producto no hace lo que necesita. Esa conclusión no genera un ticket, genera una baja silenciosa varios meses después.

Aquí es donde el lenguaje del mensaje aporta más que el recuento de votos. Una petición redactada con frustración evidente sobre algo que el producto ya hace es una señal doble: hay un problema de UX y hay una cuenta molesta. FlagUp analiza el lenguaje de cada envío y destaca las cuentas donde se acumulan señales negativas, lo que ayuda a mirar primero esas. La página de detección de churn explica esa señal.

Qué hacer con cada caso

Descubribilidad. Cambiar dónde vive la función, cómo se llama, o cuándo aparece. Responder al usuario con instrucciones no es la solución: es el parche para esa persona y deja intacto el problema para las demás.

Flujo demasiado largo. Contar los pasos reales, no los que el equipo cree. Suele haber uno o dos que existen por razones históricas.

Valor por defecto incorrecto. El cambio más barato de todos y el que más se pospone, porque parece menor.

Fallo silencioso. Tratarlo como un error, con la urgencia de un error.

Función que falta de verdad. Al tablero, con el resto. Aquí sí aplica la lectura por votos y segmento.

En los cinco casos, contar al usuario qué se hizo importa. Alguien que pidió una función y recibe "ya existe, y hemos cambiado dónde está para que se encuentre" obtiene una respuesta mejor de la que pidió.

Preguntas frecuentes

¿No es esto una excusa para no construir lo que piden?

Puede convertirse en eso si se aplica por defecto. La protección es la pregunta de contexto: se hace antes de decidir, y con frecuencia confirma que la función hace falta.

¿Cómo evito parecer condescendiente al responder?

Reconociendo el problema antes que la solución. "Tenías razón en que esto costaba demasiado, y esto es lo que hemos cambiado" funciona mejor que "en realidad ya se podía".

¿Cuándo hago la pregunta de contexto?

En el triage, no en la reunión de priorización. Preguntar tarde significa que la petición ya lleva semanas mal clasificada.

¿Y si el usuario no responde?

Bastante habitual. En ese caso se decide con lo que hay, anotando que el contexto falta. Una petición sin contexto es más débil que una con contexto, y eso también es información.

Cuando las solicitudes de funciones revelan problemas de UX