Diseño atómico y elementos digitales

El término “página web” es una reminicencia del pasado académico de la web, y ha sido una metáfora útil para acercar a los usuarios finales a esta tecnología. Desde la perspectiva de diseño, es necesario de ir más allá de hacer páginas para comenzar a crear sistemas multiplataforma.

Con el tiempo, la Web ha evolucionado y ya no está confinada al escaparate de un navegador web en una PC, sino que ha dado el salto a una enorme cantidad de dispositivos diversos, desde dispositivos móviles como smartphones hasta televisiones inteligentes, todos con diferentes capacidades, tamaños de pantalla, formatos y métodos de interacción.

Algunos de los dispositivos con los que las personas navegan la web
Algunos de los dispositivos que las personas usan para navegar en la web.

En este multiverso tecnológico, los profesionistas que crean, diseñan y mantienen la web se benefician al utilizar métodos y mejores prácticas que ayuden a mantener la consistencia y la escalabilidad de sus proyectos. Un concepto que se usa con frecuencia en pláticas sobre diseño de experiencia de usuario es la modularidad. Es aquí donde entran los conceptos de Diseño Atómico.

La metodología de Diseño Atómico

Diseño Atómico (Atomic Design) es una metodología de diseño creada por Brad Frost enfocada en la reutilización acumulativa de elementos modulares sencillos para crear estructuras de información más complejas.

El Diseño Atómico no se trata de diseñar una sola instancia de una página web a la vez, sino que vistos desde un punto de vista más amplio, se usa para crear la base de sistemas más grandes. El Diseño Atómico ayuda a que el diseño interactivo pueda adaptarse rápidamente a diferentes dispositivos, y es compatible con procesos de diseño centrado en el usuario, ya que se puede implementar desde las etapas tempranas de diseño usando sketches y prototipos.

La metodología de Diseño Atómico  se compone de cinco capas que trabajan juntas para crear interfaces y sistemas:

Los elementos del Diseño Atómico

1. Átomos

En esta metodología, los átomos son los elementos básicos que se utilizan en la construcción de interfaces digitales que no pueden ser reducidos en componentes más simples sin perder su funcionalidad. Los átomos de una página web incluyen las etiquetas básicas de HTML como párrafos, campos de texto, botones y  etiquetas, así como elementos básicos de estilo como colores y tipografías.

Átomos en HTML
Átomos en HTML

La tabla periódica de elementos HTML de Josh Duck ilustra de manera muy clara como todos nuestros sitios web, web apps, mensajes de correo, intranets y cualquier cosa que se visualice con un navegador web están compuestos de los mismos elementos:

Tabla periódica de elementos HTML
Tabla periódica de elementos HTML

2. Moléculas

En el diseño de interfaces, las moléculas son grupos relativamente simples de elementos visuales que funcionan juntos como una unidad. Un ejemplo sería juntar un campo de texto, una etiqueta de formulario y un botón para crear la molécula de un formulario de búsqueda.

Molécula de búsqueda
Molécula de búsqueda

Cuando se combinan, estos átomos tienen un propósito nuevo: la etiqueta define la entrada del campo, y el botón envía la información del formulario para ejecutar una búsqueda. El resultado es un componente simple y reutilizable que puede ser incluirse en cualquier sistema que necesite la funcionalidad de búsqueda.

3. Organismos

Los organismos son componentes de UI relativamente más complejos compuestos por átomos, moleculas y otros organismos. Los organismos se integran para crear las diferentes secciones de una interfaz.

Si a nuestra molécula de búsqueda le agregamos algunos elementos más, podremos obtener el organismo del encabezado, un elemento común en muchas páginas web.

Organismo de Encabezado
Organismo de Encabezado

4. Plantillas

Las plantillas son objetos a nivel de página –noten como aquí abandonamos la metáfora de elementos químicos y regresamos a elementos editoriales– que utilizan componentes basados en átomos, moléculas u organismos en una distribución que hace tangible la estructura general de contenido.

Plantilla con contenedores
Plantilla con contenedores para contenido

Las plantillas organizan los componentes básicos y les agregan contexto para que la página funcione correctamente. Otra característica importante de las plantillas es que se enfocan en la estructura del contenido en lugar del contenido final de la página. Los sistemas dinámicos deben poder adaptarse a contenido dinámico que cambia todo el tiempo, y las plantillas proveen los mecanismos para definir las propiedades de los componentes que las integran, como el tamaño y alineación de sus imágenes o la longitud y estilo de sus encabezados y párrafos.

5. Páginas

Las páginas son instancias específicas de las plantillas que utilizan contenido real. Si tomamos la plantilla de la capa anterior y la llenamos contenido real en sus contenedores podremos ver el resultado final del proceso.

Página con contenido final
Página con contenido final

Ventajas de utilizar Diseño Atómico

Como mencionaba al principio, una de las principales ventajas de utilizar esta metodología es que está enfocada en la modularidad, lo que permite crear elementos simples que pueden reutilizarse constantemente en equipos de diseño y desarrollo de cualquier tamaño sin perder la consistencia del diseño final.

