La toma de decisiones en la industria de las experiencias

La toma de decisiones es la función más importante de la gestión. Nunca antes fue tan difícil.

Este desafío ha sido terreno fértil para nuevas metodologías de trabajo, todas ellas prometiendo el éxito que escapa a las demás. Aunque útiles, todas comparten la misma limitación: una metodología de trabajo propone una forma de organizar personas y procesos. No reemplaza a las personas, ni a sus procesos de toma de decisiones.

Experience Decision Making (XDM) nace de reconocer esa pieza faltante. Integra y extiende elementos de teoría de la decisión, psicología cognitiva y principios de influencia y liderazgo, en un sistema consistente y aplicado en proyectos reales.

XDM permite encontrar respuestas a:

¿Cómo tomamos decisiones? ¿Estamos aplicando el proceso correcto? ¿Qué tipos de información necesitamos? ¿Qué declaraciones debemos hacer?

¿Cómo podemos administrar la complejidad y la incertidumbre?

¿Qué preguntas tenemos que hacernos para lograr proyectos exitosos?

¿Cómo podemos facilitar mejores procesos de toma de decisiones de nuestros superiores y clientes?

Conociendo los fundamentos de Experience Decision Making

Tomar decisiones, al igual que correr o respirar, es algo que todos somos capaces de hacer.

Pero de la misma manera en que buzos y deportistas profesionales estudian, entrenan y mejoran las funciones sobre las que se basa su actividad, quienes gestionamos, proyectamos y construimos experiencias, debemos entrenar nuestra capacidad de tomar mejores decisiones.

XDM es un sistema de modelos y métodos para lograr mejores procesos de toma de decisiones en la industria de las experiencias. Nuestra primer edición, “Experience Decision Making en 30 minutos”, presenta los modelos y conceptos fundamentales.

Los invitamos a obtener el eBook y empezar a desenredar las conversaciones de sus proyectos.

La entrada Presentando XDM: Experience Decision Making se publicó primero en Kambrica.

Cuando nos planteamos integrar Experiencia de Usuario y Metodologías Ágiles, el encuadre nos condiciona a pensar que una vez que identifiquemos el punto de encuentro, tendremos todas las respuestas que necesitamos.

Esto sería acertado y suficiente, si no hubiéramos tenido desencuentros antes de la aparición de las metodologías ágiles. Aplicaría si hubiéramos venido trabajando fenómeno hasta que en el año 2001 fuera publicado el Manifiesto Ágil; la realidad es un poco más compleja.

Las metodologías ágiles suelen ser propuestas o impuestas por el área de Ingeniería, y allí es cuando podemos ver que el universo “metodologías ágiles” está compuesto por dos dimensiones: Ingeniería y Gestión. La relación entre Diseño e Ingeniería viene siendo el marco del problema ya no antes del 2001, sino desde tiempos inmemoriales: arquitectos e ingenieros llevan siglos hablando mal unos de los otros.

El primer paso para lograr una convivencia sana, es resolver la relación entre Diseño e Ingeniería. Para eso, me gusta mucho esta definición que conocí por Bret Victor: “La tecnología satisface necesidades humanas, amplificando capacidades humanas”.

Esta definición resulta reveladora en varios aspectos. Primero que nada: Sin persona, no hay tecnología. En segundo lugar, permite entender que la Ingeniería se ocupa de los aspectos funcionales, los que se ajustan al problema… y el Diseño se ocupa de que lo que se proyecta, se adapte a la persona, habiendo entendido sus necesidades y capacidades. La tecnología no se limita a lo mecánico; no es algo que inventan los ingenieros y que los diseñadores coloreamos. Sin Diseño no hay tecnología: hay meras curiosidades técnicas.

Para incorporar Diseño al proceso, encuentro muy útiles las tres preguntas críticas: ¿Qué problema queremos resolverle…? ¿…a quién(es)? y ¿Cómo sabremos si lo logramos? Estas preguntas permiten integrar en una sola conversación a las tres áreas del problema: Ingeniería, Diseño y Gestión.

Cuando hablamos de Gestión, es bueno entender qué es una Metodología: un marco para organizar un proceso que involucra personas. Lo importante de esta definición es que nos revela lo que una Metodología no abarca.

Una metodología no reemplaza a las personas (involucradas en el proceso), las conversaciones (herramienta para compartir visión de futuro y coordinar acciones), ni a la toma de decisiones. Elegir una metodología es, de por sí, una decisión. 

Una metodología no puede prescribir decisiones, de la misma manera en que las reglas de tránsito (ej. “circular por la derecha”) no pueden dictarnos a dónde ir: sólo nos pueden ofrecer la organización necesaria para llegar a destino reduciendo el riesgo de accidentes.

