Wearing a wereable

Hace un mes me compré un (nuevo) smartwatch. – En realidad iba a ser un regalo, pero como siempre me pasa, acabó siendo un autoregalo y una promesa de un regalo mejor).

El modelo es el LG G Buddy en negro con Android Wear, algo muy básico que conseguí por 99€, un precio razonable para experimentar. – Sí ya sé, vaya birria de regalo, qué le vamos a hacer…

Por sus características, es un reloj que debe estar conectado por Bluetooth a mi móvil Android, y cargarse cada 3-4 días de uso. No me parece demasiado grande para mi muñeca, ni con un estilo demasiado marcado, ni pesa mucho. Creo que es cómodo como cualquier otro reloj y cumple mínimo las dos funciones básicas que debe tener:

  1. Da la hora
  2. Puedes ponértelo en la otra muñeca si quieres acordarte de algo

La experiencia de la tecnología llevable

El uso que le he dado al reloj ha sido un uso cotidiano. No me he atrevido a llevarlo mientras hacía deporte, no me parecía tan apropiado para eso a pesar de que es resistente al agua. El caso es que me resulta bastante incómodo cualquier tipo de pantalla que no tenga botones físicos. Uso un Polar, antes de eso usaba el Nike+ Sportwatch y antes de eso mi iPod de 3º generación. Cuando corro me resulta más cómodo presionar, que tocar o deslizar el dedo mientras estoy en movimiento y esperar que la interfaz reaccione.

Sin embargo, para el día a día, mientras trabajo o hago mi vida fuera de casa, lo tengo conectado con mi móvil tanto como la batería de éste me lo permite.

El reloj es un reproductor de notifcaciones el 90% del tiempo, un acceso rápido a contestar a esas notificaciones un 5% y el otro 5% es ese desconocido que te encontrarías en un ascensor que te hablaría del tiempo, del tráfico y además te chivaría lo poco o mucho que te has movido ese día.

Éste último 5% es todo mérito de Google Now (y Google Fit), que me encanta y creo que entiende muy bien el contexto y la información relativa al usuario. Fuera de bromas, creo que llevarlo en la muñeca es mucho más oportuno que en el móvil.

Sobre el exceso de notificaciones podría decirse que ‘ahorra tiempo’ si no se acumulan. Si lo hacen ya no puedes previsualizarlas en el reloj pero sí en el móvil. Es cómodo porque es discreto, puedo estar todo el día moviéndome por la casa o la oficina, dejar mi móvil en el bolso y enterarme de si alguien me está hablando por alguna red social o por mail mirando rápidamente la muñeca sin interrumpir ninguna conversación ‘en directo’.

En el coche también es útil, pero peligroso. Recibir un mensaje y poder contestarlo hablándole a tu reloj como en el coche fantástico es más seguro que intentar hacerlo manipulando el móvil. Aún así, hay que irse con cuidado.

En general este uso de receptor o canalizador de notificaciones para que resulte útil te convierte en un poco esclavo, como ya lo hace el móvil. Cuanto más quieres que te comunique, más inoportuno o estresante se convierte.

Las reacciones de la gente han sido curiosas. No se puede negar que tiene un toque moderno, techie o frikie. El diseño de cada skin para el reloj es divertida y ‘chanante’. Los smartwatch molan porque aún no está muy extendido.

Finalmente un uso curioso es mientras trabajo con el ordenador (entro 8h-10h al día), escucho música en Spotify (4-5h al día) y me da por saltar una canción desde el reloj. ¡No sirve para nada porque falla! Si bien salta la canción, parece que el móvil recibe la interacción y entiende que debe ser él el reproductor, así que paso de escuchar música por mis cascos a compartirla con quien haya en la habitación. Absurdo e incómodo porque tienes que cerrar la app en el reloj para que no te moleste.


Llevar un wereable es, en mi opinión, algo que me resulta de lo más natural y útil según qué contextos. Cuando hago deporte no puedo vivir sin mi reloj, cuando estoy en casa no me resulta interesante a no ser que pudiera verlo conectado a otros dispositivos o electrodomésticos, y en el trabajo me funciona bastante bien cuando realmente me muevo de mi puesto (en reuniones, en la mesa de algún/a compañero/a, etc.)