La modularidad del Diseño Atómico también habilita la transversalidad entre los componentes abstractos y concretos del diseño, lo que permite generar diferentes patrones de interfaz reutilizando los mismos elementos al reorganizar su arquitectura y crear nuevos contextos para ellos.

Modularidad y reutilización de elementos atómicos
Modularidad y reutilización de elementos atómicos

El Diseño Atómico es muy útil para crear un sistema de lenguaje de diseño (Design Language System o DLS) para crear prototipos y código más eficiente y que cualquier persona en el equipo de producción puede entender y utilizar para procesos de diseño y desarrollo más rápidos y productivos. Al final, el Diseño Atómico no es un proceso lineal, sino un modelo de pensamiento sobre el que se puede iterar para crear sistemas complejos partiendo de elementos sencillos.

Equipos de productos reales, como el de Airbnb se han beneficiado al implementar Diseño Atómico en sus procesos de diseño y desarrollo, integrándolo a las metodologías que ya utilizaban previamente.

Elementos de diseño en Airbnb creados con Atomic Design
Elementos de diseño en Airbnb creados con Atomic Design

Brad Frost y Dave Olsen crearon un generador de elementos llamado Pattern Lab, basados en los principios de Diseño Atómico. Este generador está creado con el principio de “Móvil primero” (mobile first) con opciones para ajustar el tamaño de las páginas y de agregar comentarios a las secciones del sitio y a los bloques de construcción a nivel de código.

Pattern Lab, un generador de elementos para Atomic Design
Pattern Lab, un generador de elementos para Atomic Design

La versión original de Pattern Lab está escrita en PHP, pero ya hay dos versiones para NodeJS: una para Gulp y otra para Grunt. Recomiendo ampliamente jugar un poco con el demo en la herramienta para entender mejor cómo funciona una implementación real de Diseño Atómico.

* * *

Vale la pena recordar que la diversidad en los dispositivos con los que nuestros usuarios navegan la web o consumen información no se detendrá, sino que seguirá creciendo de manera acelerada, y posiblemente los modelos de diseño y desarrollo tradicionales no soportarán esa diversidad sin adaptarse a formas más ágiles de trabajo. Diseño Atómico es una metodología que  puede ayudarnos a crear sistemas e interfaces que se pueden adaptar a cualquier entorno.

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.

Diseñando la web física

La Internet de las Cosas –Internet of Things, o IoT– es la promesa de que en algún momento los objetos cotidianos que nos rodean estarán conectados a la red mundial de datos. Aunque esta visión aún no llega por completo, la Web Física –Physical Web– es un paso importante para volverla tangible.

La Web Física (Physical Web)  podría sonar como un intento de darle un nombre distinto al Internet de las Cosas, aunque es realidad es una parte de ésta. Internet y la Web no son lo mismo, son diferentes entidades donde la primera se refiere a la tecnología e infraestructura que hace posible la red mundial de comunicación; la segunda se refiere a un servicio de transmisión de datos con la que se puede interactuar a través de un navegador web, o browser.

De  manera análoga, Internet de las Cosas es una colección de objetos inteligentes que se están conectando rapidamente a Internet, y la Web Física nos permite tener acceso e interactuar con esos objetos a través de un navegador web de una manera simple e intuitiva.

Web física en un iPhone  Web física en Android

Una solución de Web Física se basa en tres componentes:

1. Objetos inteligentes

El primer componente de la Web Física son esos objetos inteligentes que mencioné antes, que son pequeños dispositivos capaces de emitir una señal de corto alcance usando Bluetooth a otros dispositivos que se encuentren cerca, como smarthphones, para interactuar con ellos con información que obtienen de Internet.

Beacon comunicándose con una app
Un beacon comunicándose con una app

Los beacons son un buen ejemplo de estos objetos, además de que son baratos y sencillos de instalar. Algunos beacons tienen sensores que les permiten detectar su ubicación geográfica, medir la temperatura ambiente donde están instalados o detectar si otros dispositivos alrededor suyo se están acercando o alejando de ellos.

Tal vez el principal problema de los beacons es que para proveer una experiencia de usuario enriquecida dependen de que los usuarios tengan instalada un app en su móvil con capacidades para reconocerlos y comunicarse con ellos. Si el usuario no tiene la app o no puede instalarla, el beacon es invisible para él.

2. Direcciones web

URLPara resolver este problema, la Web Física utiliza como segundo componente una dirección web o URL. Los objetos inteligentes en la Web Física envían constantemente una dirección web que cualquier dispositivo cercano al objeto puede recibir; la idea es replantear los sitios web móviles para que muestren información relevante a un usuario en una ubicación física, por ejemplo: junto a una máquina expendedora, un poster, una parada de autobús o una cafetería, sin necesidad de que los usuarios descarguen una app primero sino que utilicen una app que ya está en su dispositivo: su browser.

3. El navegador web

Navegadores web para móvilEl tercer elemento de la Web Física es el navegador web del smartphone, que toma el lugar de la app en esa conexión con un beacon e interpreta la dirección que se le envía para abrir una página móvil específica para el contexto del usuario.

El navegador es capaz de detectar los beacons de Web Física alrededor suyo y mostrar su información ordenada por una combinación de factores como proximidad, intensidad de su señal, las preferencias del usuario, su historial de búsqueda y de navegación.

