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.

Lean UX, parte 6

Lean UX es, en esencia, una manera distinta de pensar, una nueva mentalidad para el diseño y desarrollo de productos. Involucra tres cosas fundamentales: un cambio de procesos, un cambio en la forma de enfrentar el trabajo de diseño y una transformación en la forma de gestionar los proyectos.

En esta sexta y última parte, se describe la fase de feedback e investigación que culmina el ciclo de Lean UX.

Lean UX, fase 4
Lean UX, fase 4

La investigación es un proceso continuo y colaborativo. Es continuo porque se lleva a cabo a lo largo de cada ciclo de iteración del producto. Es colaborativo debido a que la responsabilidad de esta labor es de todo el equipo y se comparte entre todos.

Descubrimiento colaborativo

El descubrimiento colaborativo es un enfoque que permite sacar al equipo de la oficina (la famosa frase “get out of the building!“) para estar en contacto directo con clientes potenciales y aprender de ellos. De esta forma, todo el equipo ejecuta experimentos y todos los involucrados aportan en la recopilación de información sobre el comportamiento de los usuarios.

Para llevar a la práctica el enfoque de descubrimiento colaborativo, Jeff Gothelf sugiere adoptar las siguientes acciones:

  • Todo el equipo trabaja y decide en conjunto sobre la declaración de hipótesis y construcción del MVP.
  • Todo el equipo define y participa en la ejecución de los experimentos divididos por parejas o pequeños sub grupos.

Descubrimiento continuo

El ciclo Lean UX debe ejecutarse de forma continua y constante. Es importante que el tiempo que transcurre entre la creación de las hipótesis, el diseño de los experimentos y el feedback de los usuarios se minimice lo más posible.

Para ayudar a que el feedback e investigación sea continuo se recomienda lo siguiente:

  • Establecer un calendario permanente de actividades.
  • Simplificar al máximo el protocolo y entorno de experimentación (discount usability engineering en su máximo esplendor, Nielsen dice al respecto: “It might be hard to appreciate today when many people talk about ‘Lean UX’, but these ideas were heresy 20 years ago).
  • Simplifica el reclutamiento de usuarios para participar en la experimentación.
  • Todo el equipo participando todo el tiempo.
  • Reunir al equipo después de las sesiones de experimentación tan pronto como sea posible para revisar en conjunto los resultados y tomar decisiones sobre la siguiente versión del MVP a trabajar.

Feedback obtenido

A medida que el equipo va obteniendo feedback de diversas fuentes, a lo largo de varios experimentos, es común encontrar momentos en los que se generen resultados, aparentemente, contradictorios. A medida que se avanza en la recopilación de feedback, Jeff recomienda realizar las siguientes prácticas:

  • Identificar patrones.
  • Apartar valores atípicos.
  • Corroborar datos con otras fuentes.

Es importante señalar que el feedback obtenido de un solo experimento nunca es concluyente. La investigación en Lean UX apuesta por la continuidad. Como dijo Kaliman: “serenidad y paciencia“.

Técnicas de monitorización para el descubrimiento colaborativo y continuo

El proceso de  feedback e investigación no sólo proviene de la ejecución de experimentos. El equipo debe asumir la cultura de obtener aprendizaje, colaborativo y continuo, de todas las fuentes posibles. Algunas de las fuentes de feedback pueden ser:

  • Servicio de atención al cliente.
  • Encuestas permanentes.
  • Analítica web.
  • Pruebas A/B.

Todas estas técnicas, además de la ejecución de experimentos, forman en su conjunto la base del ciclo Lean UX. El objetivo del equipo será recorrer este ciclo tantas veces como sea posible, para perfeccionar el concepto del producto en cada iteración.

***

Esta es, en síntesis, la descripción de Lean UX bajo la perspectiva de Jeff Gothelf. Los conceptos básicos están ahí, la misión, si decidimos aceptarla, es llevar la adopción de Lean UX a nuestras organizaciones, tarea nada sencilla pero que promete obtener resultados significativos.

El libro Lean UX fue publicado en 2010, han transcurrido ya seis años y muchas cosas han cambiado desde entonces. ¿Qué significa actualmente Lean UX? El mismo Jeff responde:

It means that we build cross-functional teams, product, design, and engineering who have the customer at their core and making the customer successful as their mission.

It’s lightweight, it’s iterative, it’s low risk. And the value of the work that you’re delivering increases based on evidence that you’re collecting from those low-risk experiments and tests that you’re running, so that you’re only making further investments in a particular design direction or in the product direction, if you’re getting a signal from the market that says, this is something that we should be working on, and we’re implementing it the right way.

La siguiente pregunta podría ser: ¿qué sigue ahora, cuál es la evolución de Lean UX? Para obtener la respuesta tendremos que esperar un poco más, hasta que Jeff publique su nuevo libro: Sense and Respond: How Successful Organizations Listen to Customers and Create New Products Continuously que verá la luz en febrero de 2017.

De cualquier forma, hay mucho por aprender y practicar todavía. Adoptar Lean UX puede tomar un tiempo relativamente considerable, ¿es necesario conducir todo el ciclo e incorporarlo desde el comienzo de un proyecto? Como dicen los conocedores: depende.

Para seguir profundizando sobre la filosofía Lean les recomiendo parte de la colección The Lean Series:

El mejor consejo es iniciar la adopción de Lean UX como un cambio de mentalidad en cada uno de nosotros; más allá de las fases y técnicas específicas que definen el método, Lean UX representa un modo distinto de pensar respecto a los procesos, un modo distinto de enfrentar las actividades de diseño y una transformación en la forma de gestionar nuestros proyectos.

Hagamos una transformación de nosotros mismos, después de nuestro equipo de trabajo y poco a poco llegaremos a toda la organización. Esa es la misión de un agente del cambio.

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.

Lean UX, parte 5

