Una breve introducción a Agile, parte 1

El término Agile es cada vez más común en una gran cantidad de escenarios y contextos distintos a los del mundo de desarrollo de software donde tuvo su origen, incluido el de Experiencia de Usuario.

Contrario a lo que comúnmente se interpreta de primera instancia, Agile no se trata simplemente de cómo desarrollar productos de forma rápida. Agile busca, en esencia, transformar paradigmas y organizaciones para propiciar entornos de trabajo con personas felices, motivadas y comprometidas, logrando en consecuencia, productos exitosos y clientes satisfechos.

Contexto histórico sobre Agile

Actualmente, Scrum, Kanban y eXtreme Programming (XP) son los enfoques o frameworks más representativos de Agile; sin embargo, otros métodos relativamente emergentes que incorporan en su definición parte de los conceptos clave del Agilismo han ganado una creciente popularidad, sobre todo en el ecosistema del emprendimiento, como Lean Startup, Lean UX o Design Sprint.

Más allá de los frameworks, la verdadera naturaleza de Agile radica en la profunda transformación de la manera en la que pensamos y nos comportamos. Es decir, el Agilismo no sólo consiste en la adopción de procesos y herramientas, sino en un cambio de cultura, verdadero, profundo y significativo.

Para comprender los motivos por los cuales Agile hace un llamado al cambio de paradigmas, es necesario hacer un recuento de su origen y evolución porque, como decimos en UX, el contexto lo es todo.

El Modelo en Cascada y los antecedentes de Agile

Explicar qué es Agile implica ineludiblemente hablar primero de su némesis: el Modelo en Cascada. De la misma forma en que no es posible explicar La Fuerza sin el Lado Oscuro, para entender el surgimiento de Agile, es importante comprender las razones de su origen, aquello a lo que trataba de oponerse.

El Modelo Secuencial de Procesos o Modelo en Cascada (Waterfall Model) es un modelo metodológico de la industria de desarrollo de software que surgió en la década de los 70. Sin entrar demasiado en detalle (porque para eso está Wikipedia) el Modelo en Cascada propone una serie de pasos, rigurosamente en secuencia, para el desarrollo de software:

  • Especificación de requerimientos
  • Diseño
  • Implementación
  • Verificación
  • Mantenimiento
Modelo en Cascada
Modelo en Cascada

 

Lo que vale la pena destacar del Modelo en Cascada es que, de alguna u otra forma, surgió como una herencia del pensamiento Taylorista, que tuvo su máximo esplendor durante la Revolución Industrial, y que definía a los procesos como una división de tareas bajo un ambiente rígido. En el Taylorismo, las personas no tenían participación ni control en los procesos, “todo lo que queremos de ellos (los obreros) es que obedezcan las órdenes que les damos, que hagan lo que les decimos y que lo hagan rápido“, decía Frederick Taylor en 1906.

Recreen en su mente la mítica escena de Charles Chaplin en Tiempos Modernos. Eso es el Taylorismo. Reemplacen la cadena de montaje por líneas de código. Eso es el Modelo en Cascada.

Escena del largometraje Tiempos Modernos (1936).
Escena del largometraje Tiempos Modernos (1936).

La razón por la que la naciente industria del software de la década de 1970 consideró que era buena idea adoptar un modelo secuencial, rígido y que restringía tanto la libertad y creatividad de las personas sigue siendo un misterio y quizá el mundo nunca lo sabrá.

Es tan controversial el tema sobre cómo fue posible que el Modelo en Cascada se haya convertido en un estándar de la industria del software, que existen varios mitos alrededor, uno de ellas señala que desde su origen, el modelo fue malinterpretado y que su autor, Winston Royce, en realidad quiso decir que el modelo era una mala idea y que no era recomendable implementarlo pues “invitaba al fracaso”. No es broma. Incluso el Departamento de Defensa de los Estados Unidos, en 1985,  tuvo esa “interpretación” incorrecta y estandarizó su propio proceso para el desarrollo de software basado en el modelo de Royce y como suele ocurrir con casi todo, el resto del mundo siguió el mismo estándar.

Las circunstancias del contexto también pudieron influir notablemente en la estandarización del Modelo de Cascada, piensen en la alocada década de los 70: la tecnología era accesible sólo para unos pocos privilegiados; apenas eran los albores de Internet; Steve Jobs y Bill Gates eran un par de jóvenes que iniciaban la construcción de los imperios de Apple y Microsoft, respectivamente. Si lo vemos en perspectiva, el Modelo en Cascada se convirtió en el modelo más utilizado simplemente porque en ese momento se concebía al software como algo tan complicado, grande y robusto que sólo era posible producirlo bajo un proceso riguroso y detallado.

Uso de la tecnología a principios de la década de los 70.
Uso de la tecnología a principios de la década de los 70.

Al paso de los años, el mundo empezó a cambiar drásticamente gracias a una vertiginosa revolución de las Tecnologías de la Información. La tecnología llegó a la vida cotidiana y el cliente empezó a convertirse paulatinamente en el centro del universo en el desarrollo de productos y servicios.

Publicidad del lanzamiento de Apple II (1977). La tecnología llega a los hogares.
Publicidad del lanzamiento de Apple II (1977). La tecnología llega a los hogares.

La industria del software tuvo que empezar a adaptarse al nuevo escenario y los problemas del Modelo en Cascada comenzaron a emerger:

  • Poco o nulo involucramiento del cliente a lo largo del proceso.
  • Limitación de la participación activa de las personas responsables del desarrollo.
  • Incapacidad de responder satisfactoriamente ante cambios de negocio.
  • Documentación excesiva del proceso.
  • Tiempos demasiado largos de producción.
  • Recuperación tardía y costosa ante errores.

La caja de Pandora fue abierta.

Los orígenes de Agile

El Movimiento Agile surgió como una reacción de hartazgo a todo lo que significaba el Modelo en Cascada.

Para muchos expertos, el año 1994 representa el punto de quiebre en la historia del Agilismo, cuando todos los problemas que el Modelo en Cascada venía arrastrando por más de dos décadas quedan exhibidos en CHAOS Report, un estudio que reveló una cifra contundente e irrefutable:

más del 80% de los proyectos de software se entregaban con sobrecostos, en forma tardía, sin cumplir las expectativas de los clientes o incluso eran cancelados antes de concluirse.