Al seleccionar un enlace de Web Física en una parada de autobús podría mostrar los horarios de los autobuses y un mapa con sus rutas. Una máquina expendedora podría ofrecer una página web para seleccionar y comprar un producto, o un parquímetro puede dirigir a su usuario a una página para pagar por tiempo de estacionamiento:

A donde sea que cada dirección web dirija, toda la interacción ocurrirá dentro del navegador web sin necesidad de que el usuario descargue una app especial para cada experiencia.

* * *

Comenzar a experimentar con la Web Física es muy sencillo: toda la información técnica está disponible en GitHub y hay una guía para comenzar desde cero en ese mismo sitio. Muchos beacons comerciales como BKON, Estimote y GemTot ya son compatibles con sus protocolos.

Aunque el planteamiento de la Web Física suena simple, aún se tienen que resolver los problemas que ya existen con la web móvil como privacidad, SPAM, problemas de usabilidad y de conectividad antes de que el concepto despegue del todo.

La idea de la Web Física es crear un estándar abierto que eventualmente pueda integrarse en cada dispositivo y navegador, y así comenzar a conectar la web con el mundo allá afuera.

 

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

El modelo HEART para medición de UX

Hay muchas cosas que se pueden medir en medios digitales, pero no todo lo que se mide es útil para UX. El modelo HEART nos ayuda a obtener información valiosa sobre la experiencia de los usuarios reutilizando métricas simples.

Al realizar pruebas A/B o en la medición de día a día de un producto digital se pueden obtener muchas métricas que no son útiles en el diseño de experiencia de usuario. Estas métricas pueden describir el comportamiento de los usuarios al interactuar con nuestros productos, pero que no están ligadas a la experiencia de usar un sistema, como el número de visitas a un sitio web, el número de visitantes únicos, la popularidad de una app en su marketplace o la frecuencia de compra de un producto.

Estas métricas, también llamadas “métricas de vanidad“, pueden ser útiles en otros contextos pero no son buenas métricas de usabilidad ni son útiles para tomar decisiones de diseño por si solas ya que no se relacionan ni con la calidad del producto ni con los objetivos del proyecto. Para que sean útiles desde la perspectiva de UX es necesario interpretarlas primero.

El espejismo de las métricas de vanidad

El modelo HEART es una técnica que se puede aplicar para reutilizar las métricas simples en insights cuantitativos y medibles que son útiles para la mejora de la experiencia de usuario de un producto completo o solo de una característica específica. En este modelo, se crean cinco categorías de métricas:

  • Felicidad (Happiness): mide las actitudes de los usuarios hacia el sistema, normalmente obtenidas por medio de encuestas. Por ejemplo: satisfacción, facilidad percibida de uso o su net-promoter score.
  • Engagement: el nivel de involucramiento del usuario con el producto, medido normalmente usando métricas de de comportamiento asociadas al concepto como frecuencia, intensidad o profundidad de la interacción sobre un periodo de tiempo. Algunos ejemplos son el número de visitas por usuario por semana, o el número de fotografías que publica un usuario al día.
  • Adopción (Adoption): es el número de nuevos usuarios de un producto o de una característica de un producto. Por ejemplo: el número de cuentas creadas en los últimos siete días o el porcentaje de usuarios de GMail que utilizan etiquetas en sus correos.
  • Retención (Retention): es la tasa con la que los usuarios regresan a utilizar un producto. Por ejemplo: el número de usuarios activos en un periodo de tiempo que siguen utilizando el producto en un periodo de tiempo posterior. Una métrica interesante es la tasa del fracaso en la retención, comúnmente conocida como “churn”.
  • Tareas (Task success): incluye métricas tradicionales de comportamiento en experiencia de usuario, como eficiencia (el tiempo que toma terminar una tarea), efectividad (el porcentaje de tareas completadas) y la tasa de errores. Esta categoría puede aplicar en las áreas de un producto que están enfocadas a tareas para el usuario, como un buscador, un formulario o la creación de un perfil en el sistema.

En la práctica no es necesario crear métricas para todas las categorías de HEART, sino que se pueden elegir una o dos que sean importantes para el proyecto que se está analizando. El modelo HEART puede ayudar a decidir si vale la pena agregar o no una categoría en particular. Por ejemplo, la categoría de engagement puede que no sea relevante en un contexto corporativo donde se espera que los usuarios utilicen un producto como parte de su trabajo diario.

En este caso, el diseñador de UX puede elegir enfocarse en la categoría de felicidad o la de tareas, aunque aún podría considerarse útil la categoría de engagement para características específicas del producto como un indicador de su utilidad.

El proceso de Objetivos-Señales-Métricas