No descarto comprar algo mejor en el futuro, seguramente con WiFi y con mejor diseño. Pero como siempre, lo que vale de un reloj son sus aplicaciones y sus servicios. Es imprescindible que estén adaptados a contextos de uso reales y útiles. Seguro que Apple vende millones de relojes estas navidades, pero está en nosotros/as, creadores de productos digitales, aprovechar la oportunidad para construir soluciones que sirvan para algo más que para recibir notificaciones.

No seamos como consumidores y usuarios sólo el producto de la industria, no nos convirtamos sólo en ‘donantes de datos’, seamos capaces de aprovechar la naturalidad de la tecnología llevable, vestible, ponible y portable, para ofrecer algo distinto, para percibir algo evolucionado.

Más allá de la moda y el diseño, los wereables se convertirán en la tecnología que nos ayude a ampliar nuestros sentidos de la forma más natural y menos disruptiva.

Trabajemos para conseguirlo.

Interfaz de línea de comandos: ¿un paradigma poco popular?

Han pasado ya unas cuantas semanas desde que empecé en mi nuevo trabajo y tenía muchas ganas de hablar de unos cuántos temas que han ido surgiendo durante todo este tiempo.

Uno de los que más interés me está causando, debido a su estrecha relación con la Interacción Persona-Ordenador (HCI) es el de las Interfaces de Línea de Comandos (CLI) y lo usable (o no) de su diseño.

No es éste un tema habitual ya que, usualmente, todo lo que tiene que ver con la Usabilidad y Experiencia de Usuario se termina ligando inevitablemente a las Interfaces Gráficas de Usuario (GUI) ya sean web, móviles, de escritorio u otras superficies. Lo cierto es que, desde que la metáfora visual se utiliza como representación del modelo de comunicación entre personas y computadores, la necesidad de diseñar estas interfaces de una forma eficiente para su uso se convierte en una obligación.

¿Pero qué ocurre con las CLI? ¿Se les puede aplicar criterios cualitativos de usabilidad? Más allá de los estándares que ya existen ¿representa la línea de comandos un paradigma relegado a un modelo de uso en declive o poco popular?

Haciendo un poco de investigación me topé con algunos recursos interesantes que me sorprendieron.

El primero que recomiendo es este libro: Build Awesome Command-Line Applications in Ruby 2: Control Your Computer, Simplify Your Life

Claramente destinado a programadores de interfaces de comandos pero con un enfoque muy serio en cuanto al respeto hacia los estándares para desarrollar algo suficientemente familiar. En el libro se destacan varias ideas en su introducción y conclusión:

  • Las CLI están focalizadas a scripting.
  • Las CLI no suelen utilizarse para el trabajo final, sino como recurso.
  • Las CLI son un white canvas (con los problemas de usabilidad inherentes que eso conlleve).

Pero por el contrario

  • Las GUI son interfaces muy difíciles de automatizar.
  • Las GUI no son interfaces fácilmente portables.

Quiero referenciar también el post que encontré en Biko que, curiosamente, trata el aspecto gráfico o visual de las CLI para hablar sobre UX. Sin faltarle razón creo que es un tema en el que se puede profundizar hacia muchos más aspectos.

Otro interesantísimo recurso que encontré fue este artículo escrito por Florian Cramer y Kamen Nedev que me parece simplemente imprescindible: Poética de la línea de comandos donde ejemplifica la diferencia entre los dos paradigmas de una forma muy sencilla:

La interfaz de línea de comandos provee funciones, no aplicaciones; métodos, no soluciones, o: nada más que un montón de plug-ins para ser promiscuamente enchufados unos en otros. La aplicación puede construirse, y la solución puede ser inventanda, por los propios usuarios.

[…] O, también, el paradigma Lego de un juguete auto-definido frente al paradigma Playmobil de un juguete predefinido.

Finalmente, me gustaría incluir algunos ejemplos de interfaces que, si bien no son líneas de comandos clásicas orientadas a usuarios administradores de sistemas, sí hacen uso del lenguaje natural en formato textual para interaccionar con los usuarios.