La industria del software estaba en crisis, empezaron a surgir o a cobrar notoriedad métodos alternativos al Modelo en Cascada como Scrum, eXtreme Programming (XP) y Lean Software Development, por citar algunos. La nueva “sombrilla” de métodos empezaron a ser identificados con el nombre de Metodologías Livianas (Lightweight Methodologies). Comenzaba así la versión en el mundo del software de Civil War, o eras #teamwaterfall o eras #teamagile.

Hay que abrir un breve paréntesis en esta línea del tiempo. Aunque muchos métodos relacionados con Agile empezaron a ser cada vez más populares a partir de la década de los 90, no significa que hayan sido creados simultáneamente, algunos conceptos clave surgieron desde mucho tiempo atrás:

El siguiente hito en la historia del Agilismo llegó en el 2001 cuando un grupo de profesionales y entusiastas de los métodos livianos se reunieron “en lo alto de una montaña” (como suele contar Mike Beedle) para discutir cómo la industria del desarrollo de software debería hacer frente al nuevo contexto, cómo responder de mejor forma a los cambios que surgían por intereses de negocio y cómo consolidar una alternativa los procesos tradicionales de desarrollo de software caracterizados por la rigidez de su proceso. El Manifiesto Ágil vió la luz.

El Manifiesto Ágil

Estamos descubriendo mejores formas de desarrollar software…

Así inicia el Manifiesto Ágil, el documento que representa la declaratoria de principios de todo lo que significa el Agilismo.

Cuatro valores y doce principios. Es todo. Por más de 15 años, cada línea escrita en el Manifiesto Ágil ha permanecido intacta. Señal de su vigencia y pertinencia.

Valores:

  • Individuos e interacciones sobre procesos y herramientas.
  • Software funcionando sobre documentación extensiva.
  • Colaboración con el cliente sobre negociación contractual.
  • Respuesta ante el cambio sobre seguir un plan.

Principios:

  1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
  2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
  3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
  4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
  5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
  6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
  7. El software funcionando es la medida principal de progreso.
  8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
  9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
  10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
  11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
  12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

Waterfall vs. Agile

Lo que siguió después de la aparición del Manifiesto Ágil fue una disputa cada vez más frontal por la supremacía en la industria de desarrollo de software entre Waterfall y Agile; de manera simultánea, el mundo seguía cambiando, llegó el mundo de los dispositivos móviles, de las apps y startups.

En la versión 2012 del CHAOS Report (ahora llamado CHAOS Manifesto) se publicó una conclusión simbólica sobre la batalla entre Waterfall y Agile:

El proceso ágil es el remedio universal para el fracaso en los proyectos de desarrollo de software. Las aplicaciones de software desarrolladas a través del proceso ágil tienen tres veces la tasa de éxito del método en cascada tradicional y un porcentaje mucho menor de demoras y sobrecostos. El software debería ser construido en pequeños pasos iterativos, con equipos pequeños y enfocados”.

Parecía que la batalla tenía un ganador.

Ser Agile vs Hacer Agile

Ante el éxito de los métodos ágiles en la industria del software, su popularidad y adopción traspasaron fronteras. El ecosistema de emprendimiento y otras industrias distintas a las del desarrollo de software empezaron también a abrazar las prácticas ágiles. Hacían lo correcto, aunque por las razones incorrectas.

La promesa de ser el “remedio para el fracasso en los proyectos” comenzó a ser una carga muy pesada para el Agilismo y para lo que, insisto, realmente significa.

En 2015, otra vez el CHAOS Manifesto dió a conocer una cifra reveladora:

61% de los proyectos ágiles, son ágiles solamente en el nombre.

El Agilismo verdadero es orgánico, emerge, fluye; simplemente ocurre o perece en el intento. Es independiente de cualquier práctica dogmática, por encima incluso, de un “dogma ágil”, por contradictorio que esto parezca. Individuos e interacciones sobre procesos y herramientas. El origen de todos los males de la práctica incorrecta del Agilismo radica en la inadecuada comprensión del Manifiesto Ágil y todo lo que conlleva.

Agile no es una metodología. No es una colección de procesos y herramientas. Agile es un mindset, una forma de pensar y actuar distinta para encontrar mejores formas de hacer las cosas a través del empirismo y el aprendizaje.

La verdadera promesa de Agile

Quiero concluir con una cita del libro Por un Scrum Popular: Notas para una Revolución Agile, de Tobias Mayer y traducido al español por Alan Cyment:

“Pinten en el aire una oficina donde reina la risa y la pasión. Donde todos, inspirados por un espíritu de camaradería, habitados por un clima de entusiasmo, propósito común y esperanza, trabajan en un ambiente donde se fomenta la escucha activa, la comunicación abierta y la colaboración a mansalva.

Estoy convencido de que se puede convertir esta imagen en realidad usando un mecanismo simple y conocido, que les permitirá llegar desde su crudo presente hasta ese sitio donde les gustaría estar. Y no, ese mecanismo no se llama Scrum.

No hay framework, proceso o metodología que por sí solo permita alcanzar esta visión. Hay una sola persona que puede hacer realidad esta visión. Ese alguien eres tú”.

Espero que este llamado, los haga pensar en abrazar el Agilismo por las razones correctas.

Diseñador de Experiencia de Usuario. Scrum Master Certified. Fotógrafo. Ha participado en proyectos vinculados a HCI, usabilidad y UX en el ámbito académico, empresarial y gobierno desde 2007. Es parte del equipo de UX Nights.

El rol del Sprint Master en un Design Sprint

Design Sprint es una metodología de trabajo para resolver problemas de diseño en una semana, y utiliza elementos de metodologías ágiles y de design thinking.

Design Sprint es un modelo de colaboración que funciona para empresas o equipos de cualquier tamaño y para resolver casi cualquier problema en unos pocos días, en buena parte porque tiene límites claros sobre el uso del tiempo y los recursos que se utilizan durante el proceso. El responsable de establecer esos límites es una persona en el equipo que tiene el rol del sprint master.

Sprint masterEl sprint master es la persona que lleva el liderazgo de la sesión, y es quien ayuda a definir el reto de diseño en el sprint, define al equipo de trabajo y los ayuda a pasar por todas las etapas del proceso.

El rol de sprint master requiere entendimiento y experiencia profunda en los métodos de diseño centrado en el usuario, desarrollo de estrategias, facilitación de procesos y negociación (pero no es necesario ser un unicornio de UX).

Desarrollar estas habilidades toma tiempo y práctica, pero este rol hace una diferencia crítica al tratar de alinear al equipo para obtener resultados excepcionales.

Normalmente un sprint master es un arquitecto o especialista en experiencia de usuario: una persona con experiencia en la gestión de equipos de trabajo que tiene un conocimiento profundo en el diseño de procesos y que no teme retar a su equipo a colaborar para producir resultados en poco tiempo.

