Hay una idea que me persigue desde hace tiempo y que se me ha vuelto a aparecer esta semana dando una formación sobre liderazgo operativo en experiencia de usuario. La idea es sencilla de formular, pero ligeramente incómoda de asumir: la mayoría de profesionales que trabajamos en diseño dedicamos más tiempo a ejecutar tareas que a hacernos cargo del resultado de esas tareas. Y esa diferencia, que parece sutil, lo cambia absolutamente todo. Estamos hablando del ownership en UX.
Voy a intentar explicarme sin caer en el discurso motivacional de domingo por la tarde, que ni es lo mío ni tampoco es domingo por la tarde.
Hacerse cargo no es lo mismo que cumplir con el encargo
Una cosa es hacer lo que nos piden, hacerlo bien, entregarlo en plazo y decir “aquí lo tienes”. Eso está perfecto, nadie lo discute y probablemente si tenemos un jefe mediocre, se va a conformar con ello. Pero luego hay otra cosa bastante distinta, que es hacerte responsable de que lo que has entregado funcione, sirva para algo y llegue a buen puerto una vez que sale de tus manos. Ahí estamos subiendo el nivel.
No es que una sea siempre buena y la otra necesariamente mala, porque hay contextos para todo. Pero es bueno que sepamos en cuál de las dos estamos invirtiendo más tiempo, porque eso determina cómo nos van a percibir, qué decisiones vamos a tomar y qué impacto va a tener nuestro trabajo en la organización.
Esto es algo que he visto muchas veces en los equipos con los que me ha tocado trabajar. Cuando alguien se limita simplemente a ejecutar sin cuestionar, acaba convirtiéndose en un perfil al que nadie consulta, es decir, esa persona irrelevante, que no cuenta para nadie. Y cuando nadie te consulta, te frustras porque sientes que no se cuenta contigo. Y eso genera una nueva frustración que consolida la idea de que nadie cuenta contigo. Pero claro, es que nunca planteaste nada ni nunca levantaste la mano. La gran lección de un escenario como que acabo de describir es que el ownership no viene de serie con el cargo, sino que se construye con las decisiones que tomamos cada día.
El triángulo que nos va a ahorrar muchos disgustos
Una herramienta que me resulta muy útil es lo que llamo el triángulo de la decisión, con tres vértices: resolver, informar y escalar. Cuando nos encontramos con un problema, tenemos que decidir rápido en cuál nos estamos situando, en cual estamos. Si tenemos la información, el criterio y la autonomía, lo podemos resolver sin pedir permiso. Si podemos resolverlo pero nuestro responsable debe saberlo, lo resolvemos y luego informamos del hecho. Y si la situación excede de nuestro alcance, escalamos.
Claro, aquí el problema es que escalar es lo más fácil. Es cómodo, nos quita de encima la responsabilidad de decidir. Pero cada vez que escalamos algo que podríamos haber resuelto por nuestra cuenta, perdemos credibilidad y contribuimos, querámoslo o no, a que el equipo de UX se perciba como un área que no decide. Y la noticia que a nadie debería sorprender es que si UX no decide, alguien decidirá por nosotros: marketing, negocio, desarrollo. Están ahí, siempre agazapados detrás de la esquina, esperando a nuestro momento de debilidad o incomparecencia.
Más allá de la narrativa, más o menos pintoresca, hay una sentencia que requiere que nos pongamos serios: no decidir tiene un coste invisible que solamente se ve cuando se acumula. Cuando nos damos cuenta de los síntomas, normalmente ya es tarde.
Nuestro trabajo termina cuando confirmamos que funciona, no cuando entregamos el Figma
Dejando de lado el hecho de que el encabezado me ha quedado muy largo, hay otra cuestión que me parece crítica y que tiene que ver con lo que pasa después del delivery. Tenemos una costumbre peligrosa en diseño: asociar la entrega con el trabajo terminado. Aquí están las pantallas, aquí están los flujos, ahí te los dejo. Pues no. El trabajo, nuestro trabajo termina cuando confirmamos que lo que hemos entregado se ha recibido, se ha entendido y se va a implementar tal y como lo habíamos acordado. Es tan sencillo como eso.
Para quienes tengan alguna duda acerca de este proceso, también quiero dejar muy claro que esto no es fiscalizar al equipo de desarrollo. Esto es enviar un mensaje 48 después de la entrega preguntando si hay dudas, si necesitan una sesión para revisar la estructura. Un email. Un minuto de nuestro tiempo. Porque si no lo hacemos, ese hueco que dejamos lo va a llenar alguien con su propio criterio, que probablemente no sea el nuestro.
Cada interacción que tenemos con otras áreas no es sólo una entrega o sólo una reunión. Estamos hablando de que se trata de una oportunidad de construir la imagen de un equipo de UX confiable, que tiene criterio y la actitud de defenderlo. O, por el contrario, de confirmar la percepción de que somos los chicos y las chicas que pintan pantallas y a los que se puede ningunear sin coste alguno. El escenario es diferente.
El ownership no es una actitud ni un rasgo de la personalidad, es una competencia profesional. Se entrena, se desarrolla y se mide. Y lo de es que yo soy así no es un argumento, es una excusa. Dicho con cariño, pero es lo que hay.