La definición de las métricas para HEART no es directa, ya que es específica para cada proyecto dependiendo de sus características, objetivos y de la información que esté disponible. Para decidir con mayor facilidad cuáles métricas definir y rastrear se utiliza el proceso Objetivos-Señales-Métricas (Goals-Signals-Metrics).

  • Los objetivos (goals) deben ser claros y estar alineados, ya que diferentes personas en el proyecto pueden tener objetivos diferentes. Este proceso es una oportunidad para alinearlos y definir de manera conjunta hacia dónde se quiere llevar el producto. Un error común es definir los objetivos de un proyecto usando las métricas que ya existen, por ejemplo: “nuestro objetivo es aumentar el tráfico del sitio web“.
    Es obvio que todo el equipo quiere eso, pero ¿cómo es que el diseño de experiencia de usuario puede ayudar a mejorar esta métrica? El objetivo de UX podría ser “atraer nuevos usuarios” o “aumentar el engagement de usuarios existentes“.
  • Las señales (signals) son indicadores que reflejan las actitudes o sentimientos de los usuarios hacia un sistema por medio de acciones, y que son sensibles a los cambios en el  diseño, por ejemplo, una señal de engagement puede ser el número de usuarios que no terminan de ver un video, o el tiempo de permanencia en una página con una densidad de información alta. Un objetivo puede tener una o varias señales asociadas.
  • Las métricas (metrics) nos dan al final información valiosa en la interacción entre los usuarios y nuestro producto. Es importante utilizar el criterio SMART en la creación de estas métricas y evitar incluir información solo “porque es interesante” y en su lugar alinearlas con las métricas de usabilidad generales del proyecto.

El modelo HEART junto con el proceso de objetivos-señales-métricas pueden ayudarnos a definir y priorizar de manera natural las métricas para obtener información que se pueda utilizar en el diseño centrado en el usuario. Al final, se puede utilizar como una tabla para hacer el mapa de análisis:

Ejemplo de una tabla HEART
Ejemplo de una tabla HEART

Este modelo se puede implementar de manera muy sencilla y ayuda a enfocar las métricas de otras áreas en un proceso de mejora de diseño, al tiempo que ayuda a tener información que refleje la calidad de la experiencia de los usuarios junto a los objetivos de negocio.

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

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

Diseñando con Design Sprint

Design Sprint es un proceso de cinco días que sirve para resolver las preguntas críticas de un producto utilizando diseño, prototipado y la evaluación de ideas con usuarios finales.

Este proceso fue desarrollado en GV (antes Google Ventures) por Jake Knapp y mejorado por Braden KowitzMichael MargolisJohn Zeratsky y Daniel Burka como una colección de buenas prácticas de design thinking, estrategia de negocios, innovación, análisis de comportamiento y otras, empaquetadas en un proceso que cualquier equipo puede utilizar. En el Vol. XVII de UX Nights en la Cd. México había hablado de este tema, y me pareció que valía la pena retomarlo.

Al trabajar en un design sprint es posible recortar el ciclo de análisis e investigación a unos cuantos días, y el equipo de trabajo puede entender más rápidamente si vale la pena trabajar en una idea antes de comenzar a desarrollar una versión mínima de producto.

Aprender antes de construirDesign sprint le ayuda a un equipo de trabajo a obtener información clara por medio de la validación con prototipos para ver las reacciones de sus futuros usuarios antes de hacer compromisos que costarán tiempo y recursos.

Las sesiones de design sprint son colaborativas e incluyentes, y se anima a invitar a estas sesiones a tantos perfiles como sea posible, incluyendo diseñadores, programadores, expertos en negocio o en procesos. Normalmente hay un facilitador –el sprintmaster– que ayuda a dirigir el proceso y se asegura que el equipo no se desvíe de su objetivo.

Estas son las etapas típicas en la ejecución de un Design Sprint:

Proceso de Design Sprint

  • El día lunes se crea el camino a seguir en los siguientes días por medio de discusiones estructuradas. Al principio, se define un objetivo de largo plazo, y se crea un mapa del reto. En este día se invitan a expertos para que compartan su conocimiento sobre el problema con el equipo. Al final, se elige un objetivo: una parte ambiciosa pero manejable del problema que se puede resolver en una semana.
  • El día martes el equipo se enfocará en buscar soluciones. Después de revisar ideas ya existentes se comienzan a mezclar y a mejorar por medio de bocetos en papel, enfatizando el pensamiento crítico sobre la estética. En este día también se definen los perfiles de los usuarios que probarán la solución al final de la semana.
  • El día miércoles se revisan y critican las propuestas de solución desarrolladas el día anterior y el equipo decide cuáles resuelven mejor el objetivo a largo plazo. Después de elegir, se toman los bocetos ganadores y se combinan para crear un storyboard: un plan paso a paso para la construcción de un prototipo.
  • El día jueves el equipo trabajará para convertir el storyboard del día anterior en un prototipo, una versión simple y rápida de la solución que simule lo que los usuarios verán al final y que se puede construir en un día. También se prepararán los guiones para entrevistas y revisión del prototipo para el día siguiente.
  • El día viernes se realizan entrevistas con usuarios de carne y hueso para que el equipo pueda aprender de ellos al verlos utilizar el prototipo que se construyó el día anterior. Esta prueba es la que hace que el sprint valga la pena, porque al final del día el equipo aprenderá qué tal útil es su propuesta de solución y que hacer después: explorar otra solución, iterar sobre la propuesta actual o enviarla a producción.

