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.

El rol del Sprint Master en un Design Sprint

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

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

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

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

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

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

El trabajo del sprint master

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

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

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

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

Antes del design sprint

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

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

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

Durante el design sprint

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

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

Después del design sprint

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

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

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.

Factores que afectan los procesos perceptuales en el usuario

En el año 2007, cuando comenzaba a hacer investigación sobre experiencia de usuario, fui encontrando información sobre los factores que afectan los procesos perceptuales en el usuario.

Diferentes estudios revelan que las percepciones están influidas por diferentes situaciones como:

  • Motivación. Si una persona tiene una necesidad especifica no satisfecha, ésta influirá en su experiencia perceptiva; por ejemplo, si alguien tiene hambre, detectará más rápidamente las imágenes u olores de alimentos, entre otros estímulos.
  • Expectativas. Las expectativas que tiene la persona le influyen en su capacidad de percibir. Por ejemplo, podemos leer un texto sin percibir algún error porque identificamos las palabras con mucha rapidez e intuimos lo que dirán.
  • Estilos Cognoscitivos. Existen dos tipos de estilos cognitivos: los igualadores, que  suprimen las diferencias, y los diferenciadores que las acentúan.
  • Antecedentes culturales. Los antecedentes culturales juegan un papel importante en las percepciones. El idioma y cualquier diferencia cultural puede afectar a la percepción del ambiente.
  • Memoria y aprendizaje. En el proceso de aprendizaje la memoria es uno de los elementos fundamentales. La memoria funciona como un gran archivador en el que se ubica la información en el lugar correspondiente y así se facilita el proceso de selección y recuperación de información.

La memoria y el proceso memorístico están formados por tres fases:

  1. Registrar. Se realiza el contacto con los elementos que posteriormente se memorizarán.
  2. Retener. Cuanta más atención se preste a lo que se intenta memorizar, más fácil será retenerlo.
  3. Rememorar. Consiste en recordar aquello que ha memorizado.

Cuando el usuario procesa la información, al principio ésta pasa de la memoria de trabajo a la memoria a corto plazo, pero lo que tiene que hacer después es enviarla a la memoria a largo plazo.

Otros autores hablan sobre las memorias episódica y semántica. La episódica se relaciona con el recuerdo de experiencias personales particulares, como la primera vez que una persona vio el mar. La semántica está ligada al recuerdo de información general no relacionada de forma consciente con una experiencia personal.

Es necesario plantear y reflexionar acerca de qué tanto conocemos al usuario y saber cuáles factores afectan sus procesos perceptuales. Sí bien en muchas ocasiones y dependiendo de las circunstancias en las que se esté trabajando un proyecto partimos de supuestos, no siempre es la opción más recomendable.

Si se va a partir de supuestos, no es opción:

  • Plantear qué quieren de ti tus usuarios,
  • Escuchar lo que se te dice de tu usuario,
  • Menospreciar lo que el usuario dice,
  • Ignorar el tiempo de las interacciones que hace tu usuario,
  • Descuidar los detalles importantes, desde lo sencillo a la vista del usuario, que se hace transparente o invisible,
  • Respetar su deseo de estar el tiempo suficiente y necesario mientras interactúa con los contenidos que se les muestra.
Diseñadora gráfica y psicóloga especializada en diseño editorial e hipermedios, ha sido investigadora y consultora en usabilidad, user experience y diseño emocional desde 2007.

Cuando todo está mal: el Oscurantismo de UX

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

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

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

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

* * *

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

* * *

¿Cuál es el punto de este ejercicio?

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

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

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

El punto de no regreso de UX

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

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

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

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

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

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

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

No son ellos, eres tú

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

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

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

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

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

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

Project Comet, ¿la “primera solución todo-en-uno para diseñadores UX”?

El pasado 5 de octubre se llevó a cabo MAX, la conferencia creativa de Adobe. El evento tuvo una especial relevancia para el mundo de User Experience por la presentación, adelantada, de “Project Comet”, que Adobe describió como “la primera solución todo-en-uno para diseñadores UX”.

Les presento una rápida revisión por las principales características de Project Comet y la inevitable comparativa con otras soluciones de software orientadas a prototipado.