Seguramente haya muchos más ejemplos, si conoces alguno te animo a que los compartas conmigo.

Una última reflexión que me surge es sobre la necesidad/oportunidad de evolucionar las CLI para que aprovechen mejor el factor de forma de algunos dispositivos móviles como Blackberry (que se niega a morir). A fin de cuentas aún hay millones de usuarios que se comunican y se entienden con mensajes de menos de 140 caracteres.

Google podría considerar otra interfaz más de comandos.

El final de una etapa, el comienzo de otra

El próximo día 28 de Febrero, además de celebrar el día de la patría (andaluza), diré adiós a CSC (iSOFT Sanidad) tras una etapa de 5 años y medio trabajando como Diseñadora de Interfaces de Usuario y consultora de UX para el sector sanitario.

Como siempre, lo que me empuja es la motivación y la ilusión de un nuevo proyecto de la mano de ITRS Group que, como ya anunció en prensa, ha tenido a bien instalarse en el Málaga Valley para su nueva oficina europea.

Pasaré de las interfaces de gestión para escritorio y móvil a tocar algo más de visualización de información. Ya tengo mi primera lectura pendiente para ponerme a tono: Now you see it. Recuperaré el trabajo en equipo codo-con-codo. Exploraré otra industria, la de las finanzas, y cambiaré las grandes estructuras jerárquicas para ser una más entre un equipazo de gente sénior de la que espero aprender un montón.

Tengo mucha ilusión por empezar, por recuperar la frescura y el reto de lo desconocido, por alejarme de mi zona de comfort y de algunas monotonías. Sin embargo, es cierto que también echaré de menos muchas cosas que he disfrutado mientras estuve en CSC, empezando por mi compañero Antonio, de quien he aprendido tanto, al igual que a mis compañeros de Málaga y de UK y Holanda (la mayoría ya en otras empresas). Han sido sin duda años de muchas oportunidades profesionales y de profundizar conocimientos en una industria tan ‘hueso’ como es la de la salud.

A nivel profesional he tenido mucha suerte, he podido jugar muchos roles, de diseñadora, consultora, formadora, e incluso de manager. Eso sin duda es gracias también a la gente que me ha ido abriendo camino dentro de la empresa, que ha confiado en mí y que ha conseguido mejor que yo que el trabajo brillara. Espero que en esta nueva empresa no me falten esas u otras oportunidades 🙂

También a nivel personal ha sido una etapa intensa, desde que me vine a Málaga han pasado y cambiado muchas cosas, no quién soy, pero sí qué quiero y cómo me enfrento, precisamente, a estos cambios, y eso en parte lo he aprendido pasando muchas horas entre las cuatro paredes de estas oficinas.

Ahora es momento seguir adelante y tengo la oportunidad, por eso estoy contenta… y si sale mal sacaré alguno de mis cientos de planes B bajo la manga 😉

El próximo día 28 diré adiós a esta empresa para empezar de cero en otra, en la que espero, sobre todo, crecer, disfrutar y aportar.

Cómo crear una librería de recursos con Pencil

Si ya conocéis Pencil y os preguntáis cómo podríais definir vuestra propia librería de componentes para crear GUI en este tutorial hacemos un repaso de los pasos a seguir.

Hay dos formas de conseguir nuestra propia librería

  1. Haciéndolo bien
  2. Haciéndolo rápido

Como para hacerlo bien ya existe una buena documentación en la web de la herramienta vamos a explicar cómo puede hacerse de forma rápida (y no tan flexible) para que resulte práctico crear conceptos visuales y compartirlos con diferentes equipos.

image

Una forma fácil de empezar

Usando la librería ‘Common shapes’ podemos empezar a dibujar elementos básicos basados en formas geométricas.

  1. Una vez que tengamos todos los elementos, los seleccionamos juntos y agrupamos (CTRL+G). Ahora se comportarán como una única forma.
  2. Sobre el nuevo componente clicamos en botón derecho “Add to my collections…”.
  3. Como este es el primer componente tendremos que crear una nueva colección a la cual añadirlo. 
  4. Si ahora comprobáis en la pestaña ‘My Stuff’ veréis que ya está creada vuestra nueva colección. 