El trabajo del sprint master

El rol del sprint master es muy similar a la del scrum master en Scrum, en el sentido de que su rol en el proceso es de maestro-esclavo; es decir, tiene el control del proceso pero solo puede usar ese control para ayudar al equipo a trabajar.

La sesión de design sprint es algo que también se debe diseñar, y aquí es donde el trabajo del sprint master comienza.

Flujo de trabajo del sprint master en una sesión de design sprint
Flujo de trabajo del sprint master en una sesión de design sprint

Un buen sprint master sigue un flujo de tareas bien definido antes, durante y después del sprint. Su éxito depende de su habilidad para guiar al equipo, hacer gestión del proyecto y entender los métodos de UX que funcionan en periodos de tiempo muy cortos. Este trabajo de planeación toma tiempo, por lo general un día de preparación por cada día de sprint.

Antes del design sprint

La tarea más importante antes de comenzar un design sprint es articular el reto de diseño significativo sobre el que se centrará el trabajo de las sesiones. Un buen reto de diseño debe ser breve, inspirador y debe especificar a los usuarios objetivo y los entregables al final del sprint.

El sprint master debe seleccionar e invitar a las personas que participarán en el equipo, agendar las sesiones con expertos y las entrevistas con usuarios para las fases de “entender” y “validar” del sprint.

Finalmente, el sprint master debe preparar el material de presentación de las sesiones, reservar el espacio de trabajo, consiguir el material de trabajo, los refrigerios, bebidas y en general, asegurárse de que el proceso fluya sin problemas o interrupciones.

Durante el design sprint

Cuando el sprint comienza, el sprint master asume el rol de facilitador y anuncia la agenda y los ejercicios, lleva control del tiempo e invita a todos a participar. Si el equipo necesita cambiar el enfoque del plan original, el sprint master se encarga de que el equipo tome decisiones con rapidez minimizando las discusiones y de que cubran sus objetivos dentro de los límites de tiempo.

Durante el proceso, el sprint master es responsable de Tomar Notas Todo el Tiempo (ABC: Always Be Capturing) en un pizarrón o rotafolio, usando post-its o en una bitácora.

Después del design sprint

Las sesiones de desig sprint normalmente terminan con mucha energía y emoción, cuando el equipo logra crear una idea tangible en unos pocos días. Un buen sprint master mantiene esa energía al crear un plan de seguimiento, compartir los resultados del proceso y solicitando retroalimentación de los participantes para mejorar las sesiones en el futuro.

Consultor en experiencia de usuario, developer, conferencista, escritor y emprendedor. Trabaja en Tesseract Space, es Google Expert en UX/UI, Microsoft Regional Director y co-fundador de UX Nights.

El valor de UX

¿Cuál es el valor del Diseño de Experiencia de Usuario? Esta pregunta que ha resonado desde la incepción de esta disciplina y que todavía no tiene una respuesta concreta, en parte por su naturaleza intangible.

Ponerle precio a UX no es fácil porque ésta no nació como un producto, de un modelo de negocio o una necesidad de mercado. Es la misma razón por la que no hay una licenciatura en diseño de experiencia de usuario. UX nació como una metodología de trabajo que tiene tantas maneras de implementarse como hay perfiles de usuarios.

Además, el perfil tan diverso de la gente que trabaja en la industria, los diferentes niveles de experiencia y la diversidad de entregables hace aún más compleja una valoración objetiva. El valor de UX, citando una de las respuestas más frecuentes, depende.

Mi experiencia profesional como publicista me ha vuelto sensible a la “venta” de la experiencia, y puedo afirmar que UX no es el único bien que tiene un problema de “asignación de valor”.

Las experiencias son para vivirlas

El problema se origina de su falta de tangibilidad. Una experiencia debe, como su nombre lo dice, ser experimentada: la experiencia no pesa, no está hecha de materiales físicos y la mayoría de los entregables que creamos los diseñadores de UX, como resultados de encuestas o análisis de casos, no existen físicamente y se materializan hasta que se documentan y se le ponen palabras algo que, por definición, se debe sentir.

Hablando de intangiblidad, hay muchas marcas ahí afuera que comercializan un bien intangible, aunque parezca que venden productos físicos. Starbucks, por ejemplo, es una de las empresas más disruptivas del último siglo, en buena parte porque aprendió a comercializar una experiencia.

El producto que Starbucks vende no es el café, sino la experiencia en el consumo de café que está controlada en cada detalle: el arreglo de las tiendas, escribir tu nombre en el vaso, el diseño del menú, las máquinas que usan, cómo capacitan a su personal, y otros factores. Su suma ha provocado que sus clientes asignaran el valor de una taza de café de Starbucks al doble de lo que estarían dispuestos a pagar por ella en otra cafetería.

Nike y Under Armour tamibién funcionan como ejemplo: estas marcas no venden ropa deportiva, venden un estilo de vida que es la suma de los detalles que genera una experiencia para sus clientes. Una persona que compra Nike sabe que no solo está comprando la tela y el pegamento del que están hechos sus zapatos deportivos, sino también la tecnología y la marca, cuya materialización de algo intangible es un producto que se puede sostener en la mano.

UX como producto, es intangible. Es una idea, un concepto o una metodología. La idea equivocada de que Diseño de Experiencia es un sinónimo de Diseño de Interfaz tiene su origen en que el diseño gráfico tiene un entregable “tangible” y es algo con lo que se puede interactuar.

Para muchos es más simple mencionar que cualquiera que sea el entregable ya trae la parte de UX de manera implícita sabiendo además que técnicamente esto es muy difícil de comprobar. Tal vez a Disney se le da muy bien el diseño de UX porque ellos lo que venden siempre se ha considerado intangible: Magia.

La subjetividad del valor

La otra parte que hay considerar además de la intangibilidad de la experiencia es su valor subjetivo. Una sección en el cerebro humano está diseñada para asignarle valor a las cosas. La palabra valor se puede traducir a muchas cosas: atención, tiempo o dinero. ¿Cómo se asigna ese valor?

Lo asignamos comparando la nueva experiencia con  nuestras experiencias previas -que en ocasiones puede no ser experiencias personales, sino que pueden haberse experimentado a través de otra persona-. A veces la experiencia no tiene un punto de comparación para las personas a las que se la intentamos vender, y por lo el primer contacto es fundamental para definir un estándar de valor.