Vale la pena aclarar que aunque design sprint toma prestados algunos conceptos de metodologías ágiles, no es sustituto ni equivalente de un sprint de scrum, ya que el proceso, los roles y los entregables son muy diferentes. Design sprint también utiliza conceptos de design thinking pero con límites claros sobre el tiempo y los recursos que se utilizarán en el proceso para mantenerlo ágil y enfocado.

Lo más importante de design sprint es que desde el principio ayuda al equipo a trabajar sobre las necesidades de sus usuarios, además de que enfoca el esfuerzo colectivo en crear cosas tangibles al mismo tiempo que reduce las discusiones.

Libro de SprintUna buena referencia sobre cómo ejecutar un design sprint es el libro que el equipo de GV publicó hace unos meses, titulado “Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days” y en el que se evaluan casos reales de implementación de la metodología, como Slack, Savioke, Blue Bottle Cafe, Foundation Medicine o FitStar, entre otros, además de que sirve como una guía hora por hora para el aspirante a sprintmaster.

Design sprint es una metodología de trabajo muy flexible que se puede aplicar al diseño o mejora de cualquier producto, e incluso se puede utilizar para hacer solo investigación de usuarios (research sprint), diseñar la visión de un nuevo negocio (vision sprint), una campaña de mercadotecnia (communication sprint) o la migración de un sistema a nuevas plataformas (new form factors sprint).

En el sitio de GV hay varios artículos (en inglés) sobre recomendaciones y técnicas para ejecutar design sprints con diferentes enfoques. El sitio de Google Developers tiene disponibles para descarga un par de ebooks para realizar sesiones de design sprint para diseñadores y programadores.

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.

Aplicaciones web progresivas, el retorno de la web al móvil

Durante años los sitios web ha sido relegados en los dispositivos móviles sobre las apps nativas debido a problemas de rendimiento, compatibilidad y, sobre todo, de conectividad. Las aplicaciones web progresivas (progressive web apps) prometen resolver estos problemas.

Las aplicaciones web progresivas (progressive web apps) son un acercamiento al desarrollo de apps para móviles que combinan lo mejor de la web y lo mejor de las apps nativas. Estas nuevas web apps son útiles para sus usuarios desde la primera visita en un navegador web, sin necesidad de instalar nada más.

A medida que el usuario crea una relación con la app de manera progresiva, ésta se vuelve más poderosa y útil: carga rápidamente, incluso en redes lentas o cuando el dispositivo está desconectado, puede enviar notificaciones, tiene un icono en la pantalla del móvil y funciona a pantalla completa.

Funcionamiento de una app web progresiva

Una aplicación web progresiva es:

  • Estándar – utiliza la misma plataforma y tecnología que se utiliza para crear páginas web: HTML, CSS y Javascript.
  • Progresiva (¡obvio!) – funciona para todos los usuarios, independientemente de cuál navegador web o sistema operativo utilice, porque está construída para mejorar progresivamente desde el principio.
  • Responsiva – se ajusta a cualquier resolución y formato de pantalla: escritorio, móviles, tabletas, televisiones o lo que sea.
  • Independiente de la conexión – está mejorada con service workers para funcionar sin conexión o en redes lentas con conexiones intermitentes.
  • Como una app nativa – el usuario la usará como una app, con soporte para navegación e interacción con gestos.
  • Fresca – siempre estará actualizada gracias al proceso automático de actualización del service worker.
  • Segura – trabaja sobre HTTPS para prevenir que alguien intercepte datos y para asegurarse de que el contenido no ha sido manipulado por otros.
  • Descubrible – es identificable como una “aplicación” gracias al manifiesto de la W3C y al registro de funciones del service worker, permitiendo a los buscadores web encontrarlas.
  • Interactiva – hace fácil interactuar con ella incluso cuando está cerrada con características como notificaciones tipo push.
  • Instalable – le permite a sus usuarios crear accesos directos en la pantalla de su teléfono sin necesidad de una tienda de apps.
  • Enlazable – se pueden compartir fácilmente usando su dirección en la web (URL) y no requiere procesos de instalación complejos.

Ya existen casos de empresas que han comenzado a implementar apps web progresivas, como AirBerlin o Flipkart con resultados bien documentados en mejoras de experiencia de usuario, retención y conversión.

Apps web progresivas

Google creó un taller para aprender a crear aplicaciones web progresivas desde cero, incluyendo consideraciones de diseño y detalles de implementación para asegurar que tus web apps cumplan todos los principios que mencioné arriba.

Las aplicaciones web progresivas son una oportunidad para regresar a la web su importancia dentro de dispositivos móviles -o en cualquier otro dispositivo-, y de romper los problemas y  dependencias de compatibilidad que tienen las apps nativas.

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.

Lenguajes para prototipado: Jade

El diseño de experiencia de usuario es, por necesidad, una labor colaborativa y multidisciplinaria. Si decimos que ‘todos somos diseñadores’, ¿por qué no todos podemos también aportar código?

Un equipo que realiza diseño centrado en el usuario debe de contar entre sus miembros con al menos un diseñador que materialize la parte visual del proyecto y un programador que realice la ejecución técnica.