La toma de decisiones es una parte fundamental del Diseño, y el mayor valor que aporta al proceso. Es frecuente que quienes nos contratan, consideren al Diseño sólo en cuanto a la ejecución de Diseño, esto es, hacer “bonitas” las decisiones de diseño tomadas previamente por Ingeniería y Negocio (sin siquiera ser conscientes de qué es una decisión de diseño).

Nos corresponde a los diseñadores marcar las distinciones correctas, proponiendo y cumpliendo la promesa de ayudar a Ingeniería y Negocio a tomar mejores decisiones.

Nos corresponde a los diseñadores marcar las distinciones correctas, proponiendo y cumpliendo la promesa de ayudar a Ingeniería y Negocio a tomar mejores decisiones, al punto que las decisiones de Diseño pueden alimentar a las decisiones de Negocio en las cuales deben basarse.

Cuando se considera al diseño como la mera ejecución, pareciera ser que un proyecto puede considerarse más o menos complejo por la “cantidad de pantallas” a producir – o cualquier otro entregable que pueda ser cuantificado.

Lo que encontramos en Kambrica trabajando sobre este problema, es que la complejidad del Diseño se puede entender de manera más apropiada como producto de la complejidad de la ejecución por la complejidad de las decisiones. Este modelo nos permite mostrar más claramente el rol necesario de UX en facilitar los procesos de toma de decisiones de los stakeholders, y brindar información para que resulten basados en evidencia.

Otra distinción importante hace al uso vulgar del término Ágil. Particularmente de parte del Negocio, se expresa interés en adoptar metodologías ágiles por la idea de lograr rapidez.

La realidad es que la rapidez no forma parte de los postulados del manifiesto ágil: lo que proponen es respuesta ante el cambio en lugar de aferrarse a un plan. En otras palabras, ágil es el esquiador que esquiva los obstáculos y llega a la meta; apurado, es el que llega al hospital.

El esquiador apurado se arroja a la meta en un acto de fe, impelido por la ansiedad. El esquiador ágil considera las evidencias del terreno en su constante proceso de toma de decisiones: un ciclo de observación, orientación, decisión y acción.

En un proyecto, la investigación UX es lo que permite información para toma de decisiones basada en evidencia. Sin embargo, suele ser desestimada con el pretexto de que “es lenta”, que es otra forma de decir “no hay tiempo”. Ahora bien: el tiempo no es algo que se almacena en cajón.

El tiempo es algo que se dispone. ¿Qué significa realmente “no hay tiempo”?
Supongamos que alguien va a un centro de esquí, pide unos esquíes y cuando el dependiente le pregunta cuánto calza, el cliente dice “no tengo tiempo de ponerme las botas, sólo quiero los esquíes”. Lo que quiere decir, es que no entiende las botas como condición necesaria para usar los esquíes.

Los profesionales de UX tenemos que aprender a escuchar “no tengo tiempo” no como una negativa inflexible, sino como una invitación a señalar la condición necesaria entre nuestra propuesta y lo que nuestro cliente necesita.

En el proceso de decisión de nuestro cliente, hay una balanza con dos bandejas: una, lo que no quiere, problemas presentes o futuros, sus miedos; y otra, lo que quiere, el futuro del cual quiere ser parte, su deseo.

Atender a las preocupaciones es crítico para lograr atención: todo lo que propongamos antes de haber satisfecho ese punto, será ignorado o malinterpretado, al punto que en lugar de ser entendido como parte de la solución, puede ser considerado como problemas adicionales recargando la bandeja del miedo.

Este enfoque permite resolver el  habitual pedido de técnicas cuantitativas, aún cuando encontremos que aporten poco y nada al entendimiento y resolución del problema. La razón de este pedido es que los clientes que lo enuncian, necesitan algo para presentar a sus superiores: se los mide. La mayor preocupación de estos interlocutores no está alineada a la calidad del diseño: está enfocada en su supervivencia en la organización.

En estos casos, la investigación cuantitativa debe ser presentada como condición necesaria para lograr una cuantificación que a nuestros clientes les resulte positiva. Esto es, reconocer las métricas que puedan mostrar con medidas crecientes a lo largo del proyecto.Distingo en la investigación cuantitativa tres niveles:

• Validación (comprobar lo que “sabemos que sabemos”) es el proceso cualitativo más simple, menos riesgoso, y sobre el cual es más factible establecer métricas cuantitativas.
• Investigación (ir a buscar lo que “sabemos que no sabemos”) representa mayor incertidumbre y sólo es viable una vez que nuestro cliente ha podido entender el valor de UX en reducir riesgos, típicamente luego de la validación de supuestos que se presentaban originalmente como verdades.
• Exploración (ir a buscar lo que no sabemos que no sabemos) es el proceso cualitativo más alejado de la preocupación del cliente por su supervivencia en la organización; sólo es viable cuando nuestro cliente dispone de recursos, capital político, experiencia y compromiso.