Aunque también pienso… ¿en serio Adobe? “¿la primera solución?” “¿Todo-en-uno?” “¿Para diseñadores UX?” Juzguen ustedes mismos.

Project Comet

La presentación de Project Comet tuvo lugar durante la conferencia inaugural de Adobe MAX. Sarah Hunt (@sarahwhatsup), senior product manager del proyecto, subió al escenario para mostrar ante los más de 7 mil asistentes al futuro nuevo integrante de la familia Adobe.

Adobe MAX

Sarah comentó que Project Comet contará con herramientas para wireframing y diseño de interfaces, en el modo “Design”, y permitirá crear prototipos, es decir, añadir interacciones, animaciones y gestos a las interfaces en el modo “Prototype”. Adicionalmente, será posible realizar una vista previa en tiempo real de la interfaz, directamente en dispositivos móviles.

Otra característica relevante es la posibilidad de compartir los prototipos con miembros del equipo o con stakeholders y permitir que realicen comentarios directamente sobre las interfaces.

Como es de esperarse, Project Comet promete trabajar de manera integrada con otros programas de la familia Creative Cloud de Adobe, como Photoshop e Illustrator, y optimizar el flujo de trabajo entre edición de imágenes y vectores con el desarrollo de interfaces y prototipos; Project Comet contará incluso con herramientas de dibujo vectorial.

Project Comet luce más o menos así en el modo “Design”:

Adobe Project Comet en modo "Design"
Adobe Project Comet en modo “Design”

Cada interfaz o artboard podrá diseñarse a partir de imágenes y objetos vectoriales, será posible crear tantos artboards como interfaces o dispositivos sean necesarios en el proyecto .

En el modo “Prototype”, podrá añadirse interacción y gestos a los elementos de cada artboard para definir los flujos de interacción.

Adobe Project Comet en modo "Prototyping"
Adobe Project Comet en modo “Prototype”

Para visualizar el prototipo en un dispositivo móvil, basta conectarlo y activar en Projet Comet la opción de “Preview”.

Adobe Project Comet en modo "Preview"
Adobe Project Comet en modo “Preview”

Fue todo durante la presentación. Se anunció que Project Comet estará disponible en 2016. Pueden ver el video completo de la conferencia inaugural aquí.

Haciendo un juicio crítico, Project Comet se queda corto en su promesa de ser una “solución todo-en-uno para diseñadores UX”. Por lo visto durante la presentación, Project Comet está dirigido a diseñadores de interfaz y de interacción responsables de la apariencia o look & feel de sitios web y apps que deben visualizarse en múltiples dispositivos, pero no cuenta con herramientas específicas para actividades como user research ó user testing, críticas en el ejercicio profesional de UX.

El principal atractivo con el que contará Project Comet para posicionarse en el mercado será sin duda la integración que ofrezca con Illustrator y Photoshop para optimizar el flujo de trabajo en el diseño de interfaces.

Project Comet librará una batalla complicada porque, afortunadamente y desde hace mucho, existe una cantidad considerable de herramientas relacionadas con actividades de UX, como wireframing, prototyping, user testing ó user research. ¿Cuál de ellas es la mejor herramienta de software para UX? La respuesta es, como siempre, depende.

El mercado de herramientas de software para prototyping

La competencia directa de Comet la representa un amplio abanico de herramientas que existen hoy día relacionadas con la creación de prototipos. La lista es larga: Axure, Briefs, Flinto, Fluid, Form, Indigo Studio, InVision, Justinmind, Marvel, Origami, Pixate, Proto.io y UXPin, por mencionar sólo algunas. Cada herramienta ofrece características distintas y decidir cuál de ellas preferir, no es nada sencillo.

Cooper.com ofrece un excelente recurso para comparar las diferentes soluciones para prototyping a través de una tabla dinámica en la que se muestran las principales características de cada software, es posible personalizar la tabla dependiendo del criterio de ordenación que se elija. Pueden consultar este recurso aquí.

comparativatools

Si pensamos en la sencillez con la que podemos aprender a utilizar una herramienta, Flinto o InVision son una excelente opción. Proto.io o UXPin son las herramientas con mayor curva de aprendizaje.