Aunque todavía hay empresas que continúan en la búsqueda del mítico Unicornio de UXuna rara criatura, mitad diseñador y mitad programador-, para la mayoría de los equipos de UX uno de los principales retos es lograr que sus miembros puedan trabajar y comunicarse de una manera coherente.

En el caso de la relaProgramando en HTMLción del dúo diseñador / programador, uno de sus principales problemas es la capacidad de cada uno de generar código útil para producción, y es un problema porque la mayor parte de esa responsabilidad normalmente cae en el programador, que debe lidear con la complejidad de volver tangible una visión de diseño que surge de bocetos en papel, dibujos en un programa de diseño o en el mejor caso, de un prototipo cuyo código no es reutilizable.

Éste es en parte, un problema creado en parte por la formación de los diseñadores a los que les hacen creer que escribir código es algo complejo y en parte por la falta de herramientas correctas para diseñar código usable. Hay una larga lista de programas de diseño WYSIWYG (What you see is what you get – Lo que ves es lo que obtienes) que ofuscan el código para que el diseñador no lo vea, pero que al final producen código poco eficiente y complejo que el diseñador que lo hizo no puede entender y que para integrarlo a un producto real requiere retoques del programador que deberá darle mantenimiento en lo sucesivo.

Lo que ves es lo que quieres decir

Una buena práctica de desarrollo es la separación en capas de los componentes de presentación, contenido y lógica para asignar responsables a cada una y después integrarlos; así la actualización de una capa por mantenimiento no obliga a las otras a cambiar a menos que cambien los requerimientos del proyecto.

El desarrollo para web en el navegador está diseñado de esta manera, dejando el contenido a HTML, la presentación de CSS y la lógica de la aplicación a Javascript. Idealmente la generación de HTML y CSS debería ser lo suficientemente sencilla para el diseñador de manera que pudiera enfocarse en qué está haciendo, y no en cómo lo está haciendo.

Estructura de una página web con HTML, CSS y Javascript en archivos separados
Estructura de una página web con HTML, CSS y Javascript en archivos separados

Para lograr eso es necesario dejar los generadores de código visuales WYSIWYG por el modelo WYSIWYM (What you see is what you mean – Lo que ves es lo que quieres decir). En este modelo el diseñador se encarga de introducir el contenido de forma estructurada siguiendo su valor semántico en lugar de indicar su formato de representación final.

Jade – un lenguaje sencillo para plantillas web

Logo de JadeUna herramienta que puede servir justo a este propósito es Jade, un sistema para generación de plantillas HTML hecho para trabajar con NodeJS y que puede usarse como lenguaje para prototipado.

Jade utiliza un metalenguaje -casi mecanografía- basado en la notación de HTML que ha sido simplificado para ser breve, consciso y fácil de recordar.

Este es un ejemplo de una página web escrita en Jade:

doctype html
html(lang="es")
  head
    title Jade
  body
    h1 Jade - sistema de plantillas para Node
    #container.col
      if youAreUsingJade
        p ¡Gracias por usar Jade!
      else
        p Deberías usar Jade
      p.
        Jade es un lenguaje de plantillas práctico y simple 
        enfocado en tener buen desempeño y características poderosas.

que genera el siguiente código HTML:

<!DOCTYPE html>
<html lang="es">
  <head>
    <title>Jade</title>
  </head>
  <body>
    <h1>Jade - sistema de plantillas para Node</h1>
    <div id="container" class="col">
      <p>¡Gracias por usar Jade!</p>
      <p>
        Jade es un lenguaje de plantillas práctico y simple enfocado en tener un buen desempeño y características poderosas.
      </p>
    </div>
  </body>
</html>

Es así de simple.

Jade se encarga de generar código HTML bien formado. En un ejemplo para generar una lista numerada escribimos:

ol
 li Elemento A
 li Elemento B
 li Elemento C

que genera en HTML:

<ol>
      <li>Elemento A</li>
      <li>Elemento B</li>
      <li>Elemento C</li>
</ol>

Jade también pueden utilizar variables y condicionales de Javascript para generar código HTML según su configuración:

var user = { description: 'Usuario frecuente' }
var authorised = false
#user
 if user.description
   h2 Descripción
   p.description= user.description
 else if authorised
   h2 Descripción
   p.description.
     El usuario no tiene descripción, ¿por qué no añades una?
   else
     h1 Description
     p.description El usuario no tiene descripción

en HTML:

<div id="user">
     <h2>Description</h2>
     <div class="description">Usuario frecuente</div>
</div>

Existe documentación sobre cómo escribir en Jade, y en general se puede comenzar a utilizar en poco tiempo. No es necesario tener un servidor, se puede instalar de manera local en un equipo de desarrollo / diseño, y tanto NodeJS como Jade son gratuitos.

Jade puede ser una herramienta útil para prototipar y generar código para prototipos funcionales usando como guía los bocetos y prototipos en papel, los archivos de Jade son compactos, fáciles de leer por humanos y es muy sencillo editarlos y compartirlos.

Lo mejor es que el HTML generado por Jade puede integrarse después al código en producción con poco esfuerzo, ya que su salida es de alta calidad y es compatible con otras librerías y frameworks que se usan en desarrollo web como Bootstrap, JQuery o AngularJS entre otros.