Recién con herramientas sólidas para las conversaciones y la toma de decisiones, podemos abocarnos a diseñar una metodología.

Lo más importante que toda metodología busca lograr, es lograr en la escala del proyecto una relación sana cliente-proveedor. Sin metodología alguna, a medida que se suma gente de ambos lados, se producen conversaciones cruzadas, confusiones y problemas que llevan a la formación de dos bandos: “esos cretinos” y “esa manga de inútiles”.

Por eso, toda metodología plantea un solo interlocutor de cada lado, contando con autoridad, competencia técnica, entendimiento de Negocio y competencias de gestión.

Una base muy importante para las metodologías ágiles es la distinción de Valor vs. Desperdicio propia de la filosofía “Lean”. Valor es lo que el Cliente valora; desperdicio, es todo lo demás… aún cosas que consideramos condiciones necesarias para lograr Valor.

Identificar el desperdicio obliga a cuestionarse todas las actividades que se realizan. En el caso de la construcción de una vivienda, las paredes –que permiten proteger a los habitantes de la intemperie y preservar su privacidad– son claramente un Valor. Ahora bien, los andamios, por más que se consideren necesarios para la construcción de esas paredes, son en realidad desperdicio constructivo: los habitantes no convivirán con los andamios una vez inaugurado el edificio. Si los andamios fueran de oro, el presupuesto crecería en varios millones de dólares, sin que los clientes finales encuentren Valor en ello. Por eso, los andamios son modulares, reutilizables, y en muchos casos, se alquilan.

Otros tipos de desperdicio pueden ser más claros de identificar. Si en lugar de descargar los materiales en el punto donde se los necesita, se los descarga a 10 cuadras de distancia, será necesario tiempo y esfuerzo adicionales para desplazarlos a donde deberían haber sido descargados en primer lugar.

Identificar el desperdicio en software resulta mucho más difícil. Lean Software Development es una herramienta muy valiosa para identificar, reducir y eliminar en nuestros proyectos:
Desperdicios en el producto:
Son los más claros… y también los más tardíos en poder ser identificados. Resultan evidentes una vez que el proyecto ha salido a producción… y por ello, cuando ya no hay recursos para resolverlos. El proceso de investigación UX busca, en un entorno controlado, identificar estos desperdicios de manera económica, cuando todavía hay tiempo y recursos para mitigarlos:

• Defectos: bugs, cosas que no funcionan de acuerdo a la expectativa del usuario final, problemas de usabilidad.
• Funcionalidad no usada: típicamente, producto de falta de entendimiento de las necesidades y capacidades reales de los usuarios.

Desperdicios en el proceso:
Pueden ser identificados y resueltos durante el proceso mismo. Atenderlos reduce la posibilidad de manifestación de desperdicios en el producto. Requieren de competencias de gestión, responsabilidad del equipo, y manejo de expectativas del Cliente.

• Pase de manos: cuando una tarea pasa de una persona a otra, hay o bien una conversación necesaria entre esas personas, o información que se pierde en el proceso.
• Multitarea: el ser humano puede realizar una sola tarea de forma consciente; la “multitarea” resulta en realidad, intercalar fragmentos de dos o más tareas. Pasar de la tarea A a la tarea B, requiere de un esfuerzo mayor a cero para entender el contexto de la segunda tarea; esa penalización de aplica nuevamente al retomar la tarea A.
• Reaprendizaje: retomar una tarea o práctica al cabo de mucho tiempo, requiere de un esfuerzo para recuperar el contexto y capacidad operativa, que se puede evitar manteniendo continuidad.
• Esperas: ocurren cuando una persona no puede avanzar con sus tareas asignadas por no contar con decisiones o insumos de los que depende. Una forma de evitar estas situaciones es manejando un cronograma de “sprints” que impone cadencia al proyecto, y que debe involucrar al Cliente.
• Trabajo incompleto: todas las decisiones y ejecuciones no finalizadas, aumentan la deuda técnica al punto en que el día de mañana, el costo para saldarla puede resultar inviable. Suele ser producto de apuro y presión sobre el proyecto, falta de planificación y visión.
• Talento no utilizado: uno de los casos usuales es cuando el Cliente considera al Diseño como mera ejecución, desatendiendo la capacidad del equipo de ayudar al Negocio a tomar mejores decisiones. Requiere de gestión, autoridad, manejo de expectativas y compromisos. Impacta al proyecto de maneras no cuantificables (nadie puede medir contra lo que “podría haber sido”), y al equipo en quiebres de motivación.