En cuanto a la fidelidad obtenida en un prototipo respecto a un producto real, Origami es una de las mejores alternativas, Justinmind o Pixate también ofrecen buenas características. HotGloo es una opción que no ofrece alto rendimiento respecto a fidelidad, pues se centra más en la creación de wireframes.

Cuando trabajamos en equipos multidisciplinarios o distribuidos en diferentes espacios físicos, o colaboramos de manera cercana con clientes y stakeholders, por lo que requerimos compartir nuestros prototipos para obtener feedback constante, definitívamente InVision es una de las mejores opciones. En este rubro, Origami no sería muy buena opción. Justinmind y Axure, por ejemplo, cuentan con un área para comentarios en la misma URL del prototipo, pero por alguna e inexplicable razón, muy pocas personas escriben ahí sus comentarios, al menos es mi experiencia.

Un caracterìstica clave para que una herramienta de prototyping realmente pueda ser llamada herramienta UX es contar con la capacidad de realizar user testing. Bajo este criterio, nuevamente InVision tiene una buena valoración, aunque Solidify se lleva el primer lugar según el análisis de Cooper y no es para menos, pues permite crear test en diferentes dispositivos, tanto de manera remota como de manera presencial, genera reportes y permite compartir la documentación con el equipo. Quizá su principal desventaja es la limitada cantidad de opciones para la creación de interfaces e interacciones. UXPin, la renombrada plataforma de diseño UX a quien le debemos tan buenos e-books, ha incorporado recientemente opciones de testing, aunque aún se encuentra en fase experimental.

Si pensamos en diseño exclusivamente para dispositivos móviles, quien se lleva las palmas es Justinmind, pues cuenta con interacciones específicas para mobile, desde taps, swipes y otros gestos touch; además, permite visualizar los prototipos directamente en un dispositivo. Las peores opciones son HotGloo y Briefs, pues no cuentan con características de este tipo.

Otro criterio importante para elegir una herramienta de prototyping es la versatilidad de sus widgets o elementos dinámicos. Indigo Studio obtiene la mejor valoración gracias a opciones como los screenparts, que permiten reusar partes de una interfaz en otra, así como la gran personalización en sus bibliotecas de widgets.

Aunque no se incluyen en el comparativo de Cooper, es súmamente importante considerar el uso de variables y condicionales para incrementar las posibilidades de interacción. Justinmind es quien podría tener las mejores prestaciones en ese sentido, los datamaster son verdaderas variables que permiten crear concatenaciones de cadenas de texto, operaciones lógicas y aritméticas, carga dinámica de datos, entre otras características.

Finalmente, hay una característica muy particular que sólo una herramienta ha sabido implementar y aprovechar: la documentación. UXPin permite mantener archivos de wireframes, mockups y prototipos junto con documentación UX, desde un Model Business Canvas, Personas, User Journey, listas de requerimientos, guías de estilo o cualquier otro tipo de archivo.

Cuando utilizamos otras herramientas de prototipado, generalmente optamos por soluciones como Trello o Google Drive para llevar el control de archivos de documentación.

Conclusiones

Ante tantas herramientas existentes, vuelta al mismo punto, ¿cuál es la mejor opción para crear prototipos? Bill Buxton, en su libro Sketching User Experience, responde así:

Un prototipo es un prototipo, independientemente de la tecnología que sea usada para implementarlo e independiente también de su relativa fidelidad con el producto real.

No perdamos el foco de identificar que el verdadero sentido de un prototipo es la validación de conceptos de diseño para aprender y mejorar de manera iterativa la solución del producto a desarrollar a través de la retroalimentación con el equipo, usuarios reales, clientes y stakeholders. De nada sirve emplear una herramienta sofisticada de prototyping si no validamos ni compartimos nuestro trabajo, “get out of the building!” como indica el principio de Lean Startup.

Diseñar la interfaz es centrarnos en el qué, pero la construcción de un prototipo ayuda a definir el cómo, el cuándo, dónde y el por qué del uso del producto.

Una última reflexión, Marc Rettig en un artículo llamado Prototyping for Tiny Fingers comenta:

Con paper prototyping (el proceso de construir prototipos con lápiz y papel), los diseñadores de interfaz pasan 95% de su tiempo pensando en el diseño y sólo el 5% en los mecanismos de la herramienta. Las herramientas de prototipado basadas en software, no importa lo bien ejecutadas que estén, revierten esta relación.

Privilegiemos siempre el proceso de diseño por encima de la herramienta de software, que al final es sólo eso: una herramienta.

Bienvenido Project Comet y bienvenidas todas las demás herramientas tambié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.

Sobre procesos cognitivos en UX

El diseño de UX no debe basarse sólo en estética; entender los procesos cognitivos de nuestras audiencias es clave en el diseño centrado en el usuario.

Hace un año en el Día Internacional de Usabilidad del año pasado (WUD 2014), que celebramos en UX Nights hablé del tema cognición y emociones, de los tres niveles de procesos cognitivos el usuario que plantea Donald Norman y de la  fricción cognitiva que tiene el usuario que plantea Alan Cooper.

En otros artículos he escrito sobre el énfasis en la medición y diagnóstico para las emociones, el diseño centrado en el usuario y sobre la importancia de la visualización de información. En los ejemplos expuestos hay en común distintos niveles de procesos cognitivos del usuario; en la interacción del usuario podemos describir y justificar la importancia de diseñar para mejorar la experiencia del usuario.

Empecemos con la definición de cognición:

Cognición (del latín: conoceré, “conocer”) es la facultad de un ser vivo para procesar información a partir de la percepción, el conocimiento adquirido (experiencia) y las características subjetivas que permiten valorar información.

La cognición consiste en procesos como el aprendizaje, el razonamiento, la atención, la memoria, la resolución de problemas, la toma de decisiones y el procesamiento del lenguaje. En la cognición existe una confirmación de un conjunto de señales que envían información.

Lo cognitivo es el acto de conocimiento y que concierne a la acción de almacenar, recuperar, reconocer, comprender, organizar y usar la información recibida a través de los sentidos.

Existen niveles en la complejidad de las operaciones cognitivas de un usuario mientras está interactuando con un sitio web, un sistema complejo o una app. Estos son algunos ejemplos:

  • El usuario procesa la información y realiza su organización y/o jerarquización. Se refiere al orden inicial para un primer acercamiento sensitivo, perceptual y cognitivo de la información.
  • El usuario genera una configuración, busca un orden coherente de los elementos que integran el sistema (factores estético-cognitivos y culturales).
  • El usuario genera una identificación, forma  parte  de  la  representación, pertenece distintos grados  nivel  de significación y sirve para referir a un objeto o concepto por medio de una imagen, sonido, texto.
  • El usuario hace una descripción, proporciona  información con o sin juicios de valor acerca del estado general de los contenidos con los que interactúa.
  • El usuario realiza una instrucción, realiza indicaciones de cómo solucionar un problema específico con acciones secuenciales.
  • El usuario se orienta, determina el entendimiento de un espacio y su representación en la interacción que realiza con el sistema o artefacto con el que está interactuando.
  • El usuario puede ser muy interactivo o no, por lo que se espera que tome decisiones.
  • El usuario busca constantemente una explicación y busca entender situaciones complejas. Trata el entendimiento del funcionamiento, causas y efectos de una acción, centrándose en las acciones y relaciones interactivas.
  • Están los procesos cognitivos del usuario en la parte de operación con retroalimentación directa mientras está interactuando con una interfaz gráfica de usuario o un artefacto por medio de otras interfaces interactivas.
  • El proceso de datos en la interfaz gráfica le permite al usuario comparar   escenarios y posibilidades en la toma de decisiones.
  • En la argumentación, espacio socio-cognitivo que se fundamenta en juicios de valor se espera que el usuario se convenza y defienda una posición.

Nathan Shedroff (1994) sugiere que el diseño de interacción de la información es la confluencia de pautas como el diseño de información, el diseño de interacción y el diseño sensorial.

Estas categorías permiten llegar a la intersección entre el diseño de información, la interacción de diseño, diseño sensorial y otras para generar el diseño de la arquitectura de información y de distribución de contenido.

El  diseño de información es una guía para la organización y presentación de datos, así como para su transformación en información selectiva que sea significativa para el usuario.