He escrito antes sobre la importancia de entender a la persona a la que le estamos vendiendo tanto como al usuario de lo que vayamos a desarrollar, porque tenemos que entender las motivaciones y experiencias previas de ambos para definir cuál es el ‘valor’ para cada persona. ¿El cliente valora la innovación? ¿O quiere ser el mejor de su industria? La mayoría de los clientes valora la rentabilidad, que es un concepto fácil de entender y explicar: “te cuesta 10 y te regresa 20, entonces tiene un retorno de 100%“.

El factor más importante a recordar es el famoso lema que Mauricio Angulo no me deja olvidar: “Nunca es culpa del usuario”. Si los clientes no valoran el trabajo de UX no es su culpa, somos nosotros los que hemos fallado en mostrar su valor. Así como StarbucksNike trascendieron el producto físico y educaron al consumidor a valorar la experiencia que les proporcionaban, nosotros como UX Designers tenemos el reto de ir más allá de las entrevistas y los análisis para mostrarle a los clientes que el verdadero valor es lo que UX puede hacer para mejorar sus negocios por medio de una experiencia centrada en las necesidades de sus usuarios.

Nike le pregunta a sus clientes ¿cuánto vale para ti la tecnología aplicada al deporte?Starbucks les pregunta ¿cuánto vale para ti la experiencia de tomar café? El trabajo de un Diseñador de UX es siempre preguntarle a sus clientes ¿cuánto vale para ti mejorar tu negocio pensando en las necesidades de tu consumidor?

Trabaja como Planner en SCLBITS. Es curador de UX Mexico y parte del equipo de UX Nights.

Cuando todo está mal: el Oscurantismo de UX

Hagamos un ejercicio: imaginemos que en los últimos meses has estado trabajando en encontrar cómo mejorar los diferentes puntos de contacto de la empresa en la que trabajas o la de alguno de tus clientes aplicando alguna o varias de las metodologías que existen de UX y diseño centrado en el usuario.

También has entrevistado a los usuarios y a los empleados, observado cómo funciona los procesos, encontrado qué es importante para la gente; ya has desarrollado un ejercicio de retorno de inversión y puedes asumir o prometer cierto valor agregado porque has aplicado diseño de experiencia de usuario y ya conoces cuáles son las prioridades y motivaciones de las personas que trabajan ahí.

Después de muchas semanas de trabajo, finalmente llega la junta con el director y el consejo de la empresa y ya tienes lista una presentación con todos tus descubrimientos y propuestas:  ellos te miran con los ojos abiertos y toda su atención porque han escuchado de la “magia” de UX aunque poco saben del tema. Sabes que aplicar UX en la empresa va a revolucionar la manera en ésta opera.

Comienza la junta y abres diciendo que todo lo que se ha hecho hasta ese momento está mal. Todo está mal: la marca no escucha a los consumidores, la página es una pesadilla de utilizar, llueven quejas en las redes sociales, la calidad de la experiencia es pésima y lo peor es que tienes los números, los videos, las estadísticas y los testimoniales para probarlo, pero todo va a estar bien gracias a ti y al UX.

* * *

Ahora veamos la situación desde el punto de vista de las personas que están viendo tu presentación: frente a ellos hay una persona con menos experiencia que ellos vendiéndoles “UX”, algo que a su parecer es un término de moda que les va a costar dinero y tiempo sin ninguna certeza de que vayan a tener retorno de esa inversión. Además, este novato comienza diciendo cómo todo lo que se ha hecho hasta ese punto está mal hecho. No necesitan escuchar más, ésta presentación es una pérdida de tiempo.

* * *

¿Cuál es el punto de este ejercicio?

Hemos hablado mucho sobre la importancia de la empatía en el Diseño de Experiencia de Usuario, y he sido particularmente enfático en la importancia de ponernos en lugar de nuestros clientes y de la gente que paga por los proyectos. La empatía es importante también al momento de realizar una presentación sobre UX.

Los beneficios de UX en el diseño de productos son evidentes: sabemos que es una filosofía de trabajo que las empresas más exitosas del mundo utilizan, y también sabemos que es la única manera real de hacer que una empresa sea “a prueba del futuro” (future-proof). Si estás leyendo este artículo es porque ya sabes que UX es importante; el problema es que esta idea que no esté generado tracción fuera del círculo de los profesionales y entusiastas de UX.

Esto no es culpa de las empresas o de los clientes, finalmente su trabajo es velar por sus intereses. Si UX no está fundamentado en la esencia de la empresa, como en el caso de Disney, el concepto de “orientación al usuario” es un concepto alienígena a los procesos, ideologías, objetivos de la empresa y a las personas que los elaboran e implementan. No es que estén mal, es que no tienen las mismas prioridades que nosotros.

El punto de no regreso de UX

Jared Spool, un investigador de UIE -y uno de los UXers más importantes- escribió un artículo titulado “Beyond the UX tipping point” (‘Más allá del punto de no regreso en UX’) en el que explica como las empresas pasan por diferentes momentos al adoptar UX como parte de su esencia. Hay marcas y empresas más avanzadas en el proceso que otras, pero es común encontrarnos con empresas que están en lo que él denomina como “El Oscurantismo de UX“:

El Oscurantismo de UX: En este punto existe poca conversación de UX dentro de la organización. Se construyen diseños pobres que entregan experiencias frustrantes, pero no se tiene idea de cómo mejorarlos. Las prioridades de la organización se enfocan con frecuencia en la entrega y la funcionalidad, sin importar cómo se vea el diseño.

Si una organización está en el oscurantismo de UX, hacerlos sentir mal por su trabajo es destinar a que el proyecto fracase porque dentro de la organización no habrá apertura para discutir el tema. Todo lo que propongas puede hacer sentir mal a tus interlocutores sobre su metodos de trabajo, arraigándolos su manera de pensar y cerrando las puertas a cualquier propuesta para hacerlo diferente.

Lecciones en madurez de UX
¿Qué tan madura está tu empresa en UX?

El proceso de vender UX no es tan transparente o sencillo como nosotros quisiéramos: las empresas y los clientes tienen razones para ser sospechosos, finalmente han habido muchas modas y conceptos que cambian más rápido de lo que ellos quisieran, y ninguna tiene garantía de éxito. Ellos tienen todas las razones para creer que UX es una moda más, otra manera de venderles cosas que ellos no creen necesarias.

En un artículo más reciente, Spool dice que nadie puede convencer a los clientes de implementar UX, sin importar cuánto sepa del tema. Es difícil convencer a los directivos dónde invertir o no, ya que la decisión debe venir de ellos al  encontrar un beneficio que los beneficie directamente. Ponerte frente a ellos y echarles en cara que todo lo que hacen está mal no ayuda.