Desde Kambrica desarrollamos, iteramos y proponemos un modelo que en primer lugar, reconoce el valor de los procesos de Facilitación e Investigación para reducir la complejidad de la toma de decisiones. Y revela que la ejecución de diseño, lejos de “resolver” (como suele ser la percepción del cliente), en realidad siempre abren nuevas preguntas que requieren de procesos adecuados para su resolución.

Nuestro modelo mínimo de sprint considera ciclos semanales, con un track de Gestión adelantado una semana al track de ejecución. En el momento de Planificación, se empalman los dos tracks, considerando además una instancia de seguimiento con Negocio a mediados de la semana de ejecución para reducir riesgos y desvíos.

Aplicando este modelo logramos coordinar todos los proyectos, sin importar su complejidad.

En resumen, integrar Experiencia de Usuario y metodologías ágiles requiere trabajar sobre varias dimensiones, de general a particular: desde el entendimiento de Diseño, Ingeniería y Gestión, hasta el diseño y aplicación de una metodología particular para encaminar los proyectos identificando y reduciendo los desperdicios, estableciendo y cumpliendo compromisos de manera responsable.
 

La Medida del Diseño 2018: Métodos lentos en tiempos ágiles – IxDA Viña del Mar

El evento contó con Mauricio Azócar (Coach Ágil en Tinet), Estefanía Cotrini (Jefa de proyectos en Ilógica) y Santiago Bustelo (Fundador y Director de UX en Kambrica).

La industria del diseño de servicios digitales se basa cada día más en el uso de metodologías ágiles, las que han traído consigo nuevas formas de trabajo, con otros ritmos y metas que han demostrado aportar en eficiencia y transparencia en los procesos de diseño y desarrollo. Sin embargo, muchas de las metodologías ágiles como Scrum, Agile o Lean han sido creadas desde el desarrollo y, por lo tanto, no consideran en sus definiciones iniciales la relevancia del rol del diseño para la experiencia, sus equipos ni sus métodos.

En este contexto, IxDA Viña del Mar levantó las preguntas ¿Cuál es el rol de los “métodos lentos” propios de DCU e investigación en los tiempos ágiles en que nos encontramos?, ¿Cómo se hace cargo cada tipo de metodología de la experiencia de usuario?, ¿Qué factores externos, humanos o de otro tipo, favorecen o dificultan el desarrollo de procesos bajo cada metodología?

¡Muchísimas gracias a Nicolás Espinoza, Katherine Exss y a todo el equipo y voluntarios de IxDA Viña del Mar por la invitación, la excelente recepción y el esfuerzo por hacer todo posible!

Créditos de la Presentación

• Framing hammer – Luigi Zanasi (CC BY-SA 2.0 ca)
• Iceberg in the Arctic with its underside exposed – AWeith (CC BY-SA 4.0)

Todas las demás imágenes y videos bajo Licencia CC0 (Libres para todo uso sin atribución requerida), de dominio público o producción propia.

¿Querés proyectar tu UX Seniority?

¡Nuevo curso!

Seniority UX: Llevá tu carrera a otro nivel

Un curso para entender qué necesitás para proyectarte como UX Senior, y cómo lograrlo.

Conocé el temario y sumate!

La entrada Las metodologías ágiles como problema de Diseño se publicó primero en Kambrica.

Suele ocurrir que el Negocio contrate a diseñadores para “diseñar”, y las dos partes crean que están hablando de lo mismo… pero en realidad, el Negocio no esté esperando que los diseñadores tomen decisiones de diseño. Sino, que ejecuten las decisiones de diseño que el negocio ya tomó antes de llamar a los diseñadores.

En otras palabras, “que lo haga lindo”.

Este tipo de malentendidos resultan no sólo en frustraciones para todos los involucrados, sino en diversas formas de desperdicio (entendido bajo la filosofía Lean): idas y vueltas, sobreprocesamiento, defectos y talento desperdiciado.

Cuando en Kambrica empezamos a aplicar la distinción entre ejecución y decisiones de diseño, encontramos el espacio para poder trabajar esas decisiones junto con el Negocio. También fuimos descubriendo y trabajando en nuestros proyectos dos niveles más, que hoy forman parte de nuestra filosofía de consultoría UX: las decisiones de Negocio, y los valores de la Organización.

Cuando las decisiones de diseño no están soportadas en decisiones de Negocio, quedan sujetas a la arbitrariedad, al cambio de parecer y a la revisión constante por parte de todos los involucrados. Síntomas comunes son que el diseño “no cierra”, a algún stakeholder “no le parece”. Siempre en esos casos queda la duda de si no se podría haber hecho otra cosa. No necesariamente mejor… sino distinta. Una situación que resulta inevitable si la expectativa del Negocio, es que el diseño lo sorprenda. Porque la sorpresa del diseño que se presenta, dura tan sólo unos instantes. Luego del primer golpe de vista, empiezan a brotar preguntas y pedidos, que derrumban las bases de las decisiones que se habían tomado hasta ese momento.

