USER FEEDBACK · FEATURE ADOPTION · PRODUCT DISCOVERY
Publicado: 2026-10-02 · Lectura editorial
Construiste exactamente lo que pidieron tus usuarios. ¿Por qué no lo usan?
Que una persona pida una feature es evidencia de una necesidad o expectativa. No demuestra cómo se comportará cuando la feature exista.
Una feature fue solicitada. El equipo la construyó. Técnicamente funciona. Casi nadie la usa. La reacción habitual es buscar cómo aumentar la adopción.
Antes de preguntar cómo hacer que la usen, conviene volver a la premisa: ¿por qué esperábamos que la utilizaran? La solicitud era evidencia. No era una predicción completa del comportamiento futuro.
01 · ADOPTION CHAIN
La baja adopción es un síntoma, no un diagnóstico
01
→DISCOVER
La feature existe, pero nadie la encuentra.
Pregunta: ¿Aparece donde surge la necesidad y para el segmento correcto?
Evidencia: Exposición, momento de entrada y recorrido hasta la feature.
02
→UNDERSTAND
La encuentran, pero no comprenden para qué sirve.
Pregunta: ¿Pueden anticipar qué resultado obtendrán?
Evidencia: Explicación, expectativas y errores de interpretación.
03
→TRY
La entienden, pero probarla exige demasiado esfuerzo o riesgo.
Pregunta: ¿Pueden obtener una primera señal sin preparar todo el contexto?
Evidencia: Tiempo, permisos, datos requeridos y abandono inicial.
04
→VALUE
La usan, pero no obtienen el resultado esperado.
Pregunta: ¿La acción resuelve la necesidad que originó la petición?
Evidencia: Resultado conseguido y diferencia respecto al workflow anterior.
05
REPEAT
Obtienen valor una vez, pero no vuelven.
Pregunta: ¿La necesidad reaparece o existe una alternativa mejor?
Evidencia: Repetición, contexto de retorno y sustitutos utilizados.
02 · DECLARED VS OBSERVED
La solicitud sigue siendo válida, pero responde otra pregunta
DECLARED FEEDBACK
- Expresa una necesidad, expectativa o interpretación
- Explica el contexto que la persona puede verbalizar
- Ayuda a formular una hipótesis sobre el trabajo que intenta hacer
OBSERVED BEHAVIOR
- Muestra si descubre la solución
- Muestra si la entiende y la intenta
- Muestra si obtiene valor y vuelve
El feedback no se descarta. Se interpreta y se contrasta con el comportamiento.
Decir “los usuarios no saben lo que quieren” sería una simplificación. Las personas sí pueden revelar problemas, restricciones y expectativas. Lo que una petición no garantiza por sí sola es qué solución adoptarán, en qué momento y con qué esfuerzo.
03 · SCENARIO
Construir la literalidad puede omitir la necesidad
ESCENARIO ILUSTRATIVO
“Quiero un dashboard”
Un cliente pide un dashboard para entender cómo va su operación. El equipo construye una pantalla con más gráficas. Después de la entrega, casi nadie la visita.
PETICIÓN
La persona nombra una forma: dashboard.
NECESIDAD
Quiere saber qué decisión requiere atención y confiar en el resultado.
COMPORTAMIENTO
La pantalla no cambia la revisión ni el workflow del equipo.
HECHO
La feature existe y puede abrirse.
INTERPRETACIÓN
La necesidad estaba relacionada con orientación, no necesariamente con más visualización.
INCERTIDUMBRE
Qué decisión quería tomar, cuándo y qué señal habría sido suficiente.
Decisión habilitada: Investigar el momento de decisión y el resultado esperado antes de mejorar la navegación o añadir más gráficas.
04 · DIAGNOSTIC
La primera pregunta no es cómo aumentar adopción
La primera pregunta es: “¿por qué esperábamos que la utilizaran?”. Responderla obliga a reconstruir la cadena: quién expresó qué problema, qué interpretación hizo el equipo, qué cambio esperaba observar y qué evidencia habría confirmado la hipótesis.
Sólo después tiene sentido elegir una intervención: mejorar descubrimiento, explicar el valor, reducir el esfuerzo de prueba, cambiar la solución o aceptar que el caso era contextual.
PRODUCT & UX DIAGNOSTIC
Entiende la adopción antes de empujarla.
Ordena feedback, comportamiento y la incertidumbre que todavía impide decidir el siguiente cambio.
Analiza tu situación de productoFUENTES
Fuentes
- Silicon Valley Product Group · Discovery como búsqueda de evidencia sobre problemas y soluciones.
- Google Research · Task success, engagement y retención como dimensiones distintas de experiencia.
FOUNDERS UX
Construir rápido no es suficiente.
Construir lo correcto es la diferencia.
Cuéntanos qué está frenando tu producto y lo revisamos contigo.