Una característica que encuentro bastante útil es la ‘Sizing policy’ que tiene cada elemento (accesible via menú contextual). Esta política permite definir el comportamiento del elemento cuando está agrupado en un componente al que se le modifica el tamaño. Gracias a esto podrás decidir si quieres que cambie o no de tamaño o se mantenga alineado a un lado o a otro.

¿Y si quiero hacerlo bien?

Qué necesitas tener

  • Un editor de texto (para ver/editar XML)
  • Un editor de SVG (las formas están definidas como vectores)
  • Un editor de bitmpas (por si necesitas meter algún icono o imagen)

Qué necesitas saber

Una estructura típica para crear una colección tiene este aspecto

... [dir] CollectionName
      |
      |___[dir] icons       #optional
      |     |
      |     |___shape1.png
      |
      |___ Definition.xml     

y en el documento Definition.xml deberás definirlo de esta forma

<Shapes xmlns="http://www.evolus.vn/Namespace/Pencil"
        xmlns:p="http://www.evolus.vn/Namespace/Pencil"
        xmlns:svg="http://www.w3.org/2000/svg"
        xmlns:xlink="http://www.w3.org/1999/xlink"

        id="your_collection_id"
        displayName="Display name of your collection"
        description="More description about this collection"
        author="Names of the authors"
        url="Optional URL to its web page">
        
        <!-- Your shapes go here -->
        
</Shapes>

Iremos añadiendo los diferentes componentes usando las etiquetas <Shape></Shape> y dentro de ellos podremos definir Propiedades (color, dimensión, etc.), Comportamientos y Acciones además de su Aspecto (mediante el SVG).

Para ver lo que estamos haciendo, puedes cargar tu colección desde Tools » Developer Tools » Load Developer Stencil Directory… seleccionando el archivo Definition.xml (usa F5 una vez cargado para refrescar).

Cuando termines, mételo todo en un archivo ZIP asegurándote que el Definition.xml está en la carpeta raíz.

No te olvides que si quieres depurar errores puedes abrir la consola de errores desde Tools » Developer Tools » Show Error Console

A partir de aquí te recomiendo que consultes el Tutorial en el que viene explicado cada detalle sobre cómo montar la colección con directivas XML.

Interaction Design with Indigo Studio and GifCam

Interaction Design with Indigo Studio and GifCam.

Indigo first release was free forever, although it’s not available for download any longer. I’m one of the few who still have a Lite license and can take advantage of this powerful prototyping tool built in Silverlight.

Indigo has helped me to demonstrate design, simulate behaviour and communicate specifications with the development team and also with end users.

GifCam is just a cool resource that helps me to share microinteractions implemented with a prototyping tool.

And this ‘Hello World’ example is nothing but one of the design interactions in motion I’ve been working this morning 🙂

Un año de proyectos

Uno de los objetivos que teníamos cuando hace un año pusimos en marcha esta firma era el de dar soporte a todo esos proyectos que siempre hemos querido iniciar y nunca encuentran el tiempo, el dinero o el coraje suficiente para salir adelante.

Éste ha sido, en sí mismo, el primero de los retos, nuestro Proyecto Cero.

Como balance de un año me gustaría reflexionar sobre los resultados, los cuales creo que han sido más positivos que negativos.

Los principios nunca son fáciles, pero contamos con el empuje de mucha gente, entre los que destacaría a Braulio y su esfuerzo por crear la comunidad de Training Bubbles a través de la cual ofrecimos algunos vídeos rápidos sobre técnicas prácticas de Diseño y Experiencia de Usuario.

Healthy Design Services muestra muchas de nuestras aspiraciones y resumen los principios en los que nos gustaría comunicar nuestros proyectos. Un diseño saludable es representado por soluciones óptimas, balanceadas, perdurables con una estrategia sólida que pone atención en el detalle, que confía en los beneficios a largo plazo sostenido por pequeños logros a corto. Un diseño como servicio al igual que un producto como servicio para ser usado y utilizado bien, fácilmente, sin aditivos y sobre todo lleno de utilidades.