Esta pérdida de foco se reduce enormemente cuando las decisiones de diseño, responden a decisiones de Negocio. Éstas decisiones tienen forma de objetivos: qué queremos lograr con el proyecto. O dicho en términos de diseño: ¿qué problema queremos resolverle, a quién, y cómo sabremos si lo logramos?

A veces, el diseño lleva a cuestionar decisiones de Negocio: eso no sólo es válido, sino que resulta para nosotros una expresión de “design thinking” mucho más profunda y madura que tan sólo una pared tapizada de post-its.

Pero encontramos que con eso no es suficiente. Diseñar la Experiencia de Usuario, requiere tomar decisiones sobre qué experiencia queremos brindarles a esos usuarios y en última instancia, cómo queremos tratarlos. Esas decisiones también resultan arbitrarias, y deben estar expresadas en los valores de la organización. Sin valores de la organización alineados a UX, el Negocio puede perder la dirección y considerar decisiones que podrían perjudicar la relación con sus usuarios y clientes.

Pocas organizaciones tienen declaraciones de Visión y Misión que describan cómo la organización se propone tratar a sus clientes. Pero esas declaraciones, aún incompletas, son siempre son el mejor punto de partida para lograr esas definiciones.

Nuestra Jerarquía de decisiones UX tiene forma de pirámide, representando que cada nivel debe estar soportado en los anteriores. “UX” en la punta, representa el hecho de que si bien la ejecución del diseño será el punto de contacto de los usuarios con la marca, en realidad la Experiencia de los Usuarios es la consecuencia de las decisiones de todos los involucrados en el proceso.

Cuando las decisiones de diseño no están soportadas en decisiones de Negocio, quedan sujetas a la arbitrariedad, al cambio de parecer y a la revisión constante por parte de todos los involucrados.

La entrada Jerarquía de decisiones UX se publicó primero en Kambrica.

Áreas de trabajo

• Capacitación
• Mentoría
• Metodologías ágiles

Resultados

Como resultado de nuestro programa de capacitación, Technisys formó su equipo de UX propio, se mejoró la integración de los equipos y procesos, y se logró la adopción de herramientas de diseño centrado en el usuario por parte de la compañía y clientes.


Con la incorporación de UX logramos aportar valor a nuestros clientes. UX es hoy un factor diferencial de nuestras soluciones.

Miguel Santos, CEO Technisys

La entrada Technisys se publicó primero en Kambrica.

El proceso de diseño se trata de abrir alternativas válidas, generar nuevas preguntas, podar el árbol de posibilidades y volver a iterar… hasta llegar a una respuesta capaz de satisfacer la expectativa con la que se inició el proceso de diseño.

Al igual que dominar un idioma, o aprender a tocar el piano, la formación en diseño se trata de incorporar una práctica, no de la acumulación de información. Esta distinción resulta fundamental para evaluar adecuadamente cualquier tipo de formación en UX. 
A continuación, algunos aspectos que ayudarán a aclarar qué se puede esperar y qué no de un curso de UX.

¿Qué es aprender a diseñar?

En ningún curso de UX, sea cual fuere su extensión, se pueden aprender todas las respuestas concretas para tener a la mano ante cada situación que se pueda presentar. Ello no se debe a falencias particulares del curso, sino a que no es ésa la naturaleza de UX – o del diseño en general. 
Diseñar no es la capacidad de aplicar soluciones conocidas en respuesta a un requerimiento. Diseñar es la capacidad de idear y ejecutar buenas soluciones en respuesta a problemas particulares, de carácter complejo, y por ello formulados inicialmente de manera incompleta o simplemente errónea.
Por ello, diseñar es:

• una práctica: la visión y capacidad para idear y ejecutar buenas decisiones surgen de la experiencia validada, no de la mera adquisición de información;
• un proceso: llegar a una buena solución requiere desarrollar no una, sino varias alternativas, que a su vez llevarán a preguntas que no se habían considerado previamente.

El proceso de diseño se trata de abrir alternativas válidas, generar nuevas preguntas, podar el árbol de posibilidades y volver a iterar… hasta llegar a una respuesta capaz de satisfacer la expectativa con la que se inició el proceso de diseño. Lo que se puede aprender en un curso de UX no son las “respuestas correctas”, sino el universo en el cual se pueden formular preguntas de diseño, cómo desarrollar respuestas y someterlas a validación.

Por ello, el valor de un curso de UX no está en las “certezas” que promete, sino en las preguntas que sus alumnos puedan realizar y ser capaces de responder después de haberlo concluido. 

Aprender a diseñar: algo que un curso de UX puede iniciar, pero nunca completar