¿Es esto suficiente para habilitar a los diseñadores a escribir código? Tal vez no, pero es un buen acercamiento a resolver el problema y una buena idea para prototipar rápidamente con código para que todos los miembros de un equipo y no solo los desarrolladores puedan aportar código útil a un proyecto.

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.

Validación de sitios para móviles

Los dispositivos móviles, y en particular los smartphones, están dominando la web. Hoy más que nunca es muy importante asegurarnos que nuestros sitios web sean compatibles con estos dispositivos.

En los últimos años hemos visto un cambios importante en las preferencias de navegación de los usuarios de la web, donde se nota una tendencia de migración clara de los equipos de escritorio –workstations, laptops, etc.– hace los equipos móviles, y no parece que vaya a cambiar pronto.

En el estudio de AMIPCI en 2015 sobre hábitos de usuarios en México, el único segmento que registró crecimiento en su uso fue precisamente el de los smartphones, y creció a costillas de los dispositivos de escritorio para colocarse en un 58% de preferencia de los mexicanos al navegar la web:

AMICPI dispositivos de conexion
A nivel mundial también es notable la preferencia de compra de los usuarios finales de dispositivos móviles (smartphones y tabletas) contra los equipos de escritorio, en una razón de casi 3 a 1:

PCs vs smartphones

Desde la perspectiva de experiencia de usuario, es importante revisar que nuestros sitios web estén construidos de forma que puedan verse y navegarse desde dispositivos móviles de manera sencilla y natural. Debemos tener en cuenta que el ecosistema móvil es mucho más diverso que el de las PCs al hablar de tamaño y resolución de pantalla, ancho de banda, capacidad de procesamiento, navegadores web y muchos otros factores.Les comparto algunas herramientas que les pueden servir para validar sus sitios móviles, al menos para comenzar a revisarlos:

Validador para sitios móviles de W3C

W3C Mobile Validator
W3C Mobile Validator

El Worldwide Web Consourtium o W3C es el organismo mundial que crea y mantiene los estándares técnicos de la web. Para ayudar a las personas que crean sitios web creó este validador de páginas web basado en la recomendación de MobileOk que revisa la estructura del código de una página y entrega un reporte donde indica el grado de cumplimiento de estándares en su codificación, el impacto de cada error y guías sobre cómo arreglarlo.

Lo encuentras en: http://validator.w3.org/mobile

Mobile friendly de Google Webmasters

Google Mobile Friendly Tool
Google Mobile Friendly Tool

En abril de 2015 Google anunció que el hecho de que un sitio web no se vea correctamente en dispositivos móviles comenzará a afectar su posicionamiento en los resultados orgánicos (no pagados) de su buscador, en caso que necesitaramos una razón de peso para optimizar y actualizar nuestros sitios web.

Para ayudar a los webmasters, Google agregó una herramienta de validación más cualitativa que la de W3C, que conecta la página validada con una granja de render de móviles de Google para entregar un resultado más enfocado en cómo ve la página el buscador y cómo la vería un usuario en su móvil. También tiene mucha documentación sobre cómo optimizar sitios web para móviles.

Lo encuentras en: https://www.google.com/webmasters/tools/mobile-friendly/

Responsinator

Responsinator
Responsinator

Esta herramienta sirve para simular cómo se vería una página web en diferentes dispositivos con diferentes tamaños, resoluciones y orientaciones. Aunque no es una manera definitiva de revisar el diseño de una página web, es una forma simple y sencilla de probar como se ajusta el diseño de un sitio a móviles si no tienes un teléfono de cada modelo a la mano para probar.

Lo encuentras en: http://www.responsinator.com

Test de velocidad de Rackspace

Prueba de velocidad de carga de Rackspace
Prueba de velocidad de carga de Rackspace

La velocidad cuenta mucho al navegar en un móvil. De acuerdo a Rackspace, actualmente un usuario tiene un rango de tolerancia entre 3 y 5 segundos para que un sitio móvil se visualice en su dispositivo antes de abandonarlo. La velocidad de carga de un sitio tiene que ver con muchos factores que van desde el ancho de banda en el servidor, la latencia de carga, el tiempo de renderizado y la carga del servidor, entre otros.

Rackspace creó una prueba de velocidad para sitios web en el que analiza varios componentes que afectan el tiempo de carga de un sitio y recomendaciones para mejorarla.

La encuentras en: http://www.rackspace.co.uk/ecommerce-hosting/page-speed-checker

* * *

Por supuesto, estas herramientas solo cubren una parte del análisis que se debe hacer a un sitio móvil y están enfocadas a la implementación técnica, no a la perspectiva del usuario, pero nos dan un punto de partida para poder analizar y mejorar de manera cuantitativa varios aspectos que sí afectan la experiencia de navegación de un usuario final.

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

El unicornio de UX

unicornio de uxPara muchas empresas, el profesionista de UX ideal es como un unicornio: está hecho con partes de diferentes criaturas, es increíblemente difícil de encontrar y por lo general sólo existe en su imaginación.

