Experiencia de Usuario (UX) y un mundo a escala humana. Por Nelson Rodríguez-Peña
Hola, soy Nelson Rodríguez-Peña. Éste es el factor humano, mi antiguo blog sobre temas relacionados a la experiencia de usuario y diseño web. Lo mantuve activamente entre 2004 y 2008, puedes revisar el archivo y ver algunos de los artículos que publiqué en esa época. Hoy lo mantengo publicado, pero inactivo.
Si te interesa, puedes leer lo que estoy escribiendo estos días en mi sitio actual, nelsonrp.com.
Hace unos días leía en «8 habits of veteran UX designers» en The Next Web, un párrafo que me llamó la atención. Se trata de la importante distinción entre patrones de interacción y tendencias.
(…) it can be difficult to discern a trend sneaking into mainstream design when it becomes ubiquitous. Overtime, popular trends have potential to morph into established patterns, but that isn’t always the case.
La diferencia entre patrones de interacción y tendencias es clave. No distinguirlos correctamente puede ser el origen de importantes problemas en la usabilidad de un sitio o sistema.
Un patrón de interacción es una solución comprobada —no sólo por uso, sino por observación, comprobación y documentación—, para un problema común en la interacción entre un usuario y una interfaz. Se puede tratar de un patrón para una interacción simple —como el menú de rastros— o de una interacción compleja —como la reserva de vuelos u hoteles.
Una tendencia —o trend— es una moda, una práctica relativamente extendida, que no necesariamente resuelve un problema, pero que es adoptada por razones estéticas, por disponibilidad —es de fácil acceso— o por la creencia, no necesariamente justificada, de que resuelve un problema —¿carrusel, me escuchas?
La adopción irreflexiva de tendencias puede introducir nuevos problemas, en lugar de resolverlos, pero también es posible que una tendencia que resuelve problemas reales se convierta en un patrón.
En general, existe coincidencia en las ventajas del uso de patrones de interacción, así como muchos patrones documentados y librerías, pero eso no es garantía de que estén libres de tendencias que aún no se han consolidado como patrones.
Lo recomendable, finalmente, es tomar cada uno de estos elementos —patrones y tendencias— con una pausa para distinguir cuál es el problema que buscan resolver y, en lo posible, probar con usuarios si efectivamente los resuelven.
(Imagen principal: patrones de interacción de MailChimp)
Más allá de lo notable de Margaret Hamilton por ser una de las mujeres pioneras en tecnología, por su rol en la definición del software moderno o por su participación en el Programa Apolo de la NASA, hay una anécdota que es una joya, al menos desde la perspectiva de la usabilidad.
En la época en que Hamilton trabajaba programando las computadoras del proyecto Apolo —una para la navegación Tierra-Luna, Luna-Tierra y la otra para el módulo lunar— la disponibilidad de recursos era espartana: se programaba en tarjetas perforadas y con capacidades de memoria muy limitadas.
El sistema de navegación a bordo —una de las computadoras en que trabajaba Hamilton— tenía instrucciones de vuelo que permitían el viaje de ida y vuelta de la Tierra a la Luna. Parte de la memoria estaba programada en duro o hard-wired —literalmente, con alambres de cobre—, la otra parte era una memoria temporal, muy limitada.
El 26 de diciembre de 1968, a cinco días del despegue del Apolo 8, que llevaría a la primera tripulación a la Luna, ocurrió un incidente que borró la memoria de la computadora de navegación, dejando sin instrucciones de retorno a la nave. Los astronautas no podrían regresar a la Tierra.
¿Cuál fue el origen del error? Durante las pruebas del software en los simuladores, Hamilton notó que era posible activar ciertos programas o instrucciones fuera de contexto, como por ejemplo una rutina de prelanzamiento llamada «P01». El equipo de Hamilton reportó el potencial problema a NASA, pero dada la limitación de recursos de memoria y procesamiento, no incluyeron un mecanismo de prevención, porque los astronautas eran entrenados para ser perfectos y no cometerían errores. Así que lo agregaron a la documentación: «No seleccione P01 durante el vuelo».
Pero ocurrió lo obvio: el astronauta Jim Lovell, pese al entrenamiento para ser perfecto y a la documentación del sistema, activó accidentalmente el programa P01, que borró la memoria de navegación.
Pongamos las cosas en perspectiva: los astronautas del Apolo 8, viajaban por el espacio en un tarro de lata, sin instrucciones de navegación. A la deriva.
Sitting in a tin can, far from the world.
Luego de 9 horas, el equipo de ingenieros —incluyendo a Hamilton—, tenían una solución que «subirían» al Apolo 8 para corregir el problema. El error logró ser corregido, los astronautas pudieron regresar.
Pues bien, esto es un ejemplo magistral de errores en principios básicos de usabilidad, en particular en sistemas críticos: evita que el usuario cometa un error, antes que tomar medidas correctivas cuando ya lo ha cometido. De hecho, es uno de los 10 heurísticos de Nielsen y Molich:
Error prevention
Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.
Prevención de errores
Mejor que buenos mensajes de error, es un diseño cuidadoso que prevenga que un problema ocurra. Elimine condiciones susceptibles de error o verifíquelas y presente a los usuarios opciones de confirmación antes de completar la acción.
Así que lo podemos decir con propiedad, la usabilidad es rocket science.
Si quieres conocer más de Margaret Hamilton, hay un gran artículo en Wired —donde aparece esta anécdota— y una entrevista en El País.
(Créditos de imagen: NASA, vía Wikimedia Commons)
Comencemos por lo primero: ¿qué es Experiencia de Usuario? Aunque se puede definir desde diferentes perspectivas, podemos decir que se trata de un enfoque en el diseño de productos —en gran medida digitales, aunque no restringido a ellos— que se basa en la investigación de las necesidades y comportamiento de los usuarios para crear productos que, a la vez de ser funcionales, generan satisfacción en sus usuarios.
El concepto de Experiencia de Usuario —o User Experience, en inglés—, es relativamente nuevo. Digo relativamente, porque su uso extendido se observa recién desde los últimos 10 años.
El término, sin embargo, tiene una historia más extensa. Ya a mediados de los ’90 Donald Norman, mencionaba la «Experiencia de Usuario» y la describía como la forma en que
(…) cover some of the critical aspects of human interface research and application.
cubrimos algunas de los aspectos críticos de la investigación y aplicación de la interfaz humana.
What You See, Some of What’s in the Future, And How We Go About Doing It, Don Norman, Jim Miller, Austin Henderson
Esto como parte de los debates de CHI ’95 y en relación a su trabajo en Apple.
Otro hito relevante es la publicación en 2002 de «The elements of user experience» —Los elementos de la experiencia de usuario—, de Jesse James Garrett, que ordena la serie de disciplinas que se relacionan con la experiencia de usuario y lo visualiza en un conocido diagrama (PDF).
Pero no fue sino en 2005 cuando el concepto de User Experience comienza a tomar vuelo por sí mismo. El contexto era el rebote luego del desastre de las «.com» y la emergencia de la llamada «Web 2.0».
De hecho, en 2005 Garrett acuña el concepto de «Ajax», parte central de la web 2.0 y Adaptive Path —de la que Garrett es co-fundador— organiza la primera UX Week. De ahí en adelante, la UX fue mainstream.
UX week de 2005, foto © Jared Spool
Quizá la señal más potente de lo que el concepto UX traía a la industria, fue el reconocimiento de la Usability Professionals Association —UPA—, una de las organizaciones profesionales con un perfil más académico, que en 2012, luego de una extensa y compleja discusión extensa, cambia su nombre a User Experience Professionals Association, UXPA.
Esto fue polémico y causó la irritación de las otras asociaciones y disciplinas profesionales, que acusaron a la UXPA de oportunismo, de monopolizar un concepto que incluía también a los profesionales de la Arquitectura de Información o el Diseño de Interacción.
Hubo reacciones indignadas de notables miembros de la comunidad, como Louis Rosenfeld, con su respuesta a la «Carta abierta a la comunidad de Experiencia de Usuario», con que Rich Gunther, Presidente de UPA a la fecha, anunciaba el cambio a UXPA.
Pero el concepto continuó extendiéndose, al punto que hoy es un concepto establecido y parte de la descripción laboral de muchos profesionales y equipos.
Al día de hoy, ya es un nombre establecido, difundido y, hasta cierto punto, comprendido por practicantes y clientes.
La pregunta de rigor es: ¿por qué «User Experience» se impuso por sobre las etiquetas previamente existentes? Creo que son dos las razones principales:
Hasta antes de asimilar masivamente el concepto de UX, hablábamos de usabilidad, arquitectura de información, diseño de interacción, diseño de interfaces, diseño visual, etc. Si bien existen diferencias entre las diferentes disciplinas, el tener una visión unificada del resultado, y una cierta visión sobre el proceso, tiene ventajas. Ha contribuido a entender que cada disciplina aporta al resultado, y que el resultado es mucho más que sólo la suma de las disciplinas.
Hasta antes de que se acuñara y se asimilara la UX como concepto, abundaban los nombres para describir procesos y resultados similares. Pero la confusión para los clientes era grande. Y el esfuerzo para intentar explicar lo que proponías a un cliente, era mayor.
De hecho, las etiquetas para las descripciones laborales reflejaban esa confusión: podías ser un Arquitecto de Información, Experto en Usabilidad o Diseñador de Interacciones, pero en la práctica hacías lo mismo, o cosas muy similares. O las hacías todas en diferentes momentos.
En suma, el concepto de Experiencia de Usuario ha venido a resolver un clásico problema de significante y significado, en el que teníamos un contenido —las disciplinas, métodos y procesos—, pero no había un denominador que facilitara su comunicación.
UX ha facilitado eso. Claro, ahora surgen otros problemas, como la de-significación del concepto —ya se quejaba de ello Norman en 2007 en una entrevista con Peter Merholz— o la trivialización de la práctica, pero esas son otras batallas.
Este es un tema que he venido masticando desde hace tiempo, pero no había tenido el tiempo de escribir. Excede el espacio de la interacción humano-máquina, o el diseño de experiencias de usuario, pero de todos modos las incluye.
Se trata de la incursión de los «vehículos inteligentes», es decir, vehículos controlados por software en lugar de conductores humanos. La idea parece fabulosa y casi de ciencia ficción. Pero tiene un punto complejo.
Y es que los vehículos inteligentes deben ser programados para tomar decisiones que involucran, eventualmente, la muerte. Son situaciones externas, no controladas, pero que requieren de acciones inmediatas, instantáneas.
En una situación extrema, pero totalmente posible, un vehículo inteligente debe determinar cuál es la pérdida menor. Imaginemos un escenario en el que sólo hay dos opciones posibles: A o B. Si decide A, hay riesgo de muerte de una persona, si decide B, morirán dos personas. No hay más opciones, no hay espacio para frenar lo suficientemente rápido y evitar que haya víctimas. ¿Qué deberá decidir, la muerte de una o de dos personas? Traducido a un algoritmo, es una decisión simple, incluso considerando la dimensión ética.
Actualmente esas decisiones las toman personas, que —de un modo u otro—, son responsables por sus actos, independientemente de lo imperfecto de la aplicación de las sanciones que derivan de ellas.
¿Qué decidiría una persona? ¿Optaría por A, la muerte de una persona, o B, la muerte de dos? ¿Tendrá la lucidez de evaluar las consecuencias?
Extrememos el caso: las opciones ya no son sólo A —muere una persona— o B —mueren dos personas—, sino que hay una opción C, en la que el conductor puede evitar que mueran otras personas, pero eso impone un alto riesgo de muerte para el conductor. La decisión que pueda tomar una persona dependerá de su estándar ético: me salvo a expensas de la muerte de otros, o salvo a los demás y me sacrifico.
Todo esto, finalmente, es un problema del espacio de la ética. La discusión teórica de estos puntos me parece completamente necesaria y razonable. La aplicación real de esto es lo que me preocupa.
Si tomamos como ejemplo el caso de Volkswagen —sólo por nombrar uno notorio, aunque no único—, llegamos a un espacio en el que todas las disquisiciones éticas quedan sometidas a decisiones comerciales. Se trata de una compañía en la que se incorporaron medidas, en la forma de software, para contravenir la normativa ambiental sobre emisiones de gases. Es decir, la compañía optó por el beneficio comercial, antes que por el bien común —o el cumplimiento de la ley.
¿Cómo se comportarían las compañías en el escenario de incorporar decisiones de vida o muerte en los vehículos «inteligentes»? ¿Qué harán en un caso como el planteado? Es fácil suponer que un vehículo inteligente, ante una situación extrema, opte por el número menor de víctimas. ¿Pero qué ocurrirá cuando hay una opción C, donde la persona a sacrificar es su cliente? No me cuesta mucho imaginar esto como un argumento de venta, aunque sea velado: «siempre lo salvaremos a usted», «vehículos más seguros para usted». Ciertamente habrá clientes dispuestos a garantizar su seguridad por sobre la de otros.
Para concluir, me queda claro que este tipo de situaciones no las puede decidir el mercado, que ha demostrado que las compañías anteponen el beneficio propio al bien común, sino que deben ser reguladas y controladas por toda la sociedad. Pero eso no garantiza que las compañías cumplan con la regulación, ¿o no Volkswagen? Permítanme el escepticismo.
(crédito de imagen: Nathan Rupert)
El concepto de web semántica no es nada nuevo, de hecho es tan antiguo como la propia web. Ya en las primeras versiones de HTML (1993), se definen elementos semánticos que permiten establecer relaciones entre recursos o documentos, —el elemento link con el atributo rel, por ejemplo—, así como elementos estructurales que permiten definir una jerarquía interna a cada documento HTML —como los títulos h1 a h6.
Todos sabemos lo que ocurrió luego, en los primeros años de la web: la irrupción masiva de Internet con la guerra de los browsers, nos llevó a la pérdida de muchos de los principios semánticos. Pero la idea siempre ha estado presente.
En 2001 Tim Berners-Lee publicó The Semantic Web, planteando la necesidad de otorgarle una estructura semántica al contenido de la web, que facilitara la relación entre el contenido y mejorara el funcionamiento de los buscadores. La visión de una nueva forma de contenido web, que es significativa para los computadores, liberará una revolución de nuevas posibilidades
, pero su despliegue ha tardado en producir suficiente tracción.
En el camino surgieron iniciativas como microformatos, que ante la falta de estándares semánticos, buscaban agregar una capa de significado directo en HTML. Aunque tuvo bastante aceptación en ciertos círculos, nunca tuvo un uso predominante.
Pero la necesidad de darle significado al contenido sigue presente. El problema de fondo es el incentivo: ¿Cuál es el beneficio directo de describir semánticamente contenido para quienes producen esa información? ¿Quién será capaz de valorizar el contenido, su significado y sus relaciones? En otras palabras: ¿Cómo gano con esto?
Pues bien, en el momento en que los grandes actores del mudo del web comienzan a valorar el contenido estructurado y descrito semánticamente, el beneficio potencial comienza a hacerse concreto. Me refiero a Google, Microsoft, Yahoo y Yandex, con el proyecto Schema.org.
Schema.org es un esfuerzo conjunto para generar ontologías de diversos espacios de conocimiento —aunque las llaman esquemas o vocabularios—, que permite a los productores o publicadores de contenido describirlo de modo que los buscadores —en primera instancia— puedan identificarlo con precisión. Esto es precisamente a lo que se refería Berners-Lee en su escrito del 2001.
Lo que busca un proyecto como Schema.org es precisamente producir ese beneficio directo: mayor precisión en las búsquedas, es decir, mejor posicionamiento y relevancia. Gana el buscador entregando un mejor servicio, el usuario al obtener mejores resultados y los publicadores de contenido o servicios al ser encontrados con mayor facilidad.
Las ontologías de Schema.org incluyen un conjunto de vocabularios para tipos como Eventos, Organizaciones, Personas, Productos, etc., que pueden ser integrados al HTML de un sitio mediante microformatos, RDFa o JSON. El conjunto de esquemas está en crecimiento y hay colaboración de múltiples participantes, en lo que parece ser un proyecto saludable.
Lo dejo hasta acá por ahora, si aún no lo conocen, den una mirada a Schema.org.
HTML5 pone a disposición una serie de API que permiten mejorar la experiencia de usuario, agregando funcionalidades que hasta hace poco sólo estaban disponibles para aplicaciones nativas en móviles.
Geolocalización y notificaciones son ejemplos de ellas. Si embargo, requieren de aprobación del usuario para hacerlas disponibles a cada sitio. Eso está bien, es protección de la privacidad, nadie quiere que un sitio registre indiscriminadamente su posición sin una autorización de por medio.
En el caso de las notificaciones, para algunos sitios web es un muy buen complemento contar con la posibilidad de agregar avisos nativos del sistema. Si usas Gmail, probablemente has autorizado el uso de notificaciones de escritorio, con lo que ya te has familiarizado con la funcionalidad de esta API.
Todo esto, para comentar un muy buen ejemplo con el que me crucé hoy, de manejo de las preferencias de notificaciones. La cosa va así: para poder mostrar notificaciones, un sitio debe pedir autorización al usuario. Este proceso lo maneja el navegador, junto con las preferencias para revocar o aprobar el permiso. Como cada navegador lo maneja de modo diferente, es complejo soportar estos flujos.
Pero Facebook lo maneja de modo muy interesante.
En primer lugar, si rechazas que el sitio utilice notificaciones, Facebook muestra un mensaje justo bajo el candado de la URL —esto al menos en Chrome—, informando que puedes modificar las preferencias de uso de notificaciones desde este lugar.
Si pinchas el candado asociado a la barra de ubicación, el navegador despliega las preferencias de privacidad, entre las cuales se encuentran los permisos, uno de ellos corresponde a Notificaciones.
En suma, si vas a usar las API de notificaciones o de geolocalización, cuida estos detalles, que son una parte importante de la experiencia de usuario.
Las metodologías ágiles y lean responden a una serie de necesidades del desarrollo de productos digitales, pero principalmente a tiempos breves para el diseño, producción y lanzamiento. Simplificando al máximo, tanto en lean como en agile se busca minimizar el riesgo y salir rápidamente con un producto.
Eso me parece perfecto. Sin embargo, esto se hace normalmente a expensas de una buena investigación de usuarios y de un foco excesivo en el desarrollo de software —en el caso de agile— o en la gestión de un producto —en el caso de lean.
Respecto a agile, En Nielsen & Norman lo plantean como:
Agile teams are more proficient in executing the development process, but the compressed timescale forces some to abandon user research and degrade the resulting user experience
Los equipos ágiles son más productivos ejecutando el proceso de desarrollo, pero las escalas de tiempo comprimidas fuerzan a algunos a abandonar la investigación de usuarios y degradan la experiencia de usuario resultante
Ese mismo foco en el desarrollo, hace que los problemas de ingeniería se sobredimensionen en relación a los demás. En lugar de investigar y desarrollar estrategias basadas en el conocimiento de los usuarios, se escribe software.
Lo curioso es que lean, que tiene el eje desplazado hacia el diseño y gestión de productos, también tiende a cometer el mismo error. La lógica de comenzar construyendo antes de investigar, tampoco permite definir una estrategia que permita guiar un proceso de investigación, evaluación y aprendizaje. En Cooper comentan acerca de esto así:
Tuitea estoFraming the problem before you start solving it is not only wise, but major opportunities for innovation often arise before anyone proposes a design solution.
Definir el problema antes de comenzar a resolverlo no sólo es sabio, sino que grandes oportunidades de innovación surgen frecuentemente antes de que alguien proponga el diseño de una solución.
Por lo mismo, e independientemente de si trata de un entorno agile o lean, realizar investigación de usuarios y definir una estrategia —o al menos hipótesis informadas— al inicio, es lo más razonable. En Cooper proponen un modelo que cambia el «Build – meassure – learn» de lean, por «Learn – build – meassure», que busca incorporar más espacio para la investigación. Esto cambia el modelo y contribuye a diseñar y construir de un modo más informado.
En cualquier caso, creo que además de integrar tanto perfiles, como actividades asociadas al diseño de la experiencia de usuario, se debe comenzar investigando y trabajando con usuarios. Si no, el riesgo de no acertar con las expectativas de tu cliente/usuario será mayor.
El uso de personas como herramienta en el diseño de interacción y el diseño de experiencia de usuario no es algo nuevo. Alan Cooper lo describió en 1998 en su clásico «The inmates are running the asylum» y en adelante los detalles sobre su uso y aplicación abundan.
Personalmente he usado personas en muchas oportunidades, pero hace poco una modificación en la forma de presentarlas generó un importante impacto en un proyecto.
Todo partió con la integración de técnicas ágiles de definición de personas —eso será otra historia. El trabajo de definición fue gradual, en la medida que obteníamos más información sobre nuestros usuarios, a partir de la investigación de diversas fuentes.
El cambio ocurrió en el momento en que pensaba en cómo producir un impacto mayor con las personas en las que estábamos trabajando. ¿Cómo hacer que el equipo técnico se interiorizara realmente con este grupo de usuarios representativos, y lograran empatizar con sus necesidades?
¿Por qué no invitarlos a la presentación?
, pensé.
Y comencé a bocetar algunas ideas de cómo hacerlo. La idea fue incluir una imagen representativa para cada una de las personas definidas, con su historia y necesidades, en un formato impreso que pudiera ser plegado y ubicado en la mesa de reunión y después en los escritorios.
Adaptamos el formato que teníamos para las personas y el resultado es el de la foto. Durante la presentación con todo el equipo, en el momento preciso, sacamos las piezas y las distribuimos en la mesa. El resultado fue notable: los participantes comenzaron a mirarlos, revisarlos y a familiarizarse con ellos. Los nombres y características quedaron grabados y permitió que se comenzara a hablar de nuestras personas como los destinatarios reales del proyecto.
El aprendizaje detrás de esto es simple, pero potente: contamos con muchas herramientas para describir nuestro trabajo, pero a veces es necesario pensar en cómo socializarlo, cómo acercarlo a los demás para que tengan un impacto real.
Hace unos días escribí acerca de los wireframes y la necesidad de reducir la documentación en los proyectos de UX. Y aunque me concentré en hablar de los wireframes, no se trata de condenarlos al olvido ni de negar su utilidad. De lo que se trata es de optimizar los procesos de trabajo y mejorar la comunicación entre equipos.
El problema es el siguiente: los wireframes documentan un sistema interactivo o de información en un momento determinado. E incluso en un estado determinado.
Un momento porque los wireframes son la foto de una etapa en el desarrollo del sistema. Pero sabemos que los sistemas son dinámicos y evolucionan permanentemente. La documentación que los describe, del mismo modo, debe ser actualizada o queda obsoleta. Esto es un esfuerzo que, con el dinamismo que se requiere cada vez más, se hace difícil.
Además, los wireframes sólo son capaces de representar un estado de una interfaz a la vez. Pero también sabemos que los sitios y aplicaciones tienen muchos estados diferentes.
Así, los wireframes no son capaces de evolucionar junto a los sistemas que documentan, ni son capaces de representar todos sus estados. Por lo mismo, no siempre son efectivos en su resultado —documentar y comunicar un sistema— o eficientes en su ejecución —considerando el tiempo y esfuerzo que requieren.
Otro aspecto del problema, es que en un proyecto interactúan diferentes equipos, con objetivos y necesidades particulares. La comunicación entre ellos y la forma en que ésta se produce, varían según la relación que tengan los equipos y la naturaleza de los proyectos.
¿Cuáles son las alternativas?
Las opciones son varias, pero existen diferentes escenarios:
Por sobre todas estas consideraciones y escenarios, debemos tener presente que el tiempo disponible para los proyectos es reducido y en muchos casos la competencia y la carrera por el time-to-market son críticos. Con lo cual debemos calibrar todos los aspectos para asegurar un diseño de UX y un desarrollo fluido.
Otra forma de reducir tiempos, costos y esfuerzos, es pasar rápidamente desde el prototipado al desarrollo. En lo posible, prototipar en herramientas lo más cercanas al lenguaje final: HTML, CSS, JavaScript en el caso del web. La idea de generar prototipos detallados, con herramientas especializadas (como Axure, InVision, etc.), que luego deberán ser reconstruidos durante el desarrollo, parece superflua en la mayoría de los casos. Gastar recursos en aprender los trucos de las herramientas de prototipado, que luego serán desechados, no parece una forma eficiente de avanzar.
En conclusión, tenemos muchas herramientas de definición y comunicación a nuestra disposición, sólo debemos saber cuándo usarlas para beneficio de cada proyecto.
el factor humano
por Nelson Rodríguez-Peña