En disciplinas creativas, la información ayuda a ganar estructura, tiempo y claridad. Pero atiborrarse de información no es buena idea: en UX, como en cualquier disciplina creativa, es necesario un balance entre el saber y la práctica. Cuando el saber supera ampliamente a la práctica, resultan diseñadores frustrados por no poder ejecutar sus ideas. O críticos implacables, capaces de demoler cualquier propuesta y la moral de todo un equipo. 

Por eso, un buen curso de UX debe ayudar a aclarar, a abrir puertas, a ver posibilidades a la medida de los alumnos… que deberán ser exploradas y desarrolladas en la práctica profesional.

Siempre comento a mis alumnos que me siento satisfecho con dejarles puertas para abrir cuyo sentido irán encontrando con el tiempo, a medida vayan diseñando su propia carrera y construyendo su propia visión.

Creo que es intelectualmente deshonesto ofrecer y prometer otra cosa a la hora de ofrecer capacitación en cualquier disciplina de diseño.

Porque es la práctica (algunos dicen que 10.000 horas) la que lleva a la maestría. Porque la formación en disciplinas creativas implica un desarrollo y transformación de la persona que no puede ocurrir en unos pocos meses o años.

Porque la idea de una escuela o universidad como “fábrica” que toma como insumo estudiantes y produce profesionales formados al final de una línea de montaje, sólo puede ser fruto del anacronismo, estándares bajos, y/o publicidad engañosa.

Conclusión

¿Cuánto se puede aprender en un curso de UX? Si la medida es, “respuestas para tener en el bolsillo”, pues más bien poco o nada. Si la medida es, “la capacidad de ver más allá, de identificar problemas que no sabía que tenía, de poder darles respuestas mejores a las que tenemos hoy”… hay un mundo por delante.

Todo problema complejo tiene soluciones simples rápidas y erróneas. Si entendés tu carrera como un problema complejo que merece un buen proceso de diseño, nuestra propuesta de formación profesional es para vos.

Santiago Bustelo

La entrada ¿Cuánto se puede aprender en un curso de UX? se publicó primero en Kambrica.

En 2010 el banco Santander Río necesitaba migrar la solicitud de sus productos del canal físico al online. Hasta ese momento el pedido de tarjetas de crédito era un trámite que muy pocos clientes estaban dispuestos a realizar de forma online.

Los motivos: escasa confianza en el canal online y formularios que requerían datos que los usuarios no comprendían o no estaban dispuestos a completar.

Áreas de trabajo

Rediseñamos todos los formularios de contratación siguiendo buenas prácticas de usabilidad y accesibilidad.

• UX Research para evaluar los procesos existentes, motivaciones e intereses de los usuarios, oportunidades y áreas de mejora.
• Rediseño del proceso de contratación de tarjetas y paquetes bancarios siguiendo mejores prácticas de persuasión, usabilidad, accesibilidad y diseño responsive.
• Rediseño de sistemas internos de Gestión del Conocimiento
• Realizamos entrevistas con el Call Center para conocer mejores prácticas de venta, aplicadas a procesos de upselling.

La entrada Santander Río se publicó primero en Kambrica.

En parte, esto ocurre porque diseñadores y desarrolladores tienen diferentes procesos y metodologías de trabajo y les falta un lenguaje compartido. Pero dado que necesitan trabajar en conjunto para lograr objetivos comunes, es importante encontrar una forma para que esta integración sea posible.

Pero dado que necesitan trabajar en conjunto para lograr objetivos comunes, es importante encontrar una forma para que esta integración sea posible.

Como parte de su tesis doctoral, Andrés Rodríguez propuso un modelo donde compara y equipara los roles de IT con los roles de UX en el marco de metodologías de desarrollo RUP, para generar una visión compartida entre ambas disciplinas.

A continuación, un resumen del modelo, basado en la Metodología RUP de IBM (Rational Unified Process):

Brevemente, la metodología RUP a pesar de ser un proceso dogmático, no es lineal sino que establece iteraciones, vueltas y pivoteo. Combina elementos de metodologías estructuradas y metodologías ágiles, y asegura que hay pasos pero no todos son secuenciales.  

Lo primero que Andrés Rodríguez resaltó como una problemática fue ver qué roles existen dentro de esta metodología y a qué nivel son comparables con los de UX. Así, desarrolló las siguientes comparaciones:

Stakeholders: están, en cierta forma, fuera del proceso. Es el cliente, el dueño del proyecto y puede ser:

• Patrocinador o sponsor: es la persona que le da apoyo político o económico al proyecto. Suele ser una sola persona que en caso de caerse u oponerse al proceso el proyecto se interrumpe. Por eso es importante definir claramente quién es el patrocinador del sponsor.
• Líder técnico del dominio: es la persona o comité que tiene conocimiento no tecnológico sino técnico del área de dominio.
• Representante del usuario: es el responsable pero no es quién ejecuta. Si solamente nos quedáramos con su postura, probablemente estaríamos presentando un “cuello de botella” al que el usuario se enfrentaría al hacer las cosas.
• Usuario final: el responsable de la ejecución. Es quién lleva a la práctica el hacer. Muchas veces, al llevar a la práctica el proyecto, se saltea muchos pasos que le resultan molestos por cuestiones productivas. Estos pasos son los que el Representante del usuario probablemente no haya tenido en cuenta.

Analista vs Especialista UX:  

IT: Analista (arquitecto de software)

Toma las decisiones que minimizan riesgos y aseguran la calidad del proyecto. Necesita experiencia que le den la capacidad de tener una visión a largo plazo. A su vez, es capaz de establecer una serie de prácticas en el equipo que permiten que la documentación no solamente funcione sino que, además, sea útil. 

Diseño: Especialista de UX (líder de UX, experto de UX)

Toma decisiones experiencia del usuario (UX), que, por definición, tienen impacto a largo plazo sobre la aplicación. Estas decisiones deben ser compartidas obligatoriamente con el Arquitecto ya que si no están sostenidas estructuralmente afectan el tipo de producto que se va a construir.

La responsabilidad de ambos en el proyecto es muy grande ya que toman decisiones estructurales que luego son muy difíciles y costosas de cambiar.

Desarrollador vs Diseñador de UX: 

IT: Desarrollador (programador)

Es quien tiene a cargo la ejecución. Toma decisiones de menor escala que el Analista. Tiene una visión de futuro más cercana.

Diseño: Diseñador de UX

Implementa experiencia del usuario diseñando los componentes de la interacción, los storyboards, prototipos, navegación, arquitectura de la información.

Ambos perfiles son responsables de darle forma concreta a la visión establecida en la etapa anterior.

Tester vs Tester de UX:

IT: Tester

Verifica que no haya errores, riesgos y vulnerabilidades que puedan presentarse y le hace una constante devolución al programador. La relación entre el tester y el programador es cíclica y se basa en el feedback.

Diseño: Tester de UX

Toma los diseños creados y lleva a cabo las pruebas de usabilidad verificando que los componentes desarrollados sean efectiblemente útiles y usables para el usuario final.

Es imprescindible que ambos trabajen en paralelo ya que el testeo se realiza sobre el producto en desarrollo.

La entrada UX & IT: un modelo para trabajar mejor se publicó primero en Kambrica.

Proyectos que se vuelven interminables, clientes insatisfechos y productos finales con los que el equipo no se siente orgulloso, son problemas comunes a muchos proyectos de diseño. No sólo son problemas evitables, sino que en los últimos años han surgido, desde la ingeniería industrial e ingeniería de software, definiciones y herramientas que resultan aplicables a todas las disciplinas de diseño.

En esta presentación se verán conceptos fundamentales como la triple restricción, definiciones objetivas de Calidad y Desperdicio, la diferencia entre problemas bien definidos y problemas complejos, bases de la metodología Scrum, y un caso real de aplicación de estos principios en un proyecto de diseño. 

Si bien diseño y desarrollo parecen dos mundos muy diferentes, diseñadores e ingenieros no sólo podemos encontrar puntos en común para entendernos, sino que también podemos aprender mutuamente.

Una muestra de que estos aprendizajes son aplicables a todas las disciplinas de diseño es que las metodologías ágiles, cada vez más aplicadas en proyectos de desarrollo, nacieron originalmente como respuesta a problemas de diseño e ingeniería industrial.

Los problemas que trata la ingeniería suelen involucrar mucha más gente y recursos que los que tratamos los diseñadores. El costo de un fracaso, por ello, resulta mucho mayor, resultando en la necesidad de definiciones y metodologías capaces de evitarlos.

Gestión vs. Azar

La primera definición importante es que un proyecto necesita de Gestión. Esto es, un esfuerzo constante sobre el “cómo” se trabaja, para poder despejar el camino a la hora de resolver el “qué” del problema. Este rol es desconocido por muchos diseñadores o programadores que trabajan por su cuenta, quienes consideran que sólo están trabajando mientras diseñan o programan. No considerar como “trabajo” el tiempo de interacción con el cliente, organización del trabajo, reporte del avance y otras tareas que no se identifican como productivas, lleva a que estas tareas -que se conocen indispensables para el éxito de un proyecto- se realicen mal o, simplemente, no se realicen.

La triple restricción