Un profesional de UX en la vida real conoce de muchos temas, pero tiende a especializarse en algunos de ellos y sabe que la forma correcta de crear buenas experiencias de usuario es con trabajo de equipo.

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.

Diseño de métricas de usabilidad

Para medir la usabilidad de un producto, primero es necesario definir las métricas adecuadas y luego utilizar la información que revelan para mejorarla. ¿Cómo se crean las métricas de usabilidad?

La Experiencia de Usuario, o UX como se abrevia comúnmente, se refiere a los todos los aspectos en la relación de una persona con un producto, aplicación o sistema. Muchas personas parecen pensar que la experiencia de usuario es una característica nebulosa que no puede ser medida o cuantificada por su naturaleza cualitativa. ¿Cómo medir objetivamente, por ejemplo, el sentimiento de una persona cuando no puede interpretar un captcha, o cuando logra utilizar una aplicación con éxito sin leer el instructivo antes?

La realidad es que todos los puntos de interacción de un usuario, sus comportamientos y actitudes hacia un sistema pueden ser medidos, aunque es cierto que algunos son más sencillos de medir que otros. ¿Por qué querríamos medir la experiencia de usuario? La respuesta corta es: para poder mejorarla. Si en estos días un sitio web, app o producto para consumidor final no se encuentra en un proceso de mejora continua, entonces ya se está quedando rezagado contra su competencia y respecto a sus clientes.

Una métrica es una manera de medir o evaluar un fenómeno o cosa particular de manera cuantitativa. Podemos decir que algo es más alto, largo o rápido porque somos capaces de medir y cuantificar estos atributos para hacer comparaciones en otros escenarios. Para que la métrica sea significativa es necesario que exista un acuerdo sobre cómo medir algo y que exista un método consistente y confiable para realizar mediciones.

Las métricas de usabilidad son una herramienta que nos ayuda a definir dónde se encuentra nuestro producto en relación con su competencia o con las expectativas de sus usuarios y para enfocar nuestros esfuerzos y recursos donde pueden tener mayor impacto para mejorarlo: las áreas en donde los usuarios lo encuentran confuso, ineficiente o frustrante.

La definición de una métrica -de usabilidad o cualquier otra- puede seguir los mismos principios que un Indicador Clave de Desempeño (KPI – Key Performance Indicator), usando el acrónimo SMART, significa que deben ser:

  • ESpecíficos (Specific)
  • Medibles (Measurable)
  • Alcanzables (Achievable)
  • Relevantes (Relevant)
  • Temporales (Timely), en el sentido de que sea posible hacer un seguimiento de su evolución en el tiempo.

Lo que hace diferente a una métrica de usabilidad de cualquier otro tipo de métrica es que la primera revela algo sobre la experiencia personal de la persona que está utilizando la app, el sitio web o el sistema. La métrica de usabilidad revela también sobre la interacción entre la persona y el sistema, como su efectividad (la capacidad de ejecutar una tarea con éxito hasta terminarla), su eficiencia (la cantidad de esfuerzo necesaria para terminar la tarea) o la satisfacción (el grado en el que el usuario se siente contento con él mismo o con la tarea que acaba de realizar).

Algunos ejemplos de métricas de usabilidad son: la tasa de éxito de ejecución de una tarea, el tiempo que toma realizar una tarea, el número de clics, teclazos o taps que realiza el usuario mientras realiza una tarea, calificaciones de satisfacción o frustración, el sentimiento de los comentarios que comparten los usuarios e inclusive el número de veces que una persona observa de manera fija un hipervínculo en la pantalla.

Otra diferencia entre una métrica de usabilidad y cualquier otra es que éstas miden algo relacionado con las personas, sus comportamientos y actitudes. Debido a que las personas son increíblemente diversas y diferentes entre sí, es común que sea complicado definirlas o intentar estandarizarlas.

Algunas cosas no deberían ser consideradas como métricas de usabilidad, como las preferencias o actitudes de una persona que no estén ligadas a la experiencia de usar un sistema, como podrían ser: la popularidad de una app en su marketplace, el tráfico de un sitio web o la frecuencia de compra de un producto. Aunque todas ellas son cuantificables y pueden reflejar algún tipo de comportamiento de sus usuarios, no están basadas en una interacción vivencial que refleje la variabilidad de la información que entregan.

La finalidad de las métricas de usabilidad siempre debe ser proveer respuestas a las preguntas que son críticas para el equipo que desarrolla tecnología y que no pueden ser resueltas de ninguna otra manera. Preguntas como ¿a los usuarios les gustará la nueva versión del producto? o ¿este producto es más eficiente que el de la competencia? son las que los estudios con personas y interpretación de las métricas de usabilidad pueden resolver, al mismo tiempo que sirven para mejorar el producto desde la perspectiva de quienes lo usarán después.

Como con el Diseño Centrado en el Usuario, las métricas nunca deben de ser un objetivo sino un medio para obtener insights, es decir, un entendimiento profundo sobre las emociones y sentimientos de una persona mientras usa un producto tecnológico. Con insights y métricas objetivas que los respalden podremos descubrir e inventar nuevas maneras de crear experiencias de usuario positivas y sorprendentes.

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.