Cuando la investigación dice 'esto no funciona': cómo comunicar verdades incómodas en UX

Índice

El rol que nadie te cuenta
Mi primera vez dando malas noticias (en el bootcamp)
El mito del UXer que solo trae buenas noticias
“No es que yo lo diga, lo dice la investigación”
Cómo comunicar un hallazgo doloroso (sin que te maten)
El silencio en la sala: cuando presentamos verdades incómodas a gerentes
Y si aún así no te escuchan
Referencias

El rol que nadie te cuenta

Desde que empecé en UX me ha tocado decir verdades incómodas. Y cada vez estoy más convencida de que eso ES parte esencial del rol.

No es algo que te cuenten en los cursos. Te hablan de metodologías, de entrevistas, de testeos, de cómo armar un journey map. Pero nadie te prepara para el momento en que tienes que pararte frente a un equipo —o peor, frente a gerentes— y decir: “Los datos muestran que esto no va a funcionar.”

Y sin embargo, ahí está el valor real de lo que hacemos. Porque cualquiera puede confirmar lo que el equipo ya quería escuchar. Pero se necesita otra cosa para decir lo que nadie quiere oír.

Mi primera vez dando malas noticias (en el bootcamp)

La primera vez que me tocó fue durante el bootcamp, y lo pasé pésimo.

El cliente era una ONG en Santiago. Llegaron con la solución ya definida: querían una app para comunicarse con sus beneficiarios. No llegaron con el dolor, llegaron con lo que querían construir. Y nosotros —inexpertos— partimos asumiendo que ESO era lo que se necesitaba.

(Hoy como consultora es algo que trabajaría desde el inicio: ¿por qué una app? ¿qué problema busca resolver? Pero bueno, los clientes no tienen por qué saber eso, y nosotros estábamos aprendiendo.)

Fuimos a hacer trabajo de campo, entrevistas en las casas de las personas que atendía la ONG. Y ahí entendimos algo incómodo: casi no usaban el celular. O sea, sí lo usaban, pero solo para WhatsApp, Facebook y llamar. Nada más. Ni siquiera descargaban apps nuevas.

La conclusión era obvia: no convenía hacer una app. Lo que necesitaban era un canal de comunicación por WhatsApp, algo que ya conocían y usaban.

Pero primero tenía que comunicárselo a mi propio equipo de desarrollo. Y ellas no querían escuchar eso. Ellas querían desarrollar. Recuerdo el estrés de esa conversación, de sentir que estaba yendo contra mi propio equipo.

Después vino la presentación al cliente. Defendí la idea, expliqué la realidad de los usuarios, su manera de funcionar. Quedamos en segundo lugar. El cliente quería una app de todas formas.

Pero tras bambalinas nos contaron algo que me quedó grabado: dijeron que nuestro equipo había sido el único que realmente entendió al usuario.

Fue genial y triste al mismo tiempo. Genial porque validó que estábamos en lo correcto. Triste porque ellos igual querían la app, a pesar de entender que probablemente no la iban a usar.

Con el tiempo creo que hubiera actuado un poco diferente. Primero, hubiera cuestionado la premisa inicial: ¿por qué una app? ¿cuál es el problema real que quieren resolver? Y después, aunque igual hubiera dicho que los usuarios no van a usar una app nueva, quizás hubiera propuesto algo que simulara la experiencia de WhatsApp, algo simple y familiar. Llegar con algo al cliente sin traicionar lo que descubrimos.

Pero lo que no cambiaría es haberme mantenido fiel a lo que la investigación mostraba. Ese orgullo de defender una idea impopular porque los datos la respaldaban… eso sigue siendo parte de lo que me motiva en este trabajo.

El mito del UXer que solo trae buenas noticias

Existe una fantasía en algunas organizaciones: que investigar es básicamente validar lo que el equipo ya quería hacer.

“Hagamos un testeo para confirmar que vamos bien.” “Entrevistemos usuarios para que nos digan que les gusta.” Como si la investigación fuera un trámite para sentirse bien con las decisiones ya tomadas.

Pero eso no es investigación. Eso es buscar confirmación.

El valor del UX Research no está en decir lo que otros quieren escuchar. Está en reducir el riesgo de tomar malas decisiones.

La investigación de verdad te puede decir cosas que no quieres escuchar:

Que tu idea no resuelve el problema que crees que resuelve
Que los usuarios no entienden tu producto
Que la competencia lo está haciendo mejor
Que el feature que quieren construir no tiene sentido para nadie

Y cuando eso pasa, el rol del UX Researcher no es suavizar el mensaje hasta que sea digerible. Es comunicar lo que hay, con los datos que lo respaldan.