Spool da un consejo: para vender UX necesitas conocer y entender a la gente que lo va a comprar: ¿cuáles son sus necesidades? ¿sus objetivos? A nivel personal y profesional, ¿son ególatras, les preocupa su futuro? ¿No les importa su trabajo? Hay muchos escenarios posibles y la manera de presentarles proyectos de UX es diferente para cada uno, pero sea cual sea, tiene que ser una presentación que explique cómo UX los beneficia a ellos y trabaja para sus necesidades.

No son ellos, eres tú

Yo quiero aportar otro consejo: no es necesario decir que lo que existe está mal y lo que nosotros proponemos está bien. En vez de eso, hablemos de mejoras, de construir sobre lo que ya existe. Si la empresa actualmente produce  y sabemos que con UX podemos producir diez veces más, hablemos de “evolución” y dónde están parados actualmente para ver hacia arriba. Habrá clientes más abiertos a hacer cambios y procesos más fáciles de mejorar que otros, la única manera es investigar y conocer a fondo nuestros clientes, sobre todo siendo empáticos con ellos.

Hay que tener en mente que como las cosas están implementadas actualmente en una empresa probablemente fueron hechas por personas que están todavía en el proyecto, y aunque sepan que su implementación no es perfecta, nunca les va a gustar escuchar que alguien más lo critique para hacerlo trizas. El trabajo como está hecho actualmente pone en evidencia las prioridades del equipo que lo realizó: ¿el contenido es terrible pero el diseño visual no está mal? Es señal de que el cliente es muy visual y prioriza el aspecto gráfico de las propuestas. ¿La página tiene un feed de Twitter de la mascota del dueño? Es señal de que te enfrentas a un cliente muy, muy difícil.

Página web hecha por el cliente
Gracias por darle ideas a los clientes, por The Oatmeal

Vender usabilidad resulta, sorprendentemente, una tarea más difícil de lo que muchos pudieran esperar. Es necesario considerar el factor humano del que depende la aprobación de estos proyectos, y por eso que debemos que integrarnos todos como industria, tener una postura sólida y clara de que lo que proponemos es una solución a muchos de los problemas que enfrentamos al vender UX. Tenemos que darle valor a nuestro trabajo y aprender a transmitirlo a la gente que lo necesita y que va a pagar por él.

Siendo realistas, puede que todo esté muy mal, pero siempre, siempre podría ser peor.

Trabaja como Planner en SCLBITS. Es curador de UX Mexico y parte del equipo de UX Nights.

Diseñando para el común denominador

En el diseño de UX es imposible satisfacer a todos los usuarios. Una buena implementación de UX debe permitir que la mayoría de los usuarios, o el “común denominador”, cumplan una tarea con la menor fricción posible.

Cuando trabajas en UX hay ciertos mantras que hay que repetir constantemente, porque al ser un campo en crecimiento y que constantemente es descubierto por nuevos candidatos a sumarse a sus filas, también se encuentra sujeto a muchas  interpretaciones y prejuicios. Algunos de estos mantras son “UX no es UI” o “UX es un campo diverso con diversas disciplinas”. Recientemente he sumado uno más a la lista: “si no se puede medir, no es UX”.

Hablar de UX requiere de hablar de términos como la empatía, de la que existe una definición pero cuya interpretación es completamente subjetiva; también hablamos de emociones como felicidadtristeza, frustración y satisfacción. Medir emociones es un proceso sumamente complejo, sin importar la herramienta que se utilice, y creo que las emociones nunca deberían ser una métrica en UX.

He leído que algunas personas opinan que UX busca “hacer felices a los usuarios”,  un objetivo que muchos especialistas plasman en sus currículums y portafolios; y suena bonito porque es un objetivo que parece dar un significado trascendente a lo que hacemos, pero que creo, contribuye a un serio problema de desinformación sobre el objetivo de UX.

Si el objetivo es ‘hacer felices a los usuarios’, debemos preguntarnos entonces:

  1. ¿Qué es hacer feliz a un usuario? Si el usuario ha tenido un mal día, una mala experiencia o no ha tomado su café, una experiencia difícilmente puede cambiar su estado de ánimo.
  2. ¿Es nuestra responsabilidad hacer felices a los usuarios? Imaginemos que estamos desarrollando una página o aplicación para cobrar impuestos o para una funeraria. Éstas experiencias no le brindan felicidad a absolutamente nadie.
  3. ¿Cómo se mide la felicidad? Un usuario podría contestar durante una entrevista o prueba de usabilidad que se siente feliz , pero he visto pruebas de usabilidad en las que los usuarios claramente se sienten frustrados pero no lo expresan y no se registra, incluso usando métodos de alta tecnología es difícil medir emociones.

UX requiere implementar soluciones tangibles, no solo de buenos deseos. Existe una gran cantidad de pruebas que sirven para probar conceptos, ideas o ejecuciones a niveles de estrategia, de diseño o de implementación, y en todos ellos hay métricas muy específicas para determinar si esos conceptos son apropiados o no, como las Tasas de rebote, tiempo en sitio, flujos de navegación, ‘Click Through Rate’ (o CTR,  la relación entre el número de usuarios que ven algo y los que interactúan con lo que ven), conversiones, suscripciones, número de usuarios activos, impresiones o incluso el Retorno de Inversión, que aunque no siempre se puede medir con exactitud, tiene un rol fundamental en la adopción de UX en las empresas.

Todas estas son diversas métricas que nos ayudan a saber si los usuarios completan una tarea de manera exitosa, eficiente y satisfactoria con datos duros para tomar una decisión en la implementación.

Estos datos también dependen de una evaluación considerablemente subjetiva: ¿cuál es un buen Bounce Rate, o un buen click-through rate? Algunos podrán encontrar promedios de la industria que sirvan como base para determinar un número pero que necesita contexto para ser realista. Por ejemplo, para algunas landing pages un Bounce Rate de 90% es aceptable, pero para otros formatos de páginas web, como las páginas de contenidos o de noticias en las que no lo es.

UX es un proceso continuo que nos somete en un ciclo de mejoras constantes, porque ninguna experiencia es ni perfecta y ni definitiva. Los usuarios, la tecnología, las interfaces y las implementaciones están en constante evolución y algo que funciona hoy puede no funcionar en un año.