Para la gestión tradicional de ingeniería, se considera al proyecto enmarcado en tres variables: tiempo, costo y alcance, entendiendo por alcance lo que el equipo se compromete a hacer. Estas variables son mutuamente dependientes, de manera que no es posible tocar una de ellas sin impactar a las otras. Este modelo ya advierte de la necesidad de una definición y estimación correcta de las variables para poder gestionar tempranamente cualquier cambio. Pero al mismo tiempo, el hecho de que el modelo no defina claramente Calidad, lleva a que frecuentemente la calidad del producto sea sacrificada para satisfacer restricciones que surgen durante su ejecución. Este problema viene siendo atacado por lo que conocemos como Metodologías Agiles.

Metodologías ágiles y Calidad

Las metodologías ágiles proponen enfocar los esfuerzos en entregar mayor calidad en menor tiempo. Para ello, requerien en primer lugar definir de manera objetiva qué es Calidad. Ello hace posible asegurarla como resultado de un proyecto, en lugar de quedar librada a la suerte.

Tanto la ingeniería industrial como la ingeniería de software han plantado diversas definiciones y modelos de Calidad, de los cuales en la presentación se verá el de la filosofía Lean, surgida de adaptar a proyectos de software el modelo de Toyota. Ese modelo logró, en tan sólo 20 años, convertir a un país arrasado por dos bombas nucleares, en una potencia industrial.

La filosofía Lean establece que Calidad es lo que el usuario o cliente final valoran, y considera a todo lo demás como Desperdicio. Una conclusión importante es que la gestión y el equipo tienen la misión de identificar y eliminar el Desperdicio. La otra es que no podemos lograr calidad si no podemos entender y medir qué valora el cliente o usuario final.

Para las disciplinas de diseño, ergonomía, marketing y usabilidad son disciplinas que nos permiten, precisamente, entender y principalmente, medir qué valoran los usuarios finales. Aplicar correctamente las herramientas que proveen permite no sólo un producto de calidad, sino además un proceso de diseño en el cual cliente y equipo trabajan juntos con análisis, en lugar de enfrentarse en opiniones.

Scrum: domando problemas complejos

La ingeniería tradicional enfoca sus esfuerzos y metodologías de trabajo a lo que hoy se conoce como “problemas bien definidos”. Se trata de problemas conocidos, que pueden tener una formulación y resolución precisa.

En contraste, las metodologías ágiles enfocan sus esfuerzos a resolver problemas dinámicos, en los cuales los requerimientos cambian frecuentemente, no es posible entender el problema por completo antes de empezar a resolverlo, y no es posible encontrar una solución “correcta”, sino una mejor o peor que otra. En esta categoría de problemas, precisamente, se pueden enmarcar los esfuerzos de todas las disciplinas de diseño.

Scrum es una metodología ágil definida por Hirotaka Takeuchi y Ikujiro Nonaka en 1986 para incrementar velocidad y flexibilidad en el desarrollo de productos. Basada en casos de industria automotriz, fotocopiadoras e impresoras, y utilizado en Xerox, Canon, Honda, NEC, Epson, 3M y HP, hoy es un estándar aceptado en proyectos de desarrollo de software.

Scrum aplica a proyectos en los que los requerimientos cambian o son definidos sobre la marcha, ejecutados por un equipo bien capacitado, con buena comunicación interna y con el cliente.

Scrum propone:

• Separar el proyecto en sprints: iteraciones, mini-proyectos de tiempo fijo.
• Repriorizar tareas al principio de cada sprint.
• Las tareas son tomadas por el primer miembro del equipo que está libre.
• Cada sprint genera entregables.
• Intervención necesaria y estructurada del cliente en el proceso.

Roles e interlocutores en Scrum:

• Equipo (Scrum Master, diseñadores, desarrolladores)
• Equipo extendido (Equipo + Product Owner)
• Stakeholders (Equipo extendido + Clientes, Usuarios, Patrocinadores, Gerencia).

En la presentación se desarrolla este modelo y se presentan casos reales de aplicación de principios de Scrum en proyectos de diseño de diferente complejidad y escala. 

Esta charla también fue presentada en:

• Curso Experto Universitario en Accesibilidad y Usabilidad, UTN Facultad Regional Buenos Aires, 2015
• Curso Experto Universitario en Accesibilidad y Usabilidad, UTN Facultad Regional Buenos Aires, 2014
• Universidad de la Cuenca del Plata, 2013
• UX2012, Centro Cultural San Martín, 2012
• Encuentro Latinoamericano de Diseño, Universidad de Palermo, 2012

¿Querés proyectar tu UX Seniority?

¡Nuevo curso!

Seniority UX: Llevá tu carrera a otro nivel

Un curso para entender qué necesitás para proyectarte como UX Senior, y cómo lograrlo.

Conocé el temario y sumate!

La entrada Charla “Metodologías ágiles: diseñando sin desperdicio” se publicó primero en Kambrica.