“No es que yo lo diga, lo dice la investigación”

Esta frase me ha salvado muchas veces.

Porque cuando comunicas algo incómodo, es fácil que lo tomen personal. Que sientan que tú estás criticando su idea, su trabajo, su criterio. Y ahí se pone defensivo todo el mundo.

Pero si logras separarte emocionalmente del mensaje, cambia la dinámica. Tú eres el mensajero, no el autor. Los datos son los que hablan.

“La investigación muestra que el 7 de 8 usuarios no completaron el flujo.”

“En las entrevistas, los clientes mencionaron repetidamente que prefieren X sobre Y.”

“El benchmark indica que los competidores resuelven esto de una manera que nuestros usuarios valoran más.”

No es tu opinión contra la de ellos. Son datos. Evidencia. Y eso es más difícil de ignorar (aunque algunos lo intentan igual, pero ya llegaremos a eso).

Cómo comunicar un hallazgo doloroso (sin que te maten)

Después de varios años haciendo esto, he aprendido algunas cosas que ayudan:

1. Prepárate (mucho más de lo que crees necesario)

Gran parte del trabajo del UXR es la preparación del documento de presentación. Y no hablo solo de “hacer las slides”. Hablo de:

Revisar que no tenga errores (o los menos posibles). Si algo no estoy segura o no tengo evidencia clara, lo saco.
Preparar citas textuales y videos breves de los usuarios. Esto es clave: cuando un gerente escucha directo de la boca del usuario “esto no lo entiendo”, es mucho más poderoso que cuando lo dices tú.
En proyectos complejos, prepararme una base de preguntas que me podrían hacer (sí, como si estuviera en el colegio 😅). Así tengo respuestas preparadas a potenciales cuestionamientos.

Esto último me ha salvado varias veces. Cuando alguien pregunta “¿pero probaron con usuarios de X segmento?” y puedo responder con seguridad “sí, teníamos 3 de ese perfil y mostraron el mismo patrón”, la conversación cambia.

2. Llega con datos, no con opiniones

“Creo que esto no va a funcionar” es muy diferente de “El 80% de los usuarios abandonó en este punto del flujo.”

Lo primero es una opinión que se puede debatir. Lo segundo es un hecho que hay que explicar.

3. Muestra el riesgo de continuar

No basta con decir “esto no funciona”. Hay que mostrar qué pasa si seguimos adelante:

¿Cuánto dinero se puede perder?
¿Qué métricas se van a ver afectadas?
¿Qué va a pasar con la experiencia del usuario?

Los stakeholders toman decisiones basadas en riesgo. Si les muestras el riesgo concreto, es más fácil que reconsideren.

4. No llegues solo con el problema: ofrece caminos de solución

Esta es probablemente la parte más importante. Nunca llego a una presentación solo con el dolor. Lo que hago es:

Primero, identificar claramente el problema. Qué encontramos, qué duele, qué no funciona.

Paralelo o al final del documento, la propuesta de solución. No solo “esto está mal”, sino “esto está mal y así podríamos resolverlo”.

A veces el problema es pequeño y la solución es directa. Pero a veces es complejo y requiere varias formas de continuar e iterar. Dependiendo de lo que se investigue, el dolor puede estar en la experiencia, en el contenido, en el flujo, en la arquitectura de información… y cada uno tiene caminos distintos.

Lo que presento suele verse así:

Hallazgo: Los usuarios no encuentran X.

Propuesta ideal: Rediseñar la arquitectura de información del módulo completo.

Alternativa si hay restricciones de presupuesto/tiempo: Mejorar el labeling y agregar un acceso directo desde el home.

Siguiente paso si necesitamos más información: Investigar específicamente el modelo mental de los usuarios respecto a la categorización actual.

A veces por presupuesto no se puede hacer la solución ideal. Está bien. Pero señalo cuál sería el ideal, y ofrezco alternativas que se ajusten a la realidad. Eso le da al stakeholder opciones, no un callejón sin salida.

Y a veces la recomendación es “continuar investigando algo más específico”. Porque no siempre una investigación responde todo. A veces abre nuevas preguntas que vale la pena explorar antes de invertir en desarrollo.

5. Sé ejecutivo

Los gerentes no tienen tiempo para 50 slides. Ve al punto. Los hallazgos principales primero, la evidencia de respaldo después.

El silencio en la sala: cuando presentamos verdades incómodas a gerentes

Momento de silencio en sala de reuniones después de presentar hallazgos difíciles de investigación UX

Una de las experiencias más intensas que tuve fue en Sodimac.