Los números no nos ayudarán a llegar a una solución sino a detectar posibles mejoras, que pueden surgir de una implementación individual o de una serie de mejoras en conjunto.  La regla para implementar esas soluciones es que deben apelar al común denominador, o en otras palabras, a la mayoría general que hace uso de tus herramientas, páginas y aplicaciones.

La idea detrás de esta regla es que cuando se está diseñando una experiencia hay que considerar una gran cantidad de usuarios y casos (o situaciones) de uso. Los usuarios con diferentes motivaciones esperan realizar  tareas diversas, especialmente al interactuar con marcas o empresas que ofrecen muchos servicios.

Algunos usuarios sólo querrán consultar información, otros  realizar una compra o realizar tareas avanzadas, mientras nuestros clientes quieren publicar contenido que a sus consumidores generalmente no les interesa. UX nos ayuda a discernir cuál de esas audiencias debe ser el foco en el proceso de diseño y de las mejoras a implementar.

Si la información que disponemos de los usuarios indica que la mayoría de ellos visitan un sitio únicamente para consultar cierta información específica, entonces el sitio tiene que estar orientado a facilitar ese comportamiento, aunque no esté conectado directamente con las ventas. Esta regla tiene que ver con el concepto de “fricción”.

Atender las necesidades del común denominador con soluciones de UX significa también reducir la fricción para aquellos usuarios que quieran pasar de ser la mayoría a la minoría. Una buena implementación de UX permite que la mayoría de los usuarios, o el común denominador, cumplan la tarea que desean cumplir con la menor fricción posible, algo que podríamos denominar “felicidad” o “satisfacción”; bajo esos términos, un buen UX se enfoca en hacer ‘felices’ a la mayoría de los usuarios.

Por ejemplo: supongamos que hicimos una página para capturar registros, y llegan 100 visitas, de las que 10 dan clic en el botón para registrarse. De ellos, 5 completan el formulario de registro. Algunos diseñadores de experiencia de usuario se verían tentados a pensar que 50% de los usuarios interesados completaron el formulario (5 de los 10 usuarios que llegaron a él) y enfocarían sus esfuerzos de mejorar el formulario, ignorando el hecho de que 95% de los usuarios visitantes nunca uso el registro.

En este caso, el común denominador de esos 95 usuarios nos está dando una dirección muy específica sobre qué es lo que hay qué hacer:  no importa si 90% es un ‘Bounce Rate’ aceptable para un Landing Page, nuestras métricas, proporcionadas por la mayoría de la audiencia nos están diciendo que nuestra experiencia requiere mejoras. Un mejor objetivo sería mejorar la cantidad de personas que hacen clic en el botón de registro.

El común denominador dicta la prioridad de UX, y éste se obtiene de las métricas al alinearlas con el objetivo específico de la experiencia que se está diseñando.

No es que las minorías no cuenten, o que los usuarios avanzados o los que utilizan funciones secundarias no sean importantes, pero el diseño de UX requiere objetivos y métricas precisas. El común denominador nos sirve para asignar prioridades de recursos (tiempo, dinero, trabajo) y detectar los problemas a resolver.

Si todo el trabajo previo a la segmentación de audiencias para entender a nuestros usuarios se ha hecho correctamente, diseñar para el común denominador siempre será la decisión correcta. UX  trata de implementar mejoras para la mayoría de los usuarios, y no hay manera de lograr esas mejoras sin antes definir las métricas correctas, porque si no se puede medir, no es UX.

Trabaja como Planner en SCLBITS. Es curador de UX Mexico y parte del equipo de UX Nights.

La conexión entre SEO y UX

A pesar de que durante años “expertos” han pregonado soluciones mágicas para mejorar el posicionamiento de sitios web en los primeros lugares de los buscadores, actualmente el buen SEO es una consecuencia de un buena implementación de UX.

En mi artículo anterior expuse algunos temas que curiosamente coincidieron con  los que se abarcaron en el Vol. 9 de UX Nights sobre cómo el considerar las necesidades del cliente y sus objetivos de negocio en el diseño de UX y no únicamente centrarnos en los usuarios. También se discutieron en el evento los tres roles más prominentes en nuestra industria: el que paga, el que desarrolla y el que lo usa, así como su respectiva aportación al flujo de trabajo.

Apelar a las necesidades de la persona que nos paga y adaptándolas a la persona que las va a usar es, en mi experiencia, el método más eficiente para justificar la inversión en las diferentes disciplinas que abarca UX, pero hay varios beneficios adicionales para el bolsillo del que paga que puede ayudarnos a ponerle “la cereza al pastel”.

Muchos clientes han mencionando mucho en fechas recientes el término “SEO”.  Con los recientes cambios al algoritmo de Google (de los cuales advertí en una plática que hice de Mobile Advertising a finales del año pasado) el gigante de Mountain View advierte que penalizará con lugares desfavorables en sus rankings de resultados de búsqueda orgánica a las páginas web que no sean usables en dispositivos móviles. Súbitamente han comenzado a aparecer los “expertos” y “consultores” que aportan soluciones equivalentes a remedios mágicos para no descender en los resultados.

La manera en que Google ordena a las páginas en los resultados de su buscador es un misterio muy bien guardado. Sin embargo, la compañía ha brindado toda la información que se necesita saber y en ningún lado hablan de meta-etiquetas, de que tu página necesita tener un blog con cientos de artículos que intentan mencionar una palabra clave repetidamente o mucho menos se sugiere que hay alguna manera de engañar a los “robots” al analizar nuestro sitio para determinar a cuál query (petición) de búsqueda responde mejor.

Un buen SEO es simplemente una mezcla de una excelente experiencia de usuario y buenas prácticas de programación.

¿Qué es lo que Google califica realmente para determinar si un sitio pertenece a los primeros lugares de un ranking? Coloquémonos en la perspectiva del servicio: Google vive de mostrar anuncios, y para que Google sea rentable necesita un  tráfico enorme todos los días. Para recibir un tráfico enorme a pesar de tener anuncios, el buscador debe ser impecablemente eficaz en cada ocasión que se usa, y debe entender perfectamente lo que los usuarios están buscando sin importar la redacción, gramática, idioma o subtexto que ellos usen.

Google no se puede arriesgarse a mostrar como el “mejor resultado” de una búsqueda a un sitio tramposo que haya decidido spammear una sola palabra clave con la intención de atrapar a usuarios incautos. Google va a ofrecer como mejor resultado de búsqueda al sitio que conteste de mejor manera la necesidad del usuario. Ese sitio debe ser rápido, eficiente, ligero y fácil de usar para calificar en estos criterios,  para que el usuario termine satisfecho con su resultado y siga considerando a Google como algo impecable, que parece que viene de otro planeta.