Lean UX es, en esencia, una manera distinta de pensar, una nueva mentalidad para el diseño y desarrollo de productos. Involucra tres cosas fundamentales: un cambio de procesos, un cambio en la forma de enfrentar el trabajo de diseño y una transformación en la forma de gestionar los proyectos.

En esta quinta parte, se describe la fase de ejecución de un experimento que permite validar una hipótesis a través de un Producto Mínimo Viable.

Lean UX, paso 3, ejecutar un experimento.
Lean UX, paso 3, ejecutar un experimento.

Introducción

En Lean UX el proceso de validación comienza con la ejecución de un experimento, probando con usuarios el MVP para comprobar las hipótesis.

Cuando el MVP es un prototipo, el proceso de ejecución del experimento incluye mostrar el prototipo desarrollado ante directivos, product owners y stakeholders del producto. Para ello, es recomendable que el equipo cuente con un día especial para realizar esta actividad de manera periódica (demo day). Cuanto más se exponga y comparta el prototipo con personas externas al equipo, más aprendizaje se obtiene. Obviamente, el mayor proceso de aprendizaje y conocimiento ocurre cuando el prototipo se muestra o prueba con clientes potenciales.

Ejecución de un experimento con prototipos

Un experimento puede ser tan simple como dejar que los usuarios utilicen y exploren libremente el prototipo para obtener el mayor feedback posible o bien, realizar un protocolo más formal a través de una prueba de usabilidad, siempre y cuando, el tipo de validación de hipótesis así lo requiera.

En una prueba de usabilidad, los usuarios tratan de realizar tareas críticas (aquellas que validan nuestra hipótesis) con el prototipo, mientras un grupo de observadores miran, escuchan y toman notas para recopilar feedback.

Dependiendo de la etapa del proyecto en que se realice un experimento de este tipo, el feedback esperado puede variar, pero por lo general se pretende:

  • Identificar problemas de usabilidad en el producto (prototipo).
  • Reunir información cuantitativa y cualitativa del desempeño de los usuarios con el producto (eficacia y eficiencia).
  • Determinar la satisfacción de los usuarios con el uso del producto.

Si se experimenta con un prototipo de lápiz y papel (paper prototyping) o si el experimento ocurre en etapas iniciales, el número de usuarios suficientes para validar la hipótesis puede ser entre 4 y 6, por grupo de usuario (protopersona).

Método: prueba de usabilidad

¿Quiénes participan?

  • Facilitador
    • Persona que conduce la prueba y orienta al usuario en las actividades a realizar durante la prueba.
  • Observador(es)
    • Persona que toma notas del comportamiento del usuario durante la prueba.
  • Wizard of Oz
    • Si la prueba se realiza con un prototipo de lápiz y papel, es necesario contar con un mago, la persona quien simulará la interacción en el prototipo.
  • Usuarios
    • Personas que cumplan con el perfil deseado (protopersonas)

Antes de empezar

  • Prototipo.

Ejecución

Una típica prueba de usabilidad puede describirse de la siguiente forma:

  1. Un facilitador recibe al usuario.
  2. El usuario toma su lugar en el espacio destinado para realizar la prueba, que debe corresponder al contexto de uso del producto.
  3. El facilitador explica al usuario el objetivo general de la prueba de usabilidad.
  4. El facilitador realiza un breve cuestionario para validar que el perfil de usuario es el correcto (protopersona), también sirve para romper el hielo.
  5. El facilitador le explica al usuario la técnica “Think Aloud Protocol” para que exprese todo lo que está pensando, en todo momento, en voz alta.
  6. El facilitador pregunta al usuario si tiene alguna pregunta.
  7. El facilitador le pide al usuario comenzar la prueba.
  8. El facilitador da lectura al primer escenario y la primera tarea, el usuario inicia la actividad.
  9. El usuario dice lo que piensa, mientras el facilitador y observador toman notas.
  10. La prueba continúa, escenario por escenario, tarea por tarea, hasta lograr la meta esperada en el tiempo determinado para la prueba.
  11. Una vez lograda la meta, o el tiempo, el facilitador da por terminada la prueba.
  12. El facilitador agradece al usuario su participación.

Como puede apreciarse, para realizar una prueba de usabilidad, además del prototipo, es imprescindible definir de manera previa tres aspectos:

  • Perfil del usuario
    • Es la representación o arquetipo de un usuario específico, en Lean UX, este arquetipo está definido por la protopersona.
  • Contexto de uso
    • Es el espacio y situación específica del uso del producto. Un escenario es una representación narrativa de un contexto de uso, permite situar a un usuario específico (protopersona) en interacción con el producto pretendiendo lograr una meta específica en un entorno específico.
  • Metas
    • Una meta es un objetivo final deseado por un usuario en un tiempo finito.
    • Una tarea es la realización de un conjunto de pasos necesarios para lograr una meta.
    • Existen tres clases de metas:
      • Metas finales: Lo que el usuario quiere hacer
      • Metas de experiencia: Lo que el usuario quiere sentir
      • Metas de vida: Lo que el usuario quiere ser

Una vez definidos el perfil de usuario, el contexto de uso y la meta a lograr, la prueba de usabilidad puede llevarse a cabo.

Recomendaciones para conducir una prueba de usabilidad

  • Se evalúa el producto, no al usuario.
  • Tratar a los usuarios con respeto.
  • Hacer sentir cómodos a los usuarios.
  • Generar confianza.
  • Recordar al usuario que exprese sus pensamientos en voz alta.
  • Ser neutral, no expresar opiniones positivas ni negativas.
  • No intervenir durante la prueba, en caso de asistencia al usuario, interrumpir el escenario y continuar a la siguiente tarea.
  • Tomar buenas notas.
  • Confiar más en lo que hace el usuario, que en lo que dice.

Recomendaciones para tomar notas

En Lean UX, en lugar de videograbar la sesión para posterior a las pruebas realizar una revisión minuciosa, como ocurre en pruebas convencionales, se recomienda adoptar el formato Lean User Research, donde el observador realiza durante la prueba un rápido registro de los aspectos críticos a considerar. El formato del observador es una hoja dividida en cuadrantes con los siguientes campos:

Lean User Research
Lean User Research

Stoppers

Se refiere a los problemas y dudas que tuvieron los participantes al estar realizando alguna tarea.

Values

Se refiere a los puntos que los usuarios consideraron que les aportó mayor valor agregado al momento de realizar las tareas.

Feedback

Se refiere a las opiniones y expresiones textuales que emitieron los usuarios a lo largo de las actividades realizadas.

Recommendations

Se refiere a las sugerencias del moderador desde la perspectiva del usuario para corregir los problemas de usabilidad y mejorar la experiencia de las personas.

Las pruebas de usabilidad deben ser una actividad de todo el equipo. Si todos observan la prueba, toman notas y absorben el feedback de los usuarios, no será necesario realizar largas sesiones de trabajo posteriores. Adicionalmente, trabajando de esta forma, el equipo podrá aprender rápidamente cuáles son las funcionalidades que se están trabajando correctamente y cuáles no. “No hay nada mejor que contemplar a los usuarios probando el [producto] en el que uno ha trabajado para que se te bajen los humos y te motives para hacerlo mejor”, afirma Jeff con toda razón.

Pruebas de usabilidad automatizadas

Además de realizar pruebas de usabilidad presenciales, es posible recurrir a pruebas online y pruebas automatizadas. Algunos tipos de este tipo de pruebas son:

  • First click testing
  • Five second testing
  • Tree testing
  • Eye tracking

Ejecución de experimentos con un MVP que no es un prototipo

Algunos ejemplos de experimentos con MVP que no son un prototipo pueden incluir:

  • Correo electrónico
    • Enviar un correo electrónico a una lista de clientes potenciales con la información de descripción del producto, oferta simulada, etc.
    • El feedback esperado puede medirse a través del índice de apertura de correo, los click-throughs o los de finalización de tarea.
  • Google Ad Words
    • Comprar un anuncio en Google Ad Words con la mayor segmentación posible.
    • El feedback a obtener incluye desde monitorear las búsquedas de los usuarios en Google, para conocer el tipo de lenguaje que le interesa a la audiencia, hasta los índices de click-throughs para validar el interés de los clientes potenciales en las palabras y mensajes que se incluyan en el anuncio.
  • Landing Page
    • Lanzar un Landing Page con un call to action obvio y específico, como “registro”, “compartir” o mejor aún “comprar ahora”.
    • El feedback consistirá en el número de conversiones logradas.
  • El botón a ninguna parte
    • En un Landing Page o en el sitio web del producto puede incluirse un botón que haga mención a la nueva funcionalidad del producto, no tiene que tener un enlace específico, ahí el truco.
    • El feedback obtenido es claro, cada vez que hay un clic en el botón, revela que hay un cliente potencial interesado en esa funcionalidad. Por obvias razones, hay que tener precaución con este tipo de experimentos.

Las opciones no se restringen a las opciones mostradas, la lista puede ser mucho mayor. Para decidir qué tipo de experimento es el más adecuado, es importante recordar la esencia de Lean UX: diseñar sólo lo necesario, salir a la luz lo más pronto posible, interactuar con usuarios reales y obtener el mayor feedback posible.

***

En la siguiente entrada, se describirá la cuarta fase del ciclo Lean UX, feedback e investigación.

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.

Lean UX, parte 2

Lean UX es, en esencia, una manera distinta de pensar, una nueva mentalidad para el diseño y desarrollo de productos. En esta segunda parte, se describen los pilares y principios de Lean UX.

Pilares

Lean UX se apoya en tres pilares clave: Design Thinking, metodologías de desarrollo ágil de software y Lean Startup.

1. Design Thinking

Innovación que se alimenta de […] la observación directa de lo que la gente quiere y necesita en sus vidas y lo que les gusta o disgusta de cómo se hacen los productos, cómo se empaquetan, cómo se ponen en el mercado, cómo se venden y cómo se les presta ayuda […]. Se trata de una disciplina que, utilizando la sensibilidad y los métodos de los diseñadores, satisface las necesidades del público con aquello que resulta tecnológicamente posible y que, gracias a una estrategia de negocio viable, puede convertirse en valor para los clientes y en oportunidades en el mercado.

Tim Brown, CEO de IDEO

Design Thinking es un pilar básico de Lean UX debido a que aporta una manera de trabajar que alienta la colaboración en el equipo, independientemente del rol que cada uno desempeñe, y que considera el producto desde una perspectiva holística y abarcadora.

Proceso Design Thinking.
Proceso Design Thinking.

2. Metodologías de desarrollo ágil de software

Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

  • 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.

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda”.

Manifiesto ágil

 

El segundo pilar de Lean UX son las metodologías de desarrollo ágil de software. Lean UX aplica en el diseño de productos los cuatro pilares del Manifiesto Ágil:

  • Individuos e interacciones sobre procesos y herramientas. La comunicación efectiva entre miembros del equipo debe prevalecer por encima de las restricciones propias de las herramientas, ya sea en los procesos o en la producción.
  • Software funcionando sobre documentación extensiva. Cuanto antes dispongamos de un producto que funcione, seremos capaces de encontrar la solución que mejor se adapta al mercado.
  • Colaboración con el cliente sobre negociación contractual. Si el equipo colabora con el cliente, se podrá crear un entendimiento común sobre el problema y las posibles soluciones.
  • Respuesta ante el cambio sobre seguir un plan. Fallar rápido. Fallar barato. El producto inicial no dará con la mejor solución posible, el objetivo es averiguar qué se ha hecho mal lo antes posible, ajustar y volver a probar.

3. Lean Startup

El método Lean Startup es un conjunto de prácticas pensadas para ayudar a los emprendedores a incrementar las probabilidades de crear una startup con éxito. No es una fórmula matemática infalible, sino una filosofía empresarial innovadora que ayuda a los emprendedores a escapar de las trampas del pensamiento empresarial tradicional.

Eric Ries
Lean Startup

 

Lean Startup utiliza un ciclo de retroalimentación (feedback) denominado “crear-medir-aprender” que minimiza el riesgo de los proyectos y consigue que el equipo pueda desarrollar software y aprender de él en muy poco tiempo.

Con este método, los equipos desarrollan lo antes posible un Producto Mínimo Viable (MVP, por sus siglas en inglés) para comenzar el proceso de aprendizaje cuanto antes.

Proceso Lean Startup.
Proceso Lean Startup.

Lean UX aplica de manera directa la filosofía de Lean Startup sobre aumentar la frecuencia de contacto con clientes reales, reducir el despilfarro y probar lo antes posible las ideas del equipo para evitar caer en suposiciones incorrectas sobre el mercado.

En Lean UX, cada diseño es una solución propuesta para el negocio -una hipótesis-, el objetivo es validar esa solución lo más eficientemente posible, utilizando para ello la retroalimentación de los clientes.

La validación de hipótesis en Lean UX sigue el siguiente proceso:

  1. Crear un MVP.
  2. Probar la hipótesis mostrando el MVP a clientes reales.
  3. Utilizar lo aprendido para modificar el MVP.
  4. Iterar.

De esta forma, Lean UX permite de forma más rápida sacar a la luz la verdadera naturaleza de los productos. La filosofía de Lean UX es otorgar más importancia a la creación de un entendimiento común de la experiencia del usuario del producto que se diseña que a la creación y entrega de documentación.

Principios

A partir de los pilares de Design Thinking, las metodologías ágiles de desarrollo y Lean Startup, Lean UX plantea sus propios principios, una serie de atributos que permite a los equipos trabajar de manera colaborativa y multifuncional para lograr el desarrollo de productos orientados a la experiencia del usuario. 

Jeff Gothelf define los principios de la siguiente forma:

1. Equipos multifuncionales

Lean UX necesita que el equipo se conforme con todas las disciplinas que intervienen en la creación de un producto, que colabore intensamente y de manera contínua, desde el primer día hasta el final.

2. Equipos pequeños, dedicados, coubicados

Es necesario limitar el tamaño de los equipos para lograr: comunicación, concentración y camaradería.

3. Progreso igual a resultados, no a entregas de documentación

Lean UX mide el progreso del proyecto según los resultados de negocio, no por la acumulación de documentación.  

4. Equipos centrados en los problemas

El equipo debe estar enfocado en resolver problemas y no limitarse a implementar funcionalidades de desarrollo.

5. Eliminación del despilfarro

En Lean UX, todo lo que no ayude a conseguir resultados, se considera un despilfarro y debe eliminarse del proceso de trabajo.

6. Lotes pequeños

El equipo sólo debe crear el diseño necesario para avanzar, evitando crear un gran volumen sin probar ni implementar.

7. Descubrimiento continuo

En Lean UX, los clientes del producto participan en el proceso de diseño y desarrollo con el objetivo de validar las ideas sobre el producto. La investigación de mercado con clientes reales debe realizarse de forma frecuente y regular, así como involucrar a todo el equipo.

8. Get out of the building

Las respuestas a los problemas están en el mercado, con los clientes reales, no en la oficina del equipo. Es mucho mejor averiguar que nuestras ideas de solución están equivocadas antes de dedicar tiempo y recursos a construir un producto que nadie quiere.

9. Entendimiento común

A medida que un equipo trabaja de forma conjunta, logrará un conocimiento colectivo y una comprensión profunda del producto y de los clientes.

10. Antimodelos: estrellas, gurús y ninjas

Lean UX privilegia una visión de equipo. Las estrellas, gurús, ninjas y expertos reducen la colaboración y frenan la cohesión del equipo.

11. Exteriorización del trabajo

Los equipos deben mostrar su trabajo de forma abierta, más allá de un monitor. El uso de pizarrones, tableros, notas adhesivas y demás anotaciones visibles es un común denominador en Lean UX para mostrar el trabajo a compañeros, colegas y clientes.

13. Hacer en lugar de analizar

Tiene más valor crear la primera versión de una idea que emplear horas de  discusión en una reunión debatiendo si vale la pena o no construirla.

14. Aprendizaje en lugar de crecimiento

Lean UX prioriza aprender sobre una idea y después buscar su crecimiento. Escalar una idea que no se ha probado es arriesgado.

15. Permiso para equivocarse

Los equipos en Lean UX necesitan experimentar con las ideas. La mayor parte de estas ideas, no funcionará. El equipo debe sentirse libre para equivocarse. Las grandes ideas siempre proceden de los riesgos.

16. Escapar de los negocios basados en entregables

El progreso de un proyecto depende de los resultados que se consiguen, no de los documentos que el equipo escriba.

***

Tener presente los pilares y principios de Lean UX nos obliga a no olvidar su esencia, la empatía hacia los usuarios (Design Thinking), el trabajo en equipo (métodos ágiles) y la experimentación como instrumento de validación (Lean Startup). Las técnicas particulares y las fases que comprenden el método en realidad son secundarias, o como dice El Principito, “lo esencial es invisible a los ojos”.

En la tercera parte de esta serie, describiré la primera fase del proceso de Lean UX: la declaración de supuestos y las técnicas que comprende.

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.

Lean UX, parte 1

Lean UX es, en esencia, una manera distinta de pensar, una nueva mentalidad para el diseño y desarrollo de productos. Involucra tres cosas fundamentales: un cambio de procesos, un cambio en la forma de enfrentar el trabajo de diseño y una transformación en la forma de gestionar los proyectos.

¿Por qué es necesario cambiar la forma en que se diseñan los productos?

Un poco de historia

En marzo de 2011, Jeff Gothelf, un reconocido diseñador de producto,  publicó Lean UX: Getting Out of the Deliverables en donde describe por primera vez el concepto Lean UX. Para Jeff, la manera en la que los diseñadores colaboran en el desarrollo de productos atraviesa una situación crítica, pasan más tiempo creando documentos en donde se especifica cómo debería ser el producto en lugar de crearlo.

Cuando los diseñadores trabajan con el paradigma de priorizar la creación de documentación exhaustiva y se combina con un entorno de desarrollo en cascada, el resultado es un consumo de tiempo perdido y la creación de una enorme cantidad de despilfarro (waste). Un despilfarro o residuo se define como cualquier cosa que termina no siendo realmente útil en el desarrollo de un producto.

Típicamente, el modelo en cascada para el desarrollo de software sigue las siguientes fases:

Modelo en cascada
Modelo en cascada

Bajo este escenario, las actividades de diseño generalmente involucran:

  • Esperar la definición de requisitos para contar con la aprobación de iniciar.
  • Leer la documentación de requisitos.
  • Elaborar mapas de sitio de alto nivel (sitemaps) y flujos de trabajo (workflows).
  • Llegar a un consenso y aprobación.
  • Desarrollar wireframes.
  • Presentar a las partes interesadas, conseguir consenso y aprobación.
  • Crear diseños visuales por cada wireframe.
  • Presentar a los interesados hasta obtener una aprobación final (después de repetidos ciclos de revisión).
  • Escribir las especificaciones, detallando cada pixel e interacción.
  • Realizar pruebas de usabilidad para futuras mejoras.
  • Revisar la fase de desarrollo, aprobar e iniciar la implementación.

Este camino deja muchas horas de despilfarro y muchos diseñadores frustrados a su paso porque al finalizar, el producto de software no corresponde a las necesidades reales de los clientes. La mayor mentira en el mundo del desarrollo de software es pensar que existirá una “Fase II” del proyecto para corregir todos los problemas que surgen en la primera entrega. La verdad es que la mayoría de las veces nunca existe una fase II.

Cómo funcionan los proyectos
Cómo funcionan los proyectos en cascada

Los métodos tradicionales de desarrollo de productos se empeñan en definir organizaciones y equipos de trabajo lineales en un mundo sometido a un cambio constante, pretende crear silos aislados en un entorno donde se necesita colaboración continua e ininterrumpida.

Este es el paradigma que intenta romper Lean UX.

Inspirado por las teorías de Lean Startup, Design Thinking y del desarrollo ágil de software, Lean UX es la práctica de traer a la luz la verdadera naturaleza del trabajo de los diseñadores, de forma más rápida, con menos énfasis en las prestaciones (documentación) y una mayor concentración en la experiencia real que está siendo diseñada.

En Lean UX los documentos tradicionales de diseño (sitemaps, wireframes, workflows, etc.) se descartan o, al menos, se reducen a la cantidad mínima de información necesaria para empezar a trabajar en la implementación lo más pronto posible. Los ciclos largos de diseño detallado se evitan en favor de ciclos muy cortos e iterativos, de baja fidelidad, con retroalimentación temprana y frecuente procedente de todos los miembros del equipo de implementación. La colaboración con todo el equipo se vuelve fundamental para el éxito del producto.

En su concepción original, el proceso Lean UX se definió a través de las siguientes fases:

Proceso original Lean UX
Proceso original Lean UX

El planteamiento retomó muchos conceptos provenientes de las metodologías ágiles: en una fase inicial, el equipo comienza a dar sus puntos de vista sobre la dirección del diseño, así como su viabilidad.  A continuación se realizan cambios a la idea original, que incluso puede ser desechada en su totalidad para proponer una nueva idea.

La inversión inicial en su representación a través del dibujo es tan mínima que no hay ningún costo significativo para replantear por completo el sentido. Una vez que se ha acordado internamente una cierta dirección, un prototipo de baja fidelidad ayuda a validar la idea con clientes reales. El aprendizaje ayuda a perfeccionar la idea, y el ciclo se repite.

Lean UX se enfocó en las actividades de diseño, lo cual permitió incorporar su ejecución a prácticamente cualquier proceso o marco de trabajo de desarrollo de software.

Desde su aparición, Lean UX empezó a ser adoptado en gran cantidad de organizaciones. Dos años más tarde, en 2013, Jeff publica el libro Lean UX: Applying lean principles to improve user experience donde define el ciclo que conocemos actualmente:

Ciclo Lean UX
Ciclo Lean UX

El ciclo inicia con la declaración de supuestos sobre el proyecto para determinar las hipótesis, después es necesario determinar qué ideas sobre el producto son válidas y cuáles deben descartarse a través de un Producto Mínimo Viable, el cual debe permitir la ejecución de un experimento que permita generar investigación y obtener retroalimentación de clientes reales. El aprendizaje adquirido es utilizado en la siguiente iteración del ciclo.

Más allá del ciclo que lo define, Lean UX representa un viaje hacia una nueva forma de trabajar, quienes deseen iniciar este viaje deben estar dispuestos a romper paradigmas, un tema particularmente difícil para quienes están inmersos en métodos de trabajo rígidos y lineales, aquellos que siguen esperando la fase II.

Escapemos de los negocios basados en documentación y volvamos a concentrarnos en la tarea más urgente: hacer felices a nuestros clientes”, es el llamado que hace Jeff Gothelf en Lean UX.

En la segunda parte de esta serie, hablaré sobre los principios de Lean UX.

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.

De personas a Personas

Alan Cooper creó el método Personas, arquetipos basados en patrones de comportamiento revelados durante el proceso de investigación de usuarios que se construyen con el propósito de ser una herramienta de comunicación durante el diseño de un producto.

A través de Personas se define una forma precisa de pensar y comunicar acerca de cómo son los grupos de usuarios, cómo se comportan, cómo piensan, qué quieren lograr y por qué.

Un poco de historia

En 1999, Alan Cooper, fundador de Cooper, una de las firmas de diseño de experiencia de usuario y estrategia digital más importantes a nivel global, introdujo en el libro The Inmates Are Running the Asylum la noción de “Personas”, un método propuesto para emplearse dentro de la filosofía de Diseño Centrado en el Usuario. En términos simples, Personas proyecta una representación ficticia pero concreta del grupo de usuarios al que va dirigido un producto. Fue en el  libro About Face: The Essentials of Interaction Design, donde Cooper detalló un proceso específico para la creación de Personas.

Desde su aparición, el método Personas ha sido ampliamente adoptado en la industria y ha reportado beneficios directos en el desarrollo de productos y servicios.

La palabra ‘persona’

Antes de entrar en detalle sobre la ejecución del método, vale la pena hacer mención como breviario cultural del significado de la palabra persona. En inglés, persona significa “los aspectos del carácter o personalidad de un individuo que se presenta o es percibida por los demás”, la traducción más cercana en español sería personaje, pero por alguna razón solemos conservar el término original en inglés, aunque estrictamente hablando la palabra tiene una connotación distinta en español ya que es sinónimo de individuo o una forma de nombrar a alguien omitiendo su género.

Más allá de la traducciones, lo importante es comprender que el valor intrínseco del método Personas consiste justo en la definición de esos aspectos del carácter o personalidad de un usuario específico:

Definición de Personas
El significado de la palabra Personas.

El método ‘Personas’

Alan Cooper define en su libro About Face: The Essentials of Interaction Design  el proceso para la construcción de Personas y de la metodología de Diseño Orientado a Metas (Goal-Directed Design), conceptos clave en Diseño Centrado en el Usuario.

Para Cooper, las Personas son arquetipos basados en patrones de comportamiento revelados durante el proceso de investigación de usuarios y se construyen con el propósito de ser una herramienta de comunicación durante el diseño del producto.

Mediante el uso de estos personajes ficticios, es posible desarrollar una comprensión clara de los objetivos de los usuarios en contextos específicos, a la vez que representan un instrumento crítico para la ideación y validación temprana de conceptos de diseño.

Como mencioné antes, a través de Personas se puede definir una forma precisa de pensar y comunicar cómo son los grupos de usuarios, cómo se comportan, cómo piensan, cuáles son las metas que quieren lograr y por qué.

Contrario a lo que muchos piensan sobre el método, Personas no sólo significa pensar arbitrariamente en estereotipos y generalizaciones de personalidad, inventar unos cuantos datos demográficos, editar una plantilla, elegir una fotografía ad hoc y exportarlo todo como archivo PDF. En realidad el método va mucho más allá.

Para que Personas sea realmente un instrumento eficaz para el diseño del producto es necesario que se defina con todo el apego posible a los métodos de investigación de usuarios existentes en User Experience, con el fin de identificar adecuadamente los patrones importantes y significativos del comportamiento de los usuarios y determinar cómo estos comportamientos se traducen en arquetipos que representan con precisión al grupo apropiado de usuarios.

El problema de diseñar para todos

Cooper menciona en About Face que para crear un producto que debe satisfacer a un público diverso de usuarios, la lógica parece indicar que la funcionalidad del producto debe ser lo más amplia posible para alcanzar a la mayor cantidad de usuarios. Esta lógica, afirma, es errónea.

La mejor manera de conducir con éxito un producto orientado a una variedad de usuarios es diseñar para tipos específicos de personas con necesidades específicas.

Cuando se extiende de manera arbitraria la funcionalidad de un producto para incluir demasiadas características, se aumenta la carga cognitiva y el esfuerzo de navegación para todos los usuarios. Justo ese es el principal problema: cuando se intenta agradar a todos, es probable que se termine no complaciendo a nadie de manera específica.

¿Recuerdan la definición de Usabilidad? “Usuarios específicos, logrando objetivos específicos con eficacia, eficiencia y satisfacción, en un contexto de uso específico”. Como podrán notar, la palabra clave es: chocolate.

En vez de intentar “diseñar para todos”, Personas sugiere definir primero un número limitado de individuos o personajes para quienes diseñar y que representen mejor las necesidades del conjunto más amplio y representativo de usuarios. Después se debe iniciar el proceso de diseño dando prioridad a estas personas para que las necesidades de los usuarios más importantes se cumplan en primera instancia, sin que esto signifique dejar de lado las necesidades de usuarios secundarios.

Beneficios de diseñar con Personas

De acuerdo con Cooper, Personas ayuda a equipos de diseño a:

  • Determinar lo que un producto debe hacer y cómo debe comportarse. Las metas de una Persona y las tareas a realizar para cumplir sus metas proporcionan la base para el trabajo de diseño.
  • Mejorar la comunicación entre cliente, stakeholders, desarrolladores y otros diseñadores. Personas proporciona un lenguaje simple y común para discutir las decisiones de diseño y también ayuda a mantener el diseño centrado en los usuarios en cada paso del proceso.
  • Construir consenso y comprometerse con el diseño. Con un lenguaje común debe llegar también, en teoría, un entendimiento común sobre el producto.
  • Medir la efectividad del diseño. Se pueden probar y validar diferentes opciones de diseño con una Persona, contrastando cada propuesta contra las necesidades y metas de la Persona. Desde luego, esto no reemplaza la necesidad de probar el producto con usuarios reales, pero proporciona una forma simple en que los diseñadores pueden resolver problemas de diseño, sobre todo en una etapa temprana.
  • Contribuir con otros esfuerzos relacionados con el producto. Personas puede ser una herramienta útil para otros equipos de la organización como el de mercadotecnia y ventas, que requieren conocimiento a detalle de los usuarios de un producto y suelen usar a Personas como herramienta para lograr sus propios objetivos.

Problemas de no diseñar con Personas

Existen tres problemas típicos que surgen durante el desarrollo de un producto cuando no se diseña para usuarios específicos: el usuario elástico, el diseño auto referencial y los casos extremos:

El usuario elástico

Cada vez es más común que todos los involucrados en el desarrollo de un producto empleen la palabra “usuario” en su jerga cotidiana. En esencia, es algo positivo; el problema estriba cuando cada miembro del equipo tiene sus propias concepciones de quién es el usuario y cuáles son sus necesidades; o peor aún, cuando moldean las características de los usuarios acorde a sus propios intereses, es ahí cuando surge el “usuario elástico”.

Utilizar de manera genérica e indistinta el término “usuario” siempre causa problemas pues se vuelve impreciso, amorfo e incluso efímero; el abuso de éste término permite a los equipos adaptar y estirar indiscriminadamente las características del usuario acorde a las limitaciones o posibilidades del producto, en lugar de diseñar un producto que se adapte y estire a las necesidades de usuarios específicos.

La falta de precisión sobre los usuarios puede llevar a una falta de claridad sobre cómo el producto debe comportarse en función de sus objetivos, habilidades y contextos.

El diseño auto referencial

Se produce cuando diseñadores o desarrolladores proyectan sus propios objetivos, motivaciones, habilidades y modelos mentales dentro del diseño de un producto. Esto puede ser útil para algunas situaciones particulares, pero en general no es apropiado en la mayoría de las ocasiones.

Los casos extremos

Otro problema que Personas ayuda a prevenir es que el esfuerzo de diseño esté  centrado en atender situaciones extremas que podrían ocurrir pero que por lo general no se presentarán para la mayoría de los usuarios. Los casos extremos usualmente deben ser diseñados y programados pero nunca deben ser el foco del diseño. Personas define las necesidades, situaciones y contexto del usuario para el cual debe diseñarse, permitiendo priorizar las funciones del producto con mejor claridad.

Investigación de usuarios primero, Personas después

Cooper hace énfasis en señalar que Personas, como cualquier modelo de representación, debe estar basado en la observación del mundo real. Las principales fuentes de datos utilizadas para sintetizar Personas deben ser entrevistas uno-a-uno, técnicas etnográficas, investigación contextual, análisis de tareas u otros métodos similares de observación de usuarios reales actuales y/o potenciales del producto.

Otros métodos y datos que pueden complementar la creación de Personas son:

  • Entrevistas con usuarios reales fuera de su contexto de uso.
  • Información sobre los usuarios proporcionada por cliente, stakeholders y expertos en la materia.
  • Datos de investigación de mercado, tales como focus group y encuestas.
  • Modelos de segmentación de mercado.
  • Información recopilada de revisión de literatura y estudios previos.

Sin embargo, ninguno de estos datos complementarios se puede tomar en lugar de las entrevistas de los usuarios directos y de la observación. Casi todos los aspectos de una Persona bien desarrollada se basa en declaraciones y comportamientos de los usuarios reales en su contexto de uso.

El proceso para la construcción de Personas

Tras años de experiencia en Cooper, trabajando para distintos proyectos de diseño de interacción, Alan y su equipo lograron definir un proceso estándar para la definición de Personas. El proceso consiste en los siguientes pasos:

  1. Grupos de entrevistas personales por rol de usuario.
  2. Identificar las variables de comportamiento.
  3. Mapa de entrevistas por variables de comportamiento.
  4. Identificar patrones significativos de comportamiento.
  5. Sintetizar las características y definir metas.
  6. Revisar para evitar redundancia y afinar integridad.
  7. Designar los tipos de Persona.
  8. Expandir la descripción de atributos y comportamientos.
Proceso de creación de Personas
Proceso de creación de Personas.
Paso 1. Grupos de entrevistas personales por rol de usuario

Después de haber concluido la investigación de usuarios es recomendable agrupar las entrevistas de acuerdo a los diferentes roles identificados. La clasificación de roles depende del tipo de proyecto, pero generalmente se define por criterios como actitudes o enfoques hacia el producto, intereses o aptitudes en relación con el estilo de vida, etc.

Paso 2. Identificar las variables de comportamiento

Una vez agrupadas las entrevistas, es necesario elaborar una lista con los distintos aspectos de la conducta observada por cada rol, así como un conjunto de las variables de comportamiento identificadas .

En general, los patrones de comportamiento surgen enfocándose en analizar los siguientes tipos de variables:

  • Actividades. Lo que el usuario hace; con qué frecuencia y en qué cantidad.
  • Actitudes. Qué piensa el usuario acerca del uso producto y la tecnología.
  • Aptitudes. Qué educación y entrenamiento tiene el usuario; cuál es su habilidad para aprender.
  • Motivaciones. Por qué el usuario está involucrado en el uso del producto.
  • Habilidades. Habilidades del usuario relacionadas con el uso del producto y la tecnología.
Paso 3. Mapa de entrevistas por variables de comportamiento

El siguiente paso es contrastar cada entrevista realizada contra las variables identificadas. El resultado deseado es representar con precisión cómo los usuarios encajan con cada variable significativa, como se muestra en la siguiente figura:

 Mapeo de entrevistas por variables de comportamiento
Mapeo de entrevistas por variables de comportamiento.
Paso 4. Identificar patrones significativos de comportamiento

Una vez realizado el mapeo de entrevistas, se deben identificar los grupos de individuos que se crean a través de las variables. Un conjunto de personas que se agrupan dentro de seis a ocho variables diferentes probablemente representará un patrón de comportamiento significativo que será la base de una Persona.

Paso 5. Sintetizar las características y definir metas

Las metas de una Persona y otros atributos se derivan de sus comportamientos. Estos comportamientos se sintetizan a partir de lo observado / identificado en el proceso de investigación, por ejemplo, el uso representativo y típico del producto durante un período de tiempo que capte adecuadamente el conjunto relevante de las acciones del usuario. A esta representación se le llama “un día en la vida de”, el período de tiempo de este “día” depende del producto o servicio que se utilice y lo que hace la Persona con él.

Por cada patrón de comportamiento que se identifique, se debe sintetizar detalles de sus datos. Estos detalles deben incluir:

  • Los comportamientos de ellos mismos (sus actividades y motivaciones).
  • El entorno de uso.
  • Las frustraciones y los puntos de dolor relacionados con el comportamiento utilizando las soluciones actuales
  • Datos demográficos asociados con el comportamiento
  • Capacidades, experiencia o habilidades relacionadas con el comportamiento
  • Las actitudes y las emociones asociadas con el comportamiento
  • Interacciones relevantes con otras personas, productos o servicios
  • Maneras alternativas de hacer lo mismo que el producto intenta solucionar.

Cooper señala que en este punto, el nivel de detalle no debe ir más allá de oraciones breves y puntuales sobre los comportamientos. Se trata de crear una herramienta de diseño, no un  personaje de telenovela.

Este es un buen momento para definir el nombre y apellido de cada Persona. También se recomienda añadir un poco de información demográfica, como la edad, la ubicación geográfica y el tipo de empleo.

Paso 6. Revisar para evitar redundancia y afinar integridad

En este punto, las Personas creadas deben ya empezar a cobrar vida propia. El proceso recomienda revisar las características atribuidas a las Personas para ver si existen “lagunas” importantes a cubrir. Esta revisión puede incluir la necesidad de realizar investigaciones adicionales para encontrar comportamientos particulares faltantes.

Paso 7. Designar los tipos de Persona

La siguiente parte de la construcción de Personas es priorizar los personajes para determinar cuál de ellos debe ser el objetivo principal del producto. Hay seis tipos de Personas:

Persona primaria

Un producto sólo puede tener un perfil de usuario principal por tipo de sistema o interfaz, pero es posible que algunos productos tengan varias interfaces distintas, cada una dirigida a un personaje principal distinto.

Elegir el personaje principal es un proceso de eliminación: se debe probar cada Persona mediante la comparación de sus metas respecto a las metas de los otros.

Persona secundaria

Un personaje secundario es aquel que, aunque la mayoría de sus necesidades son satisfechas con la interfaz del personaje principal, tiene necesidades específicas adicionales.

No siempre se tiene una Persona secundaria.

Persona complementaria

Son personajes que aunque tienen características particulares, sus necesidades están completamente representadas por una combinación de las Personas primarias y secundarias.

Personas cliente

Representan necesidades puntuales de los clientes, no de los usuarios finales. Un típico uso es crear una Persona para una interfaz de administración del sistema. En algunas ocasiones, los personajes de los clientes son tratados como personajes secundarios.

Personas atendidas

No representan usuarios finales, sino que se ven directamente afectados por el uso del producto. Estos son tratados como personajes secundarios.

Personas negativas

Se utilizan para comunicar que el producto no está siendo construido para servir a determinados tipos de usuarios, es decir, representan a los anti-usuarios. Su uso es puramente retórico: para ayudar a comunicar que una persona definitivamente no debe ser objetivo de diseño del producto.

Paso 8. Expandir la descripción de los atributos y comportamientos

La lista de características y metas definida en el paso 5 refleja la esencia de los comportamientos, pero puede dejar mucho implícito. En este paso se construye una narración en tercera persona sobre las actitudes de la personalidad, necesidades y problemas de la Persona.

La narración tiene un tono ficticio, generalmente plasma brevemente un día en la vida del personaje, incluyendo manías, preocupaciones e intereses que tienen relación directa con el producto. Los detalles deben ser una expansión de la lista de características previamente definida, con datos adicionales derivados de observaciones y entrevistas.

Finalmente, un detalle característico de Personas es la elección de una o más fotografías que las representen. Una buena fotografía debe reflejar la información demográfica definida, aludir el contexto de uso del producto y la actitud general del personaje.

Un típico formato de Persona, donde se condensa todo el trabajo realizado, luce más o menos así:

Formato Persona
Formato Persona.

 

El formato, insisto, es un aspecto secundario, lo importante es el proceso.

Conclusiones

Personas es una herramienta que se ejecuta de manera metódica a través de una serie de pasos y su definición se apega a resultados de investigación de usuarios. Muchas de las objeciones al método son resultado de malas interpretaciones acerca de cómo se deben construir las Personas.

Desafortunadamente, es común encontrar proyectos en donde se utiliza el concepto de Personas pero definidas de manera escueta o a partir de supuestos sobre el producto que nunca son validados. Estos intentos de maquillar procesos de investigación de usuarios con falsas pretensiones de creación de Personas y no hacen más que dañar y desestimar la disciplina de User Experience. ¡No se dejen seducir por el lado oscuro!

Otra crítica hacia el método es el concepto de metas y tareas, pues una parte de la comunidad de profesionales de UX afirma que no en todos los productos se cuenta con una definición clara de estos elementos y que en ocasiones los usuarios “sólo observan lo que está pasando”. Cooper arremete diciendo que “aunque puede ser correcto decir que no todos los usuarios piensan en términos de tareas, las tareas no son el corazón de Personas. Las metas sí, y también “estar al día con lo que está pasando” es una meta.

Personas es un gran método dentro de la filosofía de Diseño Centrado en el Usuario que contribuye de manera significativa en el proceso de desarrollo de un producto si se ejecuta de manera profesional y honesta. Aprendan el método, crean en él y contribuyan a diseñar mejores experiencias de usuario.

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.

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.