Si un equipo de desarrollo o una organización aún opera con mentalidad de cascada, es lógico que vea el Research como un obstáculo en lugar de una inversión. Para ellos, ya hay un plan definido, y cualquier tarea adicional solo “retrasa” la ejecución.

El problema es que esta mentalidad asume que ya saben qué construir, sin cuestionarse si eso realmente resolverá el problema, o incluso sin detenerse a considerar cuál es el verdadero problema a resolver.

Desde la mentalidad de cascada, es inevitable ver al diseño como algo estético y que se pretenda incorporarlo al final, cuando ya todo esté decidido. No se puede concebir que el diseño pueda desafiar el modelo mismo del sistema, como en el caso de que la investigación y el diseño de interacción planteen la necesidad de una función de “deshacer”, que no es una pantalla bonita sino un cambio en la arquitectura y la lógica de negocio.

Si se intenta incorporar UX al final, lo que se terminará incorporando no será UX.

Porque la realidad es que la consultora fundada por Don Norman –quien acuñó el término “User Experience”– advierte desde 2014 que sin UX Research, no hay UX.

En el mejor de los casos, habrá tan sólo UI: la interfaz. Y en el más usual, habrá una capa estética superficial tratando de maquillar el chancho de decisiones de diseño cometidas por personas de negocio, marketing o IT sin formación en la toma de decisiones de Diseño — sin siquiera saber que lo que estaban cometiendo, eran decisiones de Diseño.

“No tenemos tiempo” para hacer Research, significa “todavía no estamos preparados”

Cuando los decisores dicen que “no tienen tiempo” para hacer UX Research, lo que realmente están diciendo es que todavía no lo han hecho ni entendido su valor: el Research sería “una pérdida de tiempo”.

Si lo entendieran como lo que es –como algo crítico para construir software que resulte aceptado y realmente productivo– , encontrarían el tiempo.

Y para eso, es necesario primero entender que el usuario no es esa cosa molesta entre la silla y el teclado. El usuario es lo que le da sentido al software: porque sin usuarios no hay software, sólo instrucciones que nunca se ejecutarán y datos que nadie verá, ocupando lugar en algún medio de almacenamiento.

Y es la filosofía Lean, base de la agilidad, la que postula que valor es lo que el cliente final, el verdadero usuario, valora. Todo lo demás es desperdicio.

El manifiesto ágil fue redactado en febrero de 2001: en estos días, cumple 24 años.

Los ingenieros que han ignorado todo este tiempo la buena nueva que sus colegas les han presentado, difícilmente estén preparados para recibirla de manos de diseñadores, que ven como esa especie inferior que en lugar de estudiar una carrera en serio, se dedicó a aprender qué color combina con cuál.

Como profesionales, en Kambrica valoramos nuestro tiempo y el de nuestros clientes. Por eso, en nuestro primer encuentro, es clave entender si podremos construir una relación de valor o si, simplemente, no somos el proveedor que necesitan en este momento.

Hoy, el mejor indicador de si un proyecto será exitoso no es el presupuesto ni la cantidad de features que quieren diseñar, sino el nivel de madurez del equipo y la organización en metodologías ágiles.

Si el equipo aún no ha integrado la agilidad en su cultura de trabajo, es poco probable que pueda aprovechar UX estratégico. Porque sin ciclos iterativos y toma de decisiones basada en evidencia, el diseño se reduce a pintar pantallas y acomodar lo que ya fue decidido de antemano. Y ese no es el tipo de valor que ofrecemos.

UX estratégico para equipos maduros

Si este enfoque resuena con la cultura de tu organización, con tu equipo y con la manera en que quieren encarar su proyecto, entonces vale la pena que nos conozcamos. En Kambrica, trabajamos con equipos que buscan más que pantallas bonitas: transformamos la manera en que se toman decisiones para generar impacto real.

En los más de 25 años que llevamos en la industria, hemos confirmado una y otra vez que los proyectos exitosos (versus los que salen mal o que incluso se abandonan) no nacen de “briefs geniales”, ni de ejecutar sin más lo que el cliente pide. Lo que trae quien nos contrata no es una solución, sino un síntoma y una hipótesis. Si tomáramos su pedido como un plan cerrado, le estaríamos delegando las decisiones de diseño y la responsabilidad de sus consecuencias. Pero eso no es un servicio, es una renuncia. La verdadera diferencia no está en hacer pantallas, sino en diseñar sistemas que resulten adoptados por los usuarios, y que impulsen los comportamientos que crean valor.

Si en tu organización también quieren ir más allá de lo superficial, y trabajar en soluciones que realmente muevan la aguja, conozcámonos.