Google menciona en sus manuales de buenas prácticas de manera muy específica que en la “vieja escuela” el SEO era para las máquinas, pero esta es una idea obsoleta; los desarrolladores web tienen que preocuparse actualmente de una sola cosa: sus usuarios.

Es con este argumento -aunque no es que los argumentos escaseen- que podemos reforzar la necesidad de hacer con un sitio impecable desde la perspectiva de los usuarios para que nuestros clientes puedan ofrecer beneficios a sus usuarios que se traduzcan en ganancias, como es en este caso un mejor posicionamiento en buscadores y una mayor relevancia con las palabras relacionadas a su negocio. De esta manera podemos argumentar en favor de que nuestros proyectos se realicen y concreten de manera exitosa.

Referencias:

Para saber más de SEO pueden consultar la guía introductoria del tema elaborada por el mismo Google.

Trabaja como Planner en SCLBITS. Es curador de UX Mexico y parte del equipo de UX Nights.

El Dueño de la Experiencia de Usuario

Crear productos con buena experiencia de usuario requiere de un equipo con personas que tienen enfoques y habilidades muy diferentes. ¿Quién de ellos es el dueño de la UX?

El trabajo de desarrollo de tecnología dejó de ser desde hace mucho la tarea de una sola persona; los días del “webmaster” o del “hacker solitario” quedaron atrás como anécdotas de los tiempos en que la responsabilidad de programar, diseñar, crear contenido, asegurar la infraestructura, llevar a producción y dar a conocer un producto de tecnología era trabajo de una persona.

Los productos que sobresalen en el mercado casi siempre son creados por equipos de profesionales con habilidades y conocimientos diferentes, como en “The Avengers“, diría Adrián Solca:

El objetivo de tener un equipo es que el talento total compense las deficiencias individuales.

Un equipo multidisciplinario debe superar primero el impulso de sus miembros de trabajar únicamente orientados por requerimientos u objetivos personales. El primer reto es aceptar de que cada persona en el equipo, al tener diferente formación, tiene también formas diferentes de pensar, de comunicarse y de resolver problemas; usa herramientas diferentes que los demás y tiene objetivos personales diferentes también.

Trabajar enfocado en el beneficio del usuario sirve para centrar la atención de todos en el mismo tema y para unificar las visiones y objetivos de trabajo. Si el éxito del equipo depende del éxito del usuario final, entonces todos tiene un gran incentivo para crear la mejor experiencia de usuario posible.

La pregunta que surge en este punto es: ¿quién en el equipo es el responsable de la implementación correcta de UX?

La respuesta común es “todos son responsables“, pero esta respuesta tiene una trampa: cuando la responsabilidad es todos, en realidad nadie es 100% responsable. Los miembros de equipos con poca integración se pasan la responsabilidad entre ellos tratando de evitarla, lo que diluye el compromiso hacia el usuario y afecta el diseño final de la experiencia.

Es importante señalar en este punto que tampoco se trata de generar una “área de UX” que se responsabilice de la implementación de las buenas practicas del diseño centrado en el usuario. Una área que sólo tenga esa tarea como objetivo y trabaje de manera aislada de los equipos de producción solo volverá el proceso lento y burocrático, alienando a los demás.

En un buen equipo de UX no hay un “dueño”, pero si debe de haber un líder, un “campeón” que debe tomar dos roles adicionales a su contribución al equipo: primero, debe ser el representante del usuario, alguien que vele por los intereses de los usuarios finales y que le recuerde constantemente al equipo que el usuario es lo más importante; y segundo, debe de asumir el rol de facilitador para los otros miembros del equipo puedan conocer, entender los procesos, recomendaciones y mejores prácticas sobre UX.

Sobra decirlo, ser el “campeón” de UX en un equipo de trabajo no es sencillo. La persona que asuma ese rol deberá ser una persona que pueda trabajar con otros y comunicarse con ellos de manera puntual y eficiente, que pueda ganarse su confianza por medio mérito y no por un puesto o por pose.

En muchos sentidos, este “campeón” de UX refleja mucho el rol de un SCRUM Master en un proceso ágil pero con un giro: su principal preocupación no es el producto, sino el usuario final. Puede ser desarrollador, diseñador, project manager, el mismo CEO o alguien más. No necesita tampoco ser la misma persona todo el tiempo o en cada proyecto, o siquiera un “experto” en el tema. Es más: puede que sea una persona que trabaja fuera de la empresa, ¡o incluso un cliente!

Lo que es cierto es que cada equipo necesita a alguien que peleé por el usuario (¡como TRON!), pero no contra sus compañeros de trabajo. Si esta persona logra convencer a sus colegas que el usuario es lo más importante en el desarrollo de tecnología y los ayuda a trabajar en ese sentido, el resultado serán siempre productos increíbles y memorables.

Consultor en experiencia de usuario, developer, conferencista, escritor y emprendedor. Trabaja en Tesseract Space, es Google Expert en UX/UI, Microsoft Regional Director y co-fundador de UX Nights.

Vendiendo Experiencia de Usuario

Cuando se planea el diseño de un producto con “una buena UX” se habla mucho del usuario final, pero ¿quién representa a los que pagan por ese diseño? ¿Cuál es la mejor manera para alinear los objetivos de nuestros clientes con los de sus usuarios?

Se ha discutido mucho acerca de qué es y qué no es Diseño de Experiencia de Usuario. Todos los días personas de muy diferentes disciplinas, perfiles y niveles de experiencia se suman a sus filas interesadas en esta industria. Lo único que nos une a todos es que trabajamos es crear productos que brinden experiencias satisfactorias y funcionales a nuestros usuarios.

Me parece que el diseño de UX es un trabajo noble y desinteresado. En mi caso probablemente nunca voy a utilizar muchos de los productos que me han tocado estructurar, pero está bien porque esto no lo hacemos por beneficio propio, sino porque los usuarios merecen tener una mejor experiencia en cualquier aplicación, página, dispositivo o producto con el que tengan contacto.

En mis años de experiencia trabajando en publicidad me he encontrado, sin embargo, con una fila interminable de clientes que no comparten este gusto desinteresado por hacer de internet un mejor lugar. En algunos casos parecen más interesados en lo contrario. He conocido clientes que colocan tantos campos como les es posible en una página para que el usuario se harte y deje todos los valores del formulario por default para cobrarles de más a sus usuarios.

Son verdaderas historias de terror.

