Debes “aprender a hablar el lenguaje del negocio”. Este es sin duda uno de los consejos más repetidos a quienes son más neófitos en Diseño UX. Sin embargo, ésto casi nunca se explica con suficiente claridad.
Muchas personas lo interpretan simplemente como una falta de vocabulario: aprender a hablar de ROI, OKRs, o Churn (tasa de abandono) en una reunión con Stakeholders.
Otras personas lo interpretan como una falta de datos cuantitativos: “si no hablas con datos duros nunca van a considerar ninguna recomendación que hagas”. Eso deja a buena parte de los equipos de diseño esperando una métrica que muchas veces no está disponible o que casi nunca llega a tiempo.
Considero que saber hablar el lenguaje del negocio es algo más profundo que un simple problema de vocabulario o de acceso a datos. A mi parecer, implica tener la facultad de describir un problema de UX, según las consecuencias concretas de ese problema para una empresa u organización. Es decir, que costos, riesgos, ingresos o tiempos están asociados a ese problema de UX.
El problema no es que no te escuchen
Hace algunos años trabajé como líder de diseño UX en una empresa de servicios financieros. Tenía un equipo de diseño muy motivado, sobre todo a la hora de defender sus decisiones frente a los Stakeholders.
En una reunión, la Gerencia de Productos estaba empujando una implementación para uno de los productos estratégicos de la compañía, que el equipo de diseño consideraba que era muy deficiente. Una diseñadora salió a defender la postura del equipo con una frase: “Debemos poner al usuario en el centro”.
Todos en el equipo celebramos en la interna este comentario. Lamentablemente, éste no presentaba ninguna consecuencia medible para la organización. No le decía a la Gerente de Productos ni al resto de los Stakeholders cuáles serían las consecuencias si es que esa implementación seguía adelante tal como ellos estaban la estaban proponiendo.
Quien decide no está evaluando si tienes o no razón sobre el diseño o sobre los usuarios (a pesar de que probablemente sí tienes la razón). Está comparando dónde distribuir recursos que son limitados. Si tu argumento no entra en esa comparación, queda fuera de cualquier discusión antes de que alguien siquiera lo ponga sobre la mesa.
Eso generalmente no tiene que ver con el nivel de madurez de UX que tenga una organización, ni con un desinterés general por los usuarios o por tu criterio como profesional. Muchas veces sólo quiere decir que entregaste un dato que la persona que toma las decisiones de presupuesto no puede usar para nada, ya que no tiene con qué compararlo (de nuevo: costos, riesgos, ingresos o tiempo).
Cómo obtener mayor apoyo de los Stakeholders
Cada uno de los siguientes ejemplos corresponde a un mismo hallazgo de UX dicho de dos maneras distintas. La primera versión expresa solo un juicio u opinión; la segunda levanta una consecuencia concreta para la organización:
- De “esto es una mala experiencia” a “esto aumentará los tickets a soporte”
La primera versión del hallazgo es simplemente una opinión sobre la calidad de la UX de un producto/servicio. La segunda versión habla de un costo operativo, el cual cuenta con ownership, presupuesto y alguien que responde por ese costo todos los meses. - De “necesitamos más investigación” a “vamos a comprometer seis meses de desarrollo sobre un supuesto que nadie validó”
La primera versión suena a que UX pide más plazo. La segunda describe la exposición a un riesgo que ya existe, ya sea que lo levantes tú o no. Nadie aprueba un plazo extra por gusto, mientras que cualquiera aprobaría mitigar un riesgo que ya está puesto sobre la mesa. - De “este diseño de UI aumenta la carga cognitiva” a “este diseño de UI aumentará las posibilidades de que el usuario abandone la tarea”
Probablemente nadie fuera del equipo de diseño o de UX sepa qué significa “carga cognitiva” o hayan oído hablar alguna vez acerca de la Ley de Hick. El problema no es el término técnico, es que esta primera versión nombra la causa (el esfuerzo mental del usuario) en vez de la consecuencia. La consecuencia es dónde se caen los usuarios dentro del embudo de conversión, que es algo que los Stakeholders sí revisan con atención de forma periódica.
Un problema de diseño se prioriza junto a otros problemas de diseño. Un problema (o riesgo) de negocio se prioriza junto a otros riesgos de negocio, y esa es la mesa que sí tiene presupuesto. No se trata de inflar el problema, sino de ubicarlo en la lista donde efectivamente se toman las decisiones.
Cómo practicarlo esta semana
- Toma tu hallazgo más importante del mes y escribe su consecuencia en una unidad contable: pesos, horas, tickets, pasos o días de desarrollo.
- Averigua qué métricas miran las personas que deciden dentro de tu organización.
- Da un rango antes que un adjetivo. Hablar de: “entre 200 y 400 tickets al mes” es discutible; mientras que hablar de: “mala experiencia” ni siquiera llega a discutirse.
Si quieres hacer este ejercicio sobre un caso tuyo real en vez de en abstracto, revisemos juntos cómo presentas tus hallazgos de UX en una sesión de mentoría.