No ignoramos otro de los matices sobre nuestra identidad en esta ocasión relacionado con el background de esta pareja de dos en UXSALAD: ambos provenimos de la industria de software sanitario la cual nos ha dado una visión muy particular de lo que supone el diseño de interacción persona-ordenador con propósitos de servicio humanitario, es decir, cuya base fundamental reside en el tratatimiento de información y servicios que gestionan datos sensibles y vitales para la sociedad más que como oferta de entretenimiento, productividad o cultura general.

Con esta filosofía nos hemos mantenido estos doce meses, en los que entre otros, hemos dado comienzo al desarrollo de una plataforma social de cine que pasará a su fase beta a partir de mediados de 2014.

Aunque tampoco podemos ignorar los fallos (aún es pronto para hablar de fracasos). Es obvio que UXSALAD es un estudio de diseño al que no le dedicamos el 100% de nuestro tiempo, la principal razón es que necesitamos un flujo de ingresos estable para vivir. Una de las cosas que no quisiéramos que pasara es pervertir el buenhacer por culpa de la necesidad, si bien es cierto que la necesidad agudiza el ingenio y aprieta las tuercas para no relajarse demasiado, la prioridad es disfrutar del tiempo que dedicamos a nuestros proyectos y darles la atención que requieren. Fracasaremos el día en el que lleguemos tarde con alguna de nuestras ideas al mercado o a la audencia, sin embargo, trabajamos para ganarle tiempo a esta empresa (en el sentido menos mercantil del término).

¿Por qué tus user stories no me dicen nada?

As a designer, I want to read meaningful user stories that talks about real people with real expectations and goals to achieve when using your software.

¿Por qué tus user stories no me dicen nada? Debo confensar que no soy una gran apasionada de Scrum. Generalmente mi desagrado no viene por los principios del desarrollo ágil y su manifesto, sino por quienes lo practican y evangelizan sin querer o saber integrar actividades de diseño en un desarrollo ágil.

¿Tan difícil resulta? Veamos…

En la metodología de Diseño Centrado en el Usuario uno de los principios fundamentales es entender las necesidades de los usuarios y diseñar los productos para satisfacer dichas necesidades o incluso ‘adelantarse’ a ellas. Todo gira en torno a los usuarios, tanto el análisis como el diseño y la evaluación del producto, convirtiéndose en protagonistas dentro de todo el elenco de actores.

En este contexto, Scrum debe ser la metodología de trabajo que guía el desarrollo, asegurando con sus principios y técnicas que se entrega a los clientes un software de calidad de forma ágil y que cumple sus expectativas.

El gap empieza a notarse en el momento en el que las principales user stories, los epics, que deberían describir una funcionalidad de valor para un producto, es decir, para un usuario, terminan convirtiéndose en frases vacías que no dicen nada o más bien dicen obviedades.

Estos son algunos ejemplos que considero insignificantes.

As a user, I want to get access to the item details easily.

As a clinician, I want to get access to the patient details easily.

Pues bien, primer problema es la ausencia de actor protagonista. Tanto la palabra user, como cualquier rol asociado a un usuario, no tienen por qué ser siempre la mejor forma de referirse a quién es el usuario que necesita dicha funcionalidad.

De hecho, las funcionalidades tienden a ser características del producto que se usarán dependiendo de la actividad, y la actividad no depende sólo de un rol sino también de un objetivo, por lo tanto, es más que probable que la necesidad ‘get access to the patient details’ formará parte (o no) de las activitidades para alcanzar algún otro objetivo más importante y relevante para el usuario.

La forma que sugiero de resolver este conflicto es incluyendo el uso de Personas para protagonizar las user stories, entendiéndolas desde un punto de vista de objetivos y patrones de comportamiento. Si asociamos objetivos a nuestros usuarios arquetipos y les dotamos de personalidad podremos referirnos a ellos de la siguiente manera:

As Stepehen King, I want…

As Peter Pan, I want…

As Morgan Freeman, I want…

Segundo problema: el valor de la user story es inexistente. Muchas veces me he encontrado user stories del siguiente tipo:

As a clinician, I want to get access to the patient details easily so I have a good overview of the patient health record.

¿En serio? Una cosa es que a los usuarios, en este caso médicos o enfermeras, les cueste expresar por qué necesitan ver los datos de un paciente, pero no quiere decir que no persigan un objetivo. Este objetivo lo da muchas veces el escenario y el contexto. Mi propuesta es enganchar aquí con los Escenarios de uso para describir qué es lo que el usuario realmente persigue con sus necesidades.

As Dr. Smith, I want to get access to the patient details easily so I can … diagnose a patient.

As Dr. Smith, I want to get access to the patient details easily so I can … schedule a follow-up appointment.

As Dr. Smith, I want to get access to the patient details easily so I can … check blood tests results.

Es importante que la user story siga pareciendo una historia real dentro de un contexto real, ya que incluso a este nivel, ningún desarrollador podrá escribir una línea de código sin hablar antes con el Product Owner, sin embargo, sí podrá entender e imaginar el alcance de la funcionalidad que tiene que implementar. ¿Cómo debería desarrollarse la user story para que el acceso a un paciente sea suficientemente efectivo como para saber diagnosticarlo, reservar una cita o comprobar los tests de usuarios?

Entra en juego también que el objetivo (so I can…) puede determinar el tipo de información que el Dr. Smith querrá ver para decidir o no acceder a los detalles del paciente.

El tercer problema que encuentro es el complemento de modo (condiciones de satisfacción).

As a clinician, I want to get access to the patient details easily.

Estoy segura que a estas alturas la Usabilidad forma parte de los requerimientos no funcionalidades de tu producto desde hace mucho tiempo y que no hace falta redefinirla en cada user story. Hacer algo easily no significa nada nuevo ni nada específico. Si lo que queremos es enfatizar cómo sería acceder a los datos de un paciente por el Dr. Smith de forma sencilla ¿por qué no lo escribimos tal cuál debe ser?

As Dr. Smith, I want to get access to the patient details easily so I can schedule a follow-up appointment.

Aquí podríamos incluir los condicionantes (Acceptance criteria) o bien usar una forma diferente de escribir que ayude a su validación (Acceptance stories).

As Dr. Smith, I want to get access to the patient details so I can schedule a follow-up appointment while I’m waiting for the next scheduled patient.

Aunque estoy complicando la historia intencionadamente, el ejemplo empieza reflejar ciertos factores algo más esclarecedores de lo que significa ‘fácil’ para el Dr. Smith, que espera darle la cita a su paciente entre visita y visita, lo que significará con mucha probabilidad que el tiempo será muy reducido, que tras cerrar el encuentro con ese paciente espera poder llegar su historial, consultar su agenda y reservarle una cita a su paciente.

Sé que también que desde el punto de vista del desarrollador sería más fácil ser más explícito, es decir, si sabemos bien que esos son los condicionantes, ¿por qué no lo escribimos tal cual?

Aquí insistiría en que, primero, sigue siendo necesario hablar con el Product Owner, y segundo, ¿de verdad lo sabíamos desde el principio?

Sé que estoy liando mucho este artículo con preguntas y que da para mucho más, pero querría cerrar esta pequeña deserción con el último de los problemas o, más bien, la última de mis sugerencias.

Si no crees que estos ejemplos tengan ningún sentido, quizá deberías plantearte volver a usar Casos de Uso.

(via carmelhassan)

Interfaces de usuario en el ámbito sanitario

Diseñada para la salud

Este viernes 23 de Mayo participé en el evento de UXSpain para hablar de Interfaces Usuario en el ámbito sanitario. Me ha hecho una enorme ilusión asistir a este evento un año más y en esta ocasión como ponente para introducir un tema como el de la Experiencia de Usuario en la Industria Tecnológica Sanitaria a la que llevo dedicándome casi 5 años.

Nervios a parte, intenté comunicar con algunos ejemplos cómo las interfaces de usuario en este sector pueden llegar a representan y determinar el modelo de antención sanitaria (servicios y productos incluidos).