Cómo Diseñadores de Experiencia de Usuario tenemos la capacidad de conocer a fondo nuestros usuarios: los entrevistamos, encuestamos, analizamos y observamos para determinar cuáles son sus necesidades específicas. Nuestro súper poder mutante es ponernos en los zapatos de perfiles diferentes a los nuestros. El objetivo de este artículo, colegas, es el de hacerles ver que esto no solo debemos  hacerlo con nuestros usuarios, también tenemos que hacerlo con nuestros clientes.

Realidad vs Ficción

En todos los proyectos hay al menos tres roles: el que paga por el proyecto, el que hace el proyecto y el que usa el proyecto: stakeholders, product owners y los usuarios. Éstos pueden ser uno o varios, personas o empresas; en realidad eso no importa,  sino las tareas que realizan para que el proyecto tenga éxito. El flujo de la gestión del proyecto debería funcionar así:

  • El que paga el proyecto le pide al que desarrolla el proyecto que haga algo para que alguien lo use.
  • El que desarrolla el proyecto entrevista al que lo usa, arma una propuesta y se la enseña al que paga el proyecto
  • Al haber sido una propuesta desarrollada en conjunto con el que lo usará, será una propuesta exitosa.

Lo que sucede en realidad es esto:

  • El que paga por el proyecto le dice al que lo va a desarrollar (con diferentes niveles de detalle) lo que quiere ver
  • Éste a su vez lo verifica con el usuario, le hace modificaciones o mejoras, creando un mejor producto.
  • El que lo desarrolla se lo muestra al que lo paga
  • El que lo paga dice “eso no es lo que te pedí
  • El que desarrolla dice “sí, pero esto le gusta más al que lo usa
  • El que lo paga dice: “conozco a alguien sí puede hacer lo que le pedí

El resultado es que:

  • El que lo paga lanza un producto que no sirve para nada
  • El que lo desarrolla muere un poco por dentro ahogado en lágrimas
  • El que lo usa acaba frustrado por tener en sus manos un producto que en sus palabras “tiene una pésima usabilidad.

Es triste, lo sé. Vivimos en un mundo de supuestos y de “deberían ser”, muy diferentes de la realidad. Luego nos preguntamos por qué las cosas no cambian.

La solución

Aquí es donde viene lo que más disfruto de mi trabajo. *Redoble, por favor*:

Desarrollar un producto increíble para nuestros usuarios es solo la mitad del camino. la otra mitad es saber cómo venderlo a los stakeholders.

En mi experiencia, los que pagan por el proyecto generalmente piden lo que ‘creen’ que quieren, pero detrás de sus peticiones siempre hay necesidades que es nuestra obligación entender. Un proyecto exitoso no radica solo en cumplir la expectativa de experiencia del usuario, sino también la expectativa de resultados para nuestros clientes.

Una frase que debería ya ser un mantra de la industria es que “la usabilidad no es el fin, es un medio para alcanzar los objetivos de un proyecto de una mejor manera”. Los clientes no vienen a nosotros para que les hagamos un “sitio más bonito”, vienen a nosotros porque saben que un sitio bien diseñado les ofrece mejor conversión (o lo que sea que hayan leído en Merca2.0 que ya los hace expertos en tecnología).

No tengo una guía predefinida para entender a mis clientes, pero con el fin de echarles la mano, mis queridos lectores, he armado una lista de preguntas básicas que todo UX debe preguntarle a su stakeholder para obtener información vital a la hora de armar una propuesta:

1. ¿En qué área trabaja la persona que te está solicitando el proyecto? 

Esto es importante porque determina las métricas por las que sus jefes la van a calificar. Si es de mercadotecnia seguramente será una métrica de Costo vs Indicadores (top of mind, impresiones, awareness o número de personas que verá el mensaje). Si es un área de CRM (el área que normalmente maneja programas de lealtad y retención de clientes, así como la minería de sus datos) lo medirán por cuánto ganan en promedio por cada usuario registrado.

Si es de sistemas tendrá otras métricas como Estadísticas de tráfico o de Optimización de recursos. Lo más probable es que sin importar el área, los clientes esperan mayor “bang for their buck” (valor por su dinero). Lo que cambia es lo que cada cliente considera cómo “valor”.

2. ¿Cuál es el modelo de negocio de la empresa? 

A lo mejor tienen un servicio gratis en el que venden espacios publicitarios. Si tu propuesta es “quitar los banners” en vez de ofrecer una manera de garantizar que más gente los vea, puedes decirle adiós al proyecto.

Con las aerolíneas, por ejemplo, no se trata de solo vender el boleto de avión sino de que la gente compre extras (mejor asiento, comida, etc.) ¿Cómo es que tu propuesta o solución ayuda a mejorar la conversión de tu cliente?

3. ¿Cuál es la realidad tecnológica de la empresa? 

Sí, tu propuesta revolucionaria de e-commerce es brillante, pero el cliente no tiene una bodega centralizada para la distribución de sus productos, o te enfrentas a mi peor pesadilla: las franquicias, las que el cliente no tiene control de la experiencia final del producto, sino que ésta la determinan otros personajes que pueden hacer lo que se les pegue la gana con el producto final.

O tal vez tu cliente no cuenta con la infraestructura para soportar una base de datos para que los usuarios que se registren para ofrecerles una experiencia personalizada. Posiblemente tu cliente no tiene idea de cuánto cuesta o cuánto tiempo toma desarrollar una app nativa. Una propuesta exitosa le ayuda al cliente a ahorrar dinero, no a gastar en soluciones costosas en las que encuentra valor.

Estas tres preguntas básicas deberían ayudarte a pintar un panorama general de qué  puedes hacer y qué definitivamente no deberías hacer. También es una guía sobre cómo venderle el proyecto a tus clientes: qué palabras utilices, el enfoque que le des a los resultados que entregará tu plataforma y cómo el proyecto hará de tu cliente una súper estrella dentro de su empresa o con sus colegas porque ofrecerá resultados increíbles.

Estrategias hay tantas como clientes, pero la moraleja de esta historia es que así como es cierto que no porque nos importe a nosotros le va a importar a nuestros usuarios, tampoco puede que le importe a los clientes; y que no porque nosotros queramos que una aplicación sea increíble, nuestros stakeholders compartirán la misma pasión.

Es nuestro deber cómo UXers entender las necesidades de los clientes y los usuarios para garantizar que un proyecto suceda como consideramos que es correcto. Somos nosotros, finalmente, los que tenemos todo para lograr que esto suceda.

Trabaja como Planner en SCLBITS. Es curador de UX Mexico y parte del equipo de UX Nights.