Cuando la investigación contradice al negocio: qué hacer (y qué no)
Uno de los momentos más tensos en la carrera de cualquier profesional de Experiencia de Usuario es aquel en el que los datos dicen «no», pero la estrategia del negocio grita «sí». A menudo nos dicen que nuestro trabajo es entender a los usuarios, pero la realidad es que gran parte de nuestro éxito depende de entender y gestionar a los stakeholders.
La gestión de este conflicto entre la evidencia empírica y la visión ejecutiva es crítica. Si los stakeholders no están listos para escuchar o tienen expectativas erróneas, no importa cuán interesantes sean los hallazgos: caerán en saco roto. A continuación, presentamos una guía táctica para navegar estas aguas turbulentas sin naufragar.
Señales de alerta: cuando el stakeholder ya ha decidido
El primer paso es identificar a qué te enfrentas. A menudo, las decisiones de diseño o producto no se basan en evidencia, sino en lo que se conoce como HiPPO (Highest Paid Person’s Opinion o la Opinión de la Persona Mejor Pagada).
Debes estar alerta si observas estas situaciones:
- Un ejecutivo insiste en una elección de diseño simplemente porque «le gusta más así».
- Un Product Manager fuerza un paso extra en el signup porque «se siente más premium», ignorando las tasas de abandono.
- Se rechazan hallazgos de usabilidad basándose en «lo que quiere el jefe» en lugar de lo que necesita el usuario.
Además del efecto HiPPO, puedes encontrarte con el Stakeholder Escéptico. Este perfil suele decir cosas como: «No necesitamos investigar, no tenemos tiempo y, además, ya sabemos la respuesta». A menudo, su resistencia nace de experiencias negativas pasadas donde la investigación no condujo a mejoras significativas.
Cómo presentar hallazgos incómodos sin romper alianzas
El error más común es entrar en una batalla de egos. Recuerda: ¡los stakeholders no son tus enemigos! El objetivo es encontrar un enfoque adecuado para cada tipo de interlocutor.
La técnica de «Mostrar, no decir»
Para los escépticos o los líderes guiados por su instinto, los datos abstractos pueden no ser suficientes. Es más difícil para un HiPPO descartar un problema cuando ve un video de un cliente real diciendo: «No entiendo cómo usar esto». Dejar que los stakeholders observen entrevistas o clips de video donde los usuarios luchan con el producto suele provocar epifanías que los reportes escritos no logran.
Estructura tus hallazgos: el método FIRE
Para que una recomendación «incómoda» sea digerible y accionable, sugerimos usar la estructura FIRE (Finding, Implication, Recommendation, Expectation):
- Hallazgo (finding): describe el hecho observado claramente.
- Implicación: explica el impacto negativo en el usuario o en el negocio (ej. pérdida de ingresos o frustración).
- Recomendación: ofrece una acción concreta para solucionarlo.
- Expectativa: describe el beneficio anticipado tras implementar el cambio.
Reencuadre estratégico: del “esto no funciona” al “esto sí podría funcionar”
Decir «no» a una funcionalidad solicitada es peligroso. En su lugar, utiliza la investigación para reorientar la asignación de recursos basándote en evidencia.
Un caso de estudio relevante muestra cómo transformar el desarrollo de funcionalidades basadas en opiniones a decisiones basadas en evidencia. En lugar de preguntar «¿Deberíamos construir esto?», el reencuadre estratégico debe ser: «¿Cómo priorizamos sistemáticamente las inversiones basadas en el valor para el usuario y el impacto en el negocio?».
La paradoja de la preferencia vs. el rendimiento
A veces, el negocio quiere construir funcionalidades complejas porque los usuarios dicen quererlas. Sin embargo, la investigación a menudo revela una paradoja: los usuarios dicen preferir opciones ricas en funcionalidades, pero su rendimiento es mejor con experiencias enfocadas.
El trabajo es identificar la demanda latente. Por ejemplo, mediante investigación mixta (cuali-cuantitativa), se puede demostrar que ciertas funcionalidades «aspiracionales» (como sistemas complejos de personalización) pueden tener una alta intención de uso pero una urgencia baja, mientras que arreglar problemas de discoverability (descubrimiento de funciones) en lo que ya existe ofrece un ROI inmediato sin un coste de desarrollo tan alto.
Casos típicos de conflicto
- Features aspiracionales (feature bloat): es común que las organizaciones desperdicien entre el 30-40% de sus recursos de desarrollo construyendo lo que pide el stakeholder más ruidoso. El deseo de construir productos «todo en uno» a menudo paraliza al usuario promedio y conduce a la fatiga de decisión.
- Solución: Aplica la divulgación progresiva (mostrar solo lo necesario) y valida la simplicidad con pruebas de usabilidad, no solo con heurísticas.
- Onboarding y pricing: un stakeholder «novato» puede no tener el vocabulario para discutir investigación, pero siente el dolor de una caída en el proceso de onboarding.
- Solución: localiza la fuente del dolor (ej. baja conversión) y ayuda al stakeholder a formular preguntas como «¿Sabemos las 3 necesidades principales que nuestros usuarios querrían ver?» en lugar de actuar por instinto.
- Diseñar para el stakeholder: cuando los requisitos del negocio anulan los insights de los usuarios, el resultado suele ser un producto que confunde. Por ejemplo, un dashboard financiero diseñado bajo KPIs internos que los usuarios finales no entendían en un 60%.
Qué pasa cuando se ignora la investigación (y cómo documentarlo)
A veces, a pesar de tus mejores esfuerzos, la decisión ya está tomada. Si un VP exige un carrusel en la home a pesar de la evidencia de que los usuarios lo ignoran, tienes que elegir tus batallas.
Sin embargo, ignorar la usabilidad es un riesgo comercial medible. Los errores de diseño prevenibles tienen costes directos en tasas de rebote, tickets de soporte y menor retención.
Cómo documentarlo para el futuro: si no puedes detener una mala decisión, asegúrate de que la evidencia quede registrada.
- Priorización visual: utiliza tablas de resumen en tus informes con códigos de colores (rojo, amarillo, verde) para comunicar la severidad de los problemas ignorados.
- Claridad en la «No Recomendación»: si la cultura de la empresa te impide dar una recomendación directa o esta es rechazada, articula claramente los hallazgos para que los stakeholders tengan que formular sus propios pasos a seguir, asumiendo así la responsabilidad de la decisión.
La investigación de UX no se trata de tener la razón, sino de reducir el riesgo. Tu rol no es solo detectar problemas, sino facilitar discusiones donde los datos (y no la jerarquía) guíen el camino. Al fin y al cabo, el buen diseño no se trata de complacer al jefe, sino de servir al usuario.