La Sanidad es un ámbito de caracter humanitario que, sin duda, puede y debe verse beneficiado de las disciplinas del diseño, no sólo como especilidades sino como parte de sus estrategias transformadoras. Esta es la idea que me animó a compartir mi experiencia y que espero que resultara interesante a todo/as los asistentes.

Gracias a todos por vuestros amables comentarios en en Twitter y sobre todo a los que pude verles las caras e intercambiamos impresiones. No me gustaría que se perdiera el caracter de encuentro de este evento ya que es sin duda lo que más aporta a nivel personal para construir esta comunidad tan importante a nivel profesional.

Quiero agradecer también a mi compañero de vida Antonio Benítez su apoyo y ayuda, que se ha currado la mitad de las slides y sabe tanto o más que yo lo difícil que es la toma de decisiones de diseño y procesos en este sector.

¡Muchísimas gracias a todos, nos vemos en el próximo uxspain! Por supuesto, enhorabuena a la organización.

Cómo hablarle a los usuarios / Cómo no informar de los errores 

De qué hablamos cuando hablamos de informar a los usuarios, cuál es el mejor modo de hacerlo para saltar de la mera muestra de información a una comunicación más natural, más humana. Siguiendo los ejemplos de la foto, estas son mis reflexiones.

Título

No estás conectado vs VimeoError

Mientras el primero de ellos sintetiza un estado general del usuario de forma clara, el segundo se decanta por usar un código del sistema para resumir lo que ocurre. VimeoError nos hace pensar que algo ha podido incluso romperse, que algo hemos hecho mal, quizá el propio hecho de haber intentado usar la app. No estás conectado no dice claramente que sin conexión no hay contenido que ver.

Mensaje

La conexión Wifi y los datos móviles están desactivados. La página se podrá cargar cuando te conectes a una red. vs Could not connect to the Vimeo server. Please check your network settings.

Obviando que uno de ellos esté en inglés, aunque resulte más inaccesible para muchos usuarios, la gramática de ambos mensajes es diametralmente opuesta también. El primero se centra en explicarte qué significa No estás conectado y qué debes hacer para volver a estarlo sin más. El segundo insiste en describirse como un fallo de la app, de algo que escapa del control del usuario (el servidor) y que miremos la configuración de la red. No sabemos muy bien si también nosotros como usuarios hemos configurado mal nuestra red de repente y tendríamos que cambiar muchos parámetros, quizá baste con ‘encender la WiFi’, quién sabe…

Icono

Dinosaurio vs Alerta!

Sin duda, el primero de ellos no sólo intenta suavizar la gravedad del mensaje explicado la situación y la forma de salir de ella sin que cunda el pánico, sino que además busca simpatizar con un recurso gráfico que recuerda a la prehistoria, relacionando el hecho de la falta de conexión a Internet como algo de otra época. Esta línea de diseño emocional contrasta con la visualización de un icono de Alerta que enfatiza la gravedad de lo que ha pasado, aunque se contradiga incluso con el nivel de gravedad: ¿es una alerta o un error?

Control de acción

Más vs Cerrar

Una vez entendido o no el mensaje, la acción se ofrece como última escapatoria para el usuario. Más sugiere ampliar la información acerca de lo que ocurre, la confianza de que es posible hacer o saber algo más acerca de lo que sucede y por tanto yo, el usuario, podré saber cómo solucionarlo. Cerrar es simplemente una señal de que eso era todo y lo que pase después de cerrar es imprevisible.

Contenedor

Dentro del contenido vs Pop Up

El contexto también es importante y en el uso de móviles incluso más debido al espacio reducido para mostrar los contenidos. Usar ventanas modales ha sido una práctica común en aplicaciones de escritorio ya que ayudaba al usuario dentro de toda esa marabunta de ventanas a centrar su atención en el mensaje y tomar una decisión y una acción concreta. Usar un Pop-Up en un móvil en el que todo el contenido visible es ese mensaje (ya que no hay ni conexión ni se han cargado datos), además de ser innecesario me fuerza a considerar el mensaje como prioritario en mis atenciones, aunque lo primero que quiera hacer no sea interaccionar con él sino salir de allí como sea.

Conclusiones

Informar de los errores sin más no significa haber alcanzado un buen nivel de usabilidad en una aplicación, el modo en que esa información se dirige a los usuarios es clave para que éstos sepan qué está pasando y cómo pueden salir de ellos. En este contexto, el tono del mensaje debe acertar con la gravedad del mismo, entender que se dirige a un humano que no tiene que entender nada de sistemas, servidores o bases de datos, sino, a lo sumo, de su micromundo móvil que lleva en la mano.

El ejemplo de Google Chrome me parece fantástico para mostrar como un Diseño Emocional no significa hablarle a los usuarios de forma ‘jovial’ o personificada, sin sólo entender el contexto, empatizar con el humano que lo está usando y reforzar la confianza de que se puede prolongar un uso satisfactorio de la app a lo largo del tiempo.

Siento que Vimeo haya salido mal parado en esta comparación a pesar de sus muchas bondades sigue estando un poco oxidad.

Cross-experience Design – una aproximación

Cuando pensamos en diseñar para múltiples plataformas generalmente atendemos al sentido común que nos dice que el diseño debe adaptarse a la plataforma, a su tecnología y sus recomendaciones específicas de diseño. Sin embargo, si pusiéramos atención al factor humano y muy a pesar de los detractores del “No se diseñan experiencias”, me resulta inevitable pensar que existe un matiz diferente si enfocamos el diseño para la experiencia en una o múltiples plataformas.

Desde un significado literal, Cross-platform se refiere a la implementación de soluciones para múltiples plataformas. Luke Wroblewski incorpora también su término Multi-device design para referirse al diseño único que funcione para varios dispositivos. Ambos términos hablan dela forma de llevarse el concepto a la tecnología de forma que ‘puedas despreocuparte’ del dispositivo o plataforma desde la que se accede a la hora de desarrollarlo.

Ahora bien, cuando se piensa en diseñar para ofrecer experiencias de usuario concretas, el dispositivo o plataforma vuelve a estar en el punto de mira condicionando el comportamiento del usuario, de hecho forman parte de su contexto de uso, por lo que no podemos ignorarlo tan fácilmente una vez encontrada la solución técnica al diseño de un producto.

Existe un tercer término: Cross-chanel UX Design que se refiere a la interconectividad de los diferentes canales que se usan cada día y a la necesidad de consistencia entre ellos. Aunque esto tampoco es nuevo y nos devuelve a la época de los estándares y las divertidas discusiones sobre, por ejemplo, el icono para ‘Guardar’ (‘Guardar’ sigue formando parte de nuestro lenguaje ¿no es así?) y su uso en los diferentes Sistemas Operativos.

Sin embargo existe una situación que me gustaría bautizar como Cross-experience Design (perdonadme si el término ya existe y lo estoy ignorando) y, como todo término nuevo, refiere a algo que ya existe.

Cross-Experience Design sería el conjunto de prácticas para alcanzar soluciones de diseño que se adapten y transformen la experiencia de uso a lo largo del tiempo por las personas que utilizan la solución.

La forma en que estas prácticas toman forman son la Inteligencia Artificial y un diseño que llega a ser consciente del contexto del usuario, como el del Diseño Emocional y, por supuesto, el Diseño de Interacción.

Ideas sencillas en aparencia como lo que esconde Google Now es un buen ejemplos de esta consciencia inteligente.

Sin embargo el carácter temporal es un factor importante en UX, ya que un diseño cross-experience requeriría de incorporar ciertas características que evolucionaran conforme evoluciona la relación con el usuario. Por ejemplo, si diseñáramos un servicio X para un usuario con una necesidad A, una vez cubierta la necesidad A (ya sea circunstancial o temporal) ese usuario puede ‘transformarse’ en otro tipo de usuario con necesidades B, C y D. Como servicio puede que nos interese (o no) que suceda esa transformación de una determinada manera.

Todas las características que la solución ofrezca al usuario para que esta transformación tenga lugar de forma que se prolongue una experiencia enriquecedora a lo largo del tiempo son las que refiero como cross-experience design.

Puede que a estas alturas haya divagado demasiado, en cualquier caso, es posible que amenace con nuevas ideas para apoyar este concepto.