El objetivo era amplio: entender por qué otro retailer estaba ganando tanto espacio comercial. No era “validar nuestra propuesta” ni “confirmar que vamos bien”. Era ir a buscar la verdad, aunque doliera.

Hicimos un benchmark profundo. No solo desk research, también entrevistamos clientes. Y entendimos un montón de verdades dolorosas de por qué esta competencia estaba ganando terreno por sobre Sodimac en ese momento.

Presentamos los hallazgos a gerentes. Fue super difícil. Nos dio miedo decir que nos estaban ganando, y por qué. Son cosas dolorosas de escuchar.

Recuerdo el silencio en la sala después de mostrar algunos hallazgos. Ese momento incómodo donde nadie sabe qué decir.

Pero a la vez, creo que ganamos un espacio de credibilidad enorme. Creían mucho en nuestro trabajo en esa empresa, más que en otras donde he estado. Y creo que parte de eso fue porque no les dijimos lo que querían escuchar. Les dijimos lo que necesitaban saber.

Y si aún así no te escuchan

Esto también pasa. Y está bien.

No tenemos control sobre las decisiones finales. Nuestro rol es reducir el riesgo de equivocarse, no eliminarlo. Podemos mostrar la evidencia, explicar las implicancias, proponer alternativas. Pero al final, la decisión es de otros.

A veces van a ignorar tus hallazgos. Van a seguir adelante con la idea original. Van a construir el feature que los datos dicen que no va a funcionar.

Y cuando eso pase, no es un fracaso tuyo. Hiciste tu trabajo: trajiste la información. Lo que hagan con ella está fuera de tu control.

Lo importante es que quede documentado. Que en algún lugar exista el registro de “la investigación mostró X, se decidió hacer Y”. No para decir “te lo dije” después (aunque a veces dan ganas), sino para que la organización pueda aprender de sus decisiones.

Comodidad en la incomodidad (muy zen)

Decir verdades incómodas es incómodo. No hay forma de hacerlo fácil.

Pero es lo que nos hace útiles. Cualquiera puede confirmar lo que el equipo ya quería hacer. Se necesita otra cosa para pararse y decir “los datos muestran que esto no va a funcionar, y acá está la evidencia”.

Eso es parte esencial del rol. Y aunque a veces no te escuchen, aunque a veces el cliente igual quiera la app que nadie va a usar, hay algo valioso en mantenerse fiel a lo que la investigación muestra.

Porque al final, no es que tú lo digas. Lo dice la investigación.

¿Te ha tocado comunicar hallazgos incómodos? Me encantaría escuchar tu experiencia. Escríbeme en LinkedIn.

Preguntas frecuentes al comunicar hallazgos negativos

¿Cómo comunicar hallazgos negativos sin generar resistencia?

La clave es separarte del mensaje: tú eres el mensajero, no el autor. Presenta los datos de forma objetiva, muestra el riesgo de no actuar, y siempre ofrece alternativas o caminos de solución. No se trata de ganar un argumento, sino de dar la información que el equipo necesita para tomar mejores decisiones.

¿Qué hago si los stakeholders ignoran mis hallazgos de investigación?

Primero, asegúrate de que el formato de comunicación sea el adecuado para esa audiencia (algunos necesitan números, otros visuales, otros prototipos). Si aún así no actúan, documenta los hallazgos y las recomendaciones. No tienes control sobre las decisiones finales, pero sí sobre dejar registro de lo que la investigación mostró.

¿Es mi responsabilidad como UX Researcher proponer soluciones?

Depende del contexto. He visto que varía mucho según la empresa y cómo está organizado el equipo. En equipos pequeños, a veces te toca llegar con soluciones bastante elaboradas. En equipos más grandes, te unes al equipo ampliado a trabajar en soluciones e iterar en ellas juntos. Pero en todos los casos, se espera que al menos señales caminos posibles: desde una recomendación concreta hasta sugerir que se necesita más investigación en un área específica.

¿Cómo gano credibilidad para que me escuchen cuando traigo malas noticias?

La credibilidad se construye siendo consistente: cuando dices que algo funciona, funciona. Cuando dices que algo no funciona, no funciona. Con el tiempo, el equipo aprende a confiar en tu criterio precisamente porque no les dices solo lo que quieren escuchar.

Referencias

Portigal, S. (2013). Interviewing Users: How to Uncover Compelling Insights. Rosenfeld Media.
Greever, T. (2015). Articulating Design Decisions: Communicate with Stakeholders, Keep Your Sanity, and Deliver the Best User Experience. O’Reilly Media.
Minto, B. (1987). The Pyramid Principle: Logic in Writing and Thinking. Pearson Education.
Nielsen Norman Group. (2018). Making Usability Findings Actionable.