Los procesos cognitivos de la creación y narración van involucrados en el diseño de interacción, mientras que en el diseño sensorial se utilizan todas las vías de entrada que utilizan los órganos de los sentidos: táctil, visual, kinestésico, auditivo y olfativo. Como se plantea en la definición de cognición, el conocimiento adquirido (experiencia) y características subjetivas permiten valorar la información para procesarla a partir de la percepción.

El  diseño de información no sustituye al diseño visual; sino que hace notar una estructura en la cual la información no es el fin de un continuo entendimiento, sino que los datos que se generan pueden ser convertidos en información significativa que a su vez se convertirá en conocimiento, completando uno de los ciclos de los procesos cognitivos que el usuario va a realizar.

Es importante recordar que al hablar de información los datos sí mismos no proporcionan información relevante y no tienen un valor hasta que conforman un mensaje completo para el usuario. Para que se lleve a cabo este proceso de comprensión debe utilizarse el diseño de interacción y la creación de experiencias.

En el diseño de la experiencia de usuario es necesario conocer a la audiencia, sus necesidades, intereses, habilidades, etc. Parece sobrado mencionarlo, pero sigue siendo un problema muy recurrente al momento de diseñar y desarrollar un sistema o una interfaz.

Los  dos primeros niveles están enfocados en el control que tiene el usuario sobre el resultado, la secuencia o el tipo de acción, así como qué tanta retroalimentación existe en la interfaz. Normalmente las experiencias con alta interactividad ofrecen mayores niveles de retroalimentación.

Hay más detalle sobre el modelo de diseño de interacción e información que plantea Nathan Shedroff en su sitio web.

Information Interaction Design: A Unified Fiel Theory of Design. Imagen tomada de www-scf.usc.edu
Information Interaction Design: A Unified Fiel Theory of Design. Imagen tomada de www-scf.usc.edu

La importancia de la interacción y los procesos cognitivos para el mejoramiento de la experiencia de usuario.

Hay que tomar en cuenta el diseño centrado en el usuario, la usabilidad, la accesibilidad, la percepción y el entorno entre otros factores para crear sitios web de forma diferente. Antes de que el cliente (y nosotros) comprendiéramos el valor del procesos cognitivos del usuario en el diseño centrado en el usuario, normalmente, – aunque no siempre– tomábamos decisiones de diseño y desarrollo en base a dos criterios: lo que pensábamos que era creíble y lo que el cliente quería ver.

Construíamos interacciones basadas en lo que pensábamos que funcionaba y diseñábamos para nosotros mismos. Nuestra atención se centraba en la estética y en la marca, con poca o ninguna idea de cómo la gente utilizaría la página web o cómo se sentiría mientras la usaba. Es ahora cuando debemos tomar en cuenta que el diseño y desarrollo debe estar centrado en el usuario como parte clave del proceso de diseño de la experiencia de usuario.

Referencias

Diseñadora gráfica y psicóloga especializada en diseño editorial e hipermedios, ha sido investigadora y consultora en usabilidad, user experience y diseño emocional desde 2007.

La fábula del diseñador centrado en el usuario

“Érase una vez un joven brillante que estaba buscando a un diseñador efectivo. No buscaba un diseñador cualquiera, quería encontrar uno que diseñara tecnologías complejas que fueran simples de usar. Quería trabajar y aprender con él para convertirse en uno de ellos”.

La “fábula del diseñador centrado en el usuario” es el viaje de un joven que descubre los tres secretos del Diseño Centrado en el Usuario (UCD). David Travis un reconocido investigador y consultor de usabilidad escribió esta sencilla pero profunda historia inspirado en el popular libro The One Minute Manager en el que se abordan los consejos que recibe un joven para convertirse en un buen gerente. Travis utiliza la misma alegoría pero llevada al terreno de User Experience.

Después de conocer la naturaleza de User Experience como disciplina y de entender la filosofía de Diseño Centrado en el Usuario, el siguiente paso es descubrir cómo llegar a ser un diseñador centrado en el usuario. La lectura de este libro y la comprensión de los conceptos que enuncia es un buen principio para convertirse en un diseñador centrado en el usuario.

* * *

El viaje del joven de la historia inicia cuando se pregunta ¿cómo se diseña tecnología?, porque lo que veía a su alrededor no siempre le parecía adecuado. Así comenzó preguntándole a todos los diseñadores que encontraba en su camino: “¿qué tipo de diseñador diría que es usted?”.

Las respuestas que escuchó lo dejaron intrigado, ya que parecía que la mayoría de los diseñadores, sólo hacía una parte del trabajo, a veces preocupados por la estética de la interfaz, otras por los intereses del cliente y a veces sólo por la innovación tecnológica. “Es como si sólo fueran parte de un diseñador”, reflexionó el joven.

Cuando la desesperanza comenzó a hacer mella en nuestro intrépido y aguzado amigo, escuchó rumores sobre un diseñador muy especial que vivía en un pueblo cercano. Después de algunos esfuerzos ambos llegan a estar frente a frente, y lo que nuestro joven diseñador hizo fue hacerle la misma pregunta:

– “¿Qué tipo de diseñador diría que es usted?”
– “Soy un diseñador centrado en el usuario”, respondió el otro.

El joven estaba intrigado, así que preguntó: “¿entonces qué haces?” El diseñador centrado en el usuario le respondió que para averiguar la respuesta tendría que preguntárselo a sus clientes, así que le proporcionó los datos de tres de ellos y lo mandó a conocerlos. Sólo le impuso una condición: después de tener la respuesta en sus manos, debería compartirla con otros. El joven dio su palabra que así lo haría.

Primer secreto del diseño centrado en el usuario

El joven conoció al primer cliente del diseñador centrado en el usuario, quien le contó acerca de lo desconcertante que resultó trabajar con él cuando inició el proyecto porque no se interesó de manera inmediata en el diseño visual o en la innovación tecnológica.

Él hablaba de nuestros clientes”, dijo. El joven se sorprendió y preguntó inmediatamente: “¿Y eso cómo ayudó?” El cliente respondió que eso les permitió descubrir que ellos realmente no conocían cómo las personas usaban su producto.

– “¿Y qué hizo el diseñador centrado en el usuario para ayudar?” — preguntó el diseñador con curiosidad.
– “Su primer paso fue identificar a los usuarios de nuestro sistema y saber qué querían hacer con él” — replicó el cliente.

Primer secreto del diseño centrado en el usuario: Hay que enfocarse desde el principio y continuamente en el usuario y sus tareas

Es así como Travis revela el primer secreto del diseño centrado en el usuario: conoce a tus usuarios, sus tareas y el entorno de uso. Este descubrimiento debe originarse de la investigación y no de la suposición: suponer es bueno, pero averiguar es mejor.

Otro concepto clave es identificar “rutas rojas”: aquellas tareas críticas que el usuario realizará y que deben diseñarse de la forma más eficaz y eficiente posible. Al enfocarse en las rutas rojas se evita que otras funcionalidades menos importantes desordenen la interfaz.

Después de que el joven diseñador conoció el primer secreto de UCD, se despidió del cliente y partió. Al reflexionar sobre lo que había aprendido pensó “realmente tiene sentido. Después de todo, ¿cómo puedes ser un diseñador efectivo si no sabes para quién estás diseñando o lo que la gente hace con el producto que estás creando?”.

Segundo secreto del diseño centrado en el usuario

El viaje del joven diseñador lo llevó con el segundo cliente. Al terminar las respectivas presentaciones le preguntó sobre el siguiente paso después de enfocarse en el usuario y sus tareas

– “Se necesita garantizar que el diseño funcione tal y como los usuarios esperan”, respondió el cliente.

El diseñador centrado en el usuario había ayudado al segundo cliente a realizar pruebas de usabilidad a un producto, pidió a un grupo de usuarios realizar ciertas tareas específicas y a expresar en voz alta sus pensamientos y emociones al interactuar con el producto. Esto le permitió obtener las tres métricas básicas de la usabilidad:

  • Efectividad, medir cuántos usuarios logran completar con éxito una ruta crítica.
  • Eficiencia, medir cuánto tiempo tardan los usuarios en realizar la tarea.
  • Satisfacción: medir cómo se sienten los usuarios respecto al diseño del producto.

Segundo secreto del diseño centrado en el usuario: hay que medir de forma empírica el comportamiento del usuario

El joven nuevamente quedó fascinado por el descubrimiento: “¡cierto!, ¿cómo se puede ser un diseñador efectivo si no se sabe cómo usa el usuario su diseño?” reflexionó. Sin embargo, una duda lo intrigaba:  “después de realizar sus pruebas,  ¿siempre se encuentran problemas con el producto?

– “Siempre” — respondió el cliente.
– “¿Y luego de arreglar los problemas ustedes siempre tienen que volver a probar el sistema?”, preguntó el joven.
– “Exacto” — dijo el cliente.
– “Pero eso debe tomar mucho tiempo…” — dijo el joven.
– “Creo que ya es hora de que averigües acerca del tercer secreto del diseñador centrado en el usuario”, concluyó el cliente.

Tercer secreto del diseño centrado en el usuario

Finalmente, el joven diseñador llega con el tercer cliente a quien le dice: “he estado oyendo sobre las pruebas de usabilidad. Parece que tienen mucho sentido, pero me preocupa que consuman demasiado tiempo”.

El cliente le explica que el Diseño Centrado en el Usuario define una técnica que permite probar nuevos diseños muy rápido, llamada prototipos en papel. A través de los prototipos en papel es posible validar conceptos de alto nivel, como la arquitectura de información; posteriormente, los prototipos digitales permitirán refinar otros aspectos, como el diseño visual.

Para lograr un buen diseño hay que generar muchas ideas tan rápido como sea posible para validarlas con usuarios: “no puedes tener correcto el diseño hasta que tienes el diseño correcto”, le dijo el tercer cliente al joven diseñador.

Tercer secreto del diseño centrado en el usuario: el diseño debe ser iterativo

El diseñador se sorprendió al conocer el tercer secreto: todo parecía tan claro y obvio, ¿cómo se puede ser un diseñador efectivo si solamente se diseña una vez sin validar, corregir y volver a validar?

Despues de reflexionar un poco, el joven se cuestionó: “¿por qué hay tan pocas compañías que diseñan de esta forma?”.

El tercer cliente sonrió y dijo: “vamos a dejar que le hagas esa pregunta al diseñador centrado en el usuario”, y se despidió.

* * *

La fábula termina con el reencuentro entre el joven y el diseñador centrado en el usuario. Al cuestionarlo sobre por qué muchas empresas no llevan a cabo los tres secretos, el diseñador centrado en el usuario responde: “la mayoría de las compañías creen que están centradas en el usuario, pero cuando les preguntas a sus clientes muy pocos están de acuerdo”.

Muy pocas empresas dedican el esfuerzo necesario en conocer a sus usuarios, tareas y entorno de uso de manera continua. Algunas compañías realizan investigación de sus productos, pero usualmente a través de actividades como focus groups, y eso no es suficiente.

Con productos interactivos lo que importa no es lo que los usuarios dicen, lo importante es lo que hacen. Las actividades como los focus groups no ayudan a encontrar los problemas del producto, por eso es que se deben realizar pruebas de usabilidad con métricas sólidas y bien definidas.

Prácticamente ninguna compañía realiza un proceso de diseño iterativo: se tiene la idea errónea que si cada iteración implica diseñar, validar con usuarios e implementar mejoras nunca se van a lograr cumplir tiempos de entrega, se reventará al presupuesto o que se verán limitados con sus recursos humanos disponibles.

Todo es un asunto de administración del riesgo: se involucran usuarios siempre que haya que tomar decisiones importantes sobre el diseño. Hay otras técnicas que se pueden usar de forma paralela a las pruebas de usabilidad, como la revisión por un experto, aunque éstas nunca reemplazarán por completo una prueba de usabilidad.

Después de asimilar todos estos principios y de ponerlos en práctica durante un cierto tiempo, ocurrió lo esperado, el joven se convirtió en un diseñador centrado en el usuario.

El joven diseñador nunca olvidó la promesa que hizo y a partir de ese momento compartió con todos sus colaboradores y clientes las lecciones que aprendió del diseñador centrado en el usuario.

Espero que todos podamos honrar la misma promesa.

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.