PEC 5 – Diseño de Interacción: La Videocomunicación.

Tras analizar los resultados obtenidos en el formulario por parte de usuarios de apps de videocomunicación durante sus clases de alemán, se ha creado un Storyboard intentando incluir las principales sensaciones o sentimientos expresados por los participantes con el fin de establecer un escenario base sobre el que trabajar en el diseño centrado en el usuario de una app de videocomunicación. A continuación, se puede consultar.

Una vez definido el escenario base, se ha pasado a diseñar un primer boceto de la aplicación. Para ello hemos tenido en cuenta los problemas que los participantes admitieron encontrar durante su experiencia en clases online de alemán, así como las sugerencias que propusieron y las aplicaciones externas que se veían obligados a utilizar debido a la falta de funcionalidad de las aplicaciones existentes en el mercado actualmente.

La propuesta de valor se ha centrado principalmente en:

  • Un calendario inicial para organizar las reuniones.
  • El cambio de visualización de los compañeros y el profesor.
  • La deshabilitación de las notificaciones externas a la aplicación para facilitar la concentración y evitar distracciones.
  • La búsqueda eficiente de contenido tanto en chat como en archivos para una fácil encontrabilidad de la información.
  • La posibilidad de editar y trabajar conjuntamente en ficheros de forma simultánea a la hora de corregir ejercicios conjuntos, por ejemplo.
  • La opción de pedir turno de palabra tanto pulsando un botón como levantando la mano y que la IA capte el mensaje y se lo transmita al moderador o profesor.
  • Las reacciones instantáneas que se ejecutan automáticamente al detectar la IA algún gesto como sonrisas, aplausos, etc. con el fin de evitar la pereza y poder facilitar la comunicación y el apoyo entre los alumnos de la clase.

 

 

 

Sin duda, hay algunas otras cosas que se podrían mejorar o incluir. Sin embargo, en este primer diseño se ha centrado la atención en las mejoras que se podrían incluir, más que en cómo mejorar lo ya existente en otras aplicaciones. Por ejemplo, se expone el caso de la pizarra virtual en la que una IA convertiría también los esquemas mal escritos del profesor en texto cuando sea necesario y tenga soporte de formas por defecto para facilitar la legibilidad de los apuntes.

De esta forma, se pretende que la aplicación mejore la experiencia teniendo en cuenta tanto las facilidades de hacerlo online como los elementos que los usuarios echaban de menos de la categoría presencial de la educación presencial.

PEC5 – Arquitectura de la Información: Prototipado y síntesis del proyecto.

A partir de las fases anteriores y basando el diseño en los bocetos presentados en las siguientes páginas, se ha desarrollado un wireframe de baja fidelidad del sitio. No obstante, a pesar de ser de baja fidelidad y no incluir ni colores, ni imágenes, ni contenido, se han decidido añadir algunos textos o iconos relevantes para clarificar mejor la función de cada una de las pantallas y se pueda llevar a cabo una mejor evaluación de la Arquitectura de la Información y la navegación de la app.

De esta manera se puede comprobar que el diseño del sistema cumple con los objetivos fijados al comienzo de este proyecto y se puede garantizar una buena experiencia por parte del usuario. Además, esto servirá de base en el futuro cuando se empiece con la parte de diseño UI como tal. También es especialmente útil para identificar caminos mejorables del usuario o navegación entre las distintas pantallas de contenido.

Pese a que el prototipo es interactivo y se puede visitar en la web de Figma como se indica en el enlace que hay justo al terminar los prototipos, se ha decidido incluir un punto colorido en cada una de las pantallas como simulación de los pasos del usuario para facilitar la evaluación.

A la hora de elegir la forma de presentar la información y de su accesibilidad o tamaño en la proporción de la pantalla, se ha tenido en cuenta su nivel en el árbol de contenido definido anteriormente así como la importancia de esa funcionalidad con respecto a los objetivos.

Uno de los escenarios modelados en este prototipo interactivo es el que se muestra a continuación sobre la consulta de programación y la compra de entradas por parte del usuario.

El prototipo diseñado para este escenario en concreto es el que se puede ver a continuación.

A continuación se puede consultar el prototipo interactivo siguiendo el siguiente enlace:

https://www.figma.com/file/70HgyRq8UWDfX5cw5Rd5On/MUTEK-prototype?node-id=0%3A1

Una vez que tenemos el prototipo, se pueden llevar a cabo muchos análisis mucho más exahustivos que con otras opciones menos tangibles. El usuario tiene algo con lo que puede “jugar” y es más sencillo observar sus pasos ante una posible interacción con la aplicación sin necesidad de haber invertido una gran cantidad de dinero en el diseño definitivo. De esta forma, una vez se haga la implementación del diseño, será con unos pilares mucho más seguros.

 

 

PEC 4 – Diseño Especulativo: Paradigmas de interacción.

Se conoce como diseño especulativo la manifestación por la fascinación escéptica por la tecnología que se lleva a cabo mediante el planteamiento de preguntas y la creación de escenarios que definan las posibilidades para prepararnos para retos inconvenientes y facilitar un camino al futuro más deseable y responsable. A continuación se verá cómo se aplica esa base para realizar un diseño especulativo a partir de un objeto físico cotidiano no tecnológico.

El este caso se ha elegido como objeto cotidiano una gorra. Así que descontextualizando e imaginando que es la primera vez que se ve este objeto, se podría definir de la siguiente manera:

Objeto de tela con forma redonda, que posee una visera y un cierre en los extremos opuestos.

Al ser un objeto abierto y relativamente pequeño se descartan algunas ideas como que sirva de almacenaje, funda de balón, etc. Sin embargo, sí que se puede deducir su funcionalidad analizando sus affordances, puesto que se trata de un objeto bastante simple:

  • Es de tela, por lo que podría ser una prenda de vestir.Partes de una Gorra Trucker – Aritta® ? | Tienda de Gorras
  • Tiene forma redonda, por lo que podría ser para la cabeza.
  • Tiene una visera alargada que podría proteger los ojos.
  • Tiene un cierre en el lado opuesto a la visera que podría servir para ajustarla. Aunque existan cierres de varios tipos como snapback (la tira de plástico con puntitos), hebilla o velcro, en todos los casos se intuye que son mecanismos de ajuste.

 

No obstante, dependiendo de la función que se le quiera dar, se puede ver usada en escenarios muy diferentes.

  • Como accesorio de ropa con fines estéticos: gorras conjuntadas con la ropa, sin finalidad alguna más allá de dar estilo y que puede variar su forma de uso como poner la visera hacia un lado o hacia atrás. El escenario en este caso podría ser cualquiera: en clase, en el bar, en una celebración, etc.
  • Como herramienta de protección solar: formando parte de algún uniforme o como accesorio de ropa especialmente si la persona va a estar en el exterior y hace calor. La gorra evita que el sol dé directamente en la cabeza y la visera protege los ojos de la luz para una mejor visión.
  • Con otros usos alternativos: como recaudar dinero después de una actuación en la calle, identificarse estéticamente con alguna banda urbana en concreto, pasar desapercibido y hacer más difícil que te reconozcan, o incluso como proteger los ojos de posibles golpes al ir de aceituna.

Sin embargo, no deja de ser una pieza de tela cuyas alternativas, a menos que se le añado algo de tecnología, son bastante limitadas. Pero, ¿qué pasa si se le añade tecnología a una gorra? ¿Existe alguna posibilidad de que nos sirva para comunicarnos de manera no presencial? Y mejor aún, ¿también no verbal?

Una de las principales ventajas que hacen de la gorra un objeto especialmente interesante es su continuo contacto con la cabeza. En la cabeza está el cerebro y el cerebro es realmente como el ordenador de nuestro cuerpo, por donde todo pasa y donde todo se procesa: emociones, sentimientos, memoria, movimientos, impulsos, etc. Esto hace que prácticamente toda la funcionalidad del cerebro esté al alcance, aunque sea de manera limitada.

Teniendo en cuenta esa ventaja que ofrece el objeto, la atención se centrará en cómo se puede usar esa información del cerebro para brindar la oportunidad de forzar un cambio social que mejore el futuro de las personas. Y si pensamos en futuro, irremediablemente pensamos en salud, que es lo que suele truncar esos planes a largo plazo. Además, si pensamos en salud y lo juntamos con el hecho de que la gorra se ponga en la cabeza, irremediablemente saltará la alarma de «salud mental«.

En los tiempos que corren, la salud mental ha tomado especial importancia por el ritmo de vida que llevamos y el modelo de consumo y producción en el que centramos nuestras principales actividades. Además, la pandemia ha hecho que estos números aumenten. De acuerdo a cifras oficiales, en España se produjeron en 2021 un total de 3941 suicidios. Esto es una media de 11 suicidios diarios. Además, según la OMS, en España existirían unos 20 intentos por cada suicidio. Eso significa que en un año podrían producirse en torno a 80.000 intentos de suicidio al año en España y que entre dos y cuatro millones de personas posean ideación suicida a lo largo de su vida.

Juntando estos datos con las posibilidades que ofrece una gorra al incorporarle tecnología, se ha llegado al diseño de MoodCap:

 

Por supuesto no es un diseño perfecto y se le podrían hacer cientos de modificaciones. Sin embargo, plantea un debate muy interesante sobre cómo la tecnología puede ayudar en la prevención del suicidio.

PEC 4 – Arquitectura de Información – Diseño de Navegación

Dado que en el mercado actual está prácticamente todo inventado, se pueden comparar sistemas parecidos al que se pretende implementar para tener referencias de cómo se llevan a cabo las principales funciones en algunas webs ya conocidas. De esta forma se puede analizar si el sistema objetivo se parece a lo que ya existe o, por el contrario, no sigue el estándar ya establecido y se diferencia de otras aplicaciones.

Para ello se han seleccionado dos festivales con página web y opción de compra de entradas. Se ha establecido un escenario estándar para simular el comportamiento de un usuario. En este escenario el usuario realizar un total de tres acciones siempre que sea posible: primero consulta la programación del festival, después adquiere la entrada que más le interesa y finalmente comprueba que la entrada se ha adquirido de forma correcta.

Los dos festivales elegidos son el Primavera Sound y el Mad Cool Festival, de los que se hará una breve introducción a continuación, incluyendo los enlaces pertinentes.

Primavera Sound

Primavera Sound es un festival de música que se celebra entre finales de mayo y principios de junio en Barcelona. Su primera edición tuvo lugar en el 2001 en el Pueblo Español y desde el 2005 tiene su sede en el Parque del Fórum, un recinto más grande y al lado del mar.

https://www.primaverasound.com/es

Mad Cool Festival

Mad Cool es un festival de música que se realiza en Madrid desde el año 2016. El arte, la moda, la gastronomía y el turismo se unen eclécticamente en este festival. La última edición, del año 2020, fue cancelada debido a la pandemia del COVID-19.

https://madcoolfestival.es/

 

COMPARATIVA HEURÍSTICA DE NIELSEN

Basándonos en los Principios Heurísticos de Nielsen, podemos evaluar ambas webs teniendo en cuenta si cumplen con las directrices o no. Posteriormente a la tabla, se incluirá una pequeña reflexión de por qué se ha llegado a la conclusión de que las webs cumplen o no con cada uno de esos principios.

Justificación de la tabla de evaluación heurística según Nielsen

 

A continuación, se pasará a exponer el por qué se ha considerado que cada sistema cumple o no con los diez principios establecidos por Nielsen.

  • Visibilidad: Ninguno de los sistemas hace uso de las conocidas “migas de pan”, ni muestran barras de progreso o indicadores de carga, por lo que el usuario no conoce en muchas ocasiones el estado del sistema.
  • Coincidencia: Para la información de la planificación, ambos sistemas hacen uso del diseño del cartel del festival como si fuese en papel. Además, utilizan iconos parecidos a las entradas para indicar el término.
  • Control y libertad: En el caso del Primavera Sound sí que es fácil retroceder o saltar entre varias opciones del menú, sin embargo, en el Mad Cool es necesario terminar muchos procedimientos o simplemente incluso cerrar la página puesto que el menú principal deja de ser visible.
  • Consistencia y estándares: No siguen ningún tipo de consistencia especialmente visual entre muchas de sus opciones del menú, especialmente porque ambas implican la redirección a otros sistemas de terceros, lo que puede hacer al usuario desconfiar.
  • Prevención: En ambos casos se previene al usuario de realizar una compra indeseada permitiéndole siempre comprobar los datos y haciendo inaccesibles las opciones que no están disponibles para evitar confusión.
  • Reconocer en lugar de recordar: Mucha de la información está puesta como imagen y no como texto, lo que hace que el usuario tenga que recordar parte de la información. También ocurre con algunos códigos para las entradas.
  • Flexibilidad y eficiencia: Sorprendentemente, especialmente si tenemos en cuenta la envergadura de ambos festivales, las webs no son tan eficientes y la navegación en muchas ocasiones se hace extraña y tediosa.
  • Estética y diseño: La estética se rompe especialmente al redirigir a sitios de terceros. Además incluir el cartel como una imagen plana no lo hace especialmente accesible ni adaptable a diferentes dispositivos.
  • Ayuda al usuario con errores: En el Primavera Sound es mucho más fácil cometer errores sin darte cuenta puesto que no se indica en ningún momento que los pasos a seguir son erróneos. Sin embargo, en la página de Mad Cool hacen incluso uso de memes y de humor musical para indicar que algo no ha ido bien. Por ejemplo, una foto de Justin Bieber diciendo “Is it too late now to say sorry?” al acceder a una página que no existe.
  • Ayuda y documentación: Algo especialmente sorprendente es el hecho de que ninguna de las dos ofrezca la opción de ayuda o documentación sobre el uso del sistema. Si bien es cierto que ambas incluyen información y preguntas frecuentes sobre el festival, ninguna de ellas cubre los aspectos a nivel técnico que puedan surgirle al usuario final.

 

Además, como se observa en los diagramas de flujo, tienen muchos pasos poco intuitivos como que la programación esté sólo accesible desde la página principal o incluso que la compra de entradas sea una opción difícil de encontrar, cuando es precisamente el principal objetivo de negocio.

Por otro lado, dada la limitada funcionalidad de ambos sistemas, sería complicado extraer conclusiones para el sistema que se está diseñando, salvo la idea de incluir en la página principal botones de acción a aquellas tareas que más interesen, es decir, a “ver programación” y “comprar entradas”.

 

 

PEC 3 – Definición de la Organización y el Etiquetado

Con el fin de poder clarificar el resultado obtenido del card-sorting y cómo ha debido evolucionar la arquitectura de la información según estos datos, se ha pasado a la realización de un árbol de contenido. ­Esta estructura se muestra a continuación.

Se han realizado los siguientes cambios a la arquitectura de la información:

  1. Se ha sustituido «Programación» por «Actuaciones».
  2. La «Compra de entradas» ha pasado a «Entradas» en vez de tener que acceder primero a la actuación para la que se quieren adquirir los boletos.
  3. La «Gestión de comentarios» ha pasado de ser algo único del Artista, a ser también parte del rol de Gestor.
  4. El descuento en las entradas para el artista ha pasado de ser parte del perfil del artista, a ser una opción en el proceso de compra de las entradas del perfil de espectador.

Con estos cambios se pretende hacer la navegación en la información más accesible e intuitiva para el usuario. El resultado final sería éste:

PEC 2 Evaluación de Usabilidad – Evaluación Heurística de Instagram

Instagram es una red social muy popular hoy en día que ofrece la posibilidad de compartir fotos y vídeos con otros usuarios y poder recibir feedback con comentarios y «likes». Además se le han ido añadiendo funciones adicionales a medida que ha ido pasando el tiempo como el envío de mensajes, compartir publicaciones o las videollamadas en grupo. Pero, ¿cuál es la historia de esta red social y cuánto ha crecido desde su creación?

 

Persona Sosteniendo Smartphone Tomando Fotografías Del Puente Durante El DíaInstagram se publicó en 2010 en la App Store, ya que la idea inicial era que se tratase de una aplicación exclusiva para iPhone. No obstante, al ver su auge y popularidad entre los usuarios, en 2012 acabó saliendo también para Android. Una de las muestras de su éxito es que el primer día que estuvo disponible para Android se la descargaron la escalofriante cifra de más de un millón de usuarios. Y su alcance no ha dejado de crecer hasta alcanzar un total de 1.478 millones de usuarios a finales de 2021. Entonces, si se trata de una aplicación tan conocida, debería ser perfecta a nivel de usabilidad ¿no es así? De hecho, esta aplicación está tan integrada en la rutina de muchas personas y empresas que llega incluso a ser el trabajo de muchas marcas y gente conocida como «influencers».

Sin embargo, lejos de lo que pueda parecer, han sido numerosas veces las que muchas personas, especialmente famosas, han tenido problemas por publicar contenido que querían que sólo viese parte de la audiencia o contenido que no debía ir a esta red social. En este artículo me he propuesto el reto de  encontrar y exponer «fallos» o elementos de mejora en el diseño de este sistema. Pero, ¿cómo?

Para una primera toma de contacto con el sistema a nivel analítico, se ha llevado a cabo una inspección de la completa interfaz de la aplicación desde un rol crítico y no como una mera usuaria, que es lo que se conoce como evaluación heurística. Este tipo de evaluación se realiza por parte del diseñador como punto de partida a alto nivel, por lo que no se ha recurrido a terceras personas por el momento.

A lo largo de la historia se han publicado varias listas de principios heurísticos que se deben tener en cuenta a la hora de evaluar heurísticamente. Una de las más famosas y utilizadas en el mundo de la usabilidad es la de los 10 principios de Nielsen y será la que emplearé a lo largo de esta evaluación.

El procedimiento que se ha seguido ha sido intentar llevar a cabo las funciones principales que se ofrecen en la aplicación e ir apuntando los problemas que encuentro en un cuaderno que tenía al lado, para evitar detener el recorrido. Además, iba grabando la pantalla durante el proceso para luego poder generar clips de vídeo donde se vieran claramente los problemas. Posteriormente, se han clasificado según el principio que siguen o incumplen.

 

Evaluación de los 10 principios de Nielsen en Instagram

1. Visibilidad del estado del sistema.

«El sistema siempre debe mantener informados a los usuarios sobre lo que está sucediendo, a través de comentarios apropiados dentro de un tiempo razonable».

Ejemplo 1.1: Cuando el usuario sube una foto a lo que se conoce como «feed», es decir, la cuadrícula de perfil en la que se quedan las fotos permanentes que se publican en la plataforma, una vez pulsa el  «tick azul» correspondiente a publicar, la aplicación muestra una pequeña franja donde aparece la palabra «finalizando» entre los conocidos como «stories» y la publicación que se muestra inicialmente. Finalmente, la foto aparece en la página de inicio de la aplicación y también en el perfil del usuario.

Como se puede ver en el GIF derecho, instagram no permite la grabación de la parte de edición de fotos, por lo que se adjunta un pantallazo a continuación del tick al que me refería anteriormente.

Podemos concluir que el usuario sabe el estado de su publicación en todo momento con los mensajes de «procesando», «finalizando» y por último viendo su foto ya publicado.

Práctica: buena

 

Ejemplo 1.2: El usuario activo manda una solicitud de seguimiento a la cuenta de otro usuario (pasivo) que es privada, por lo que necesita que el dueño de la cuenta acepte una solicitud de seguimiento. Una vez la manda, aparecerá como «Pendiente». En este preciso ejemplo, el usuario pasivo decide eliminar la solicitud de seguimiento puesto que no quiere que el usuario activo acceda a su contenido. No obstante, el activo nunca es notificado de la decisión de la persona que lleva la cuenta privada, sólo lo sabrá si decide volver a buscarla, puesto que entonces aparecerá como si nunca le hubiese mandado esa petición, es decir, habrá desaparecido el estado de «pendiente». En este caso, el usuario activo no es informado del estado de su solicitud en todos los casos. Únicamente se le notificará si ésta se aprueba.

Aunque esta funcionalidad supongo que intenta proteger al usuario de la cuenta privada, lo cierto es que puede causar confusión al usuario activo que manda la petición, ya que puede llegar a pensar que por un error no se llegó a mandar. Esto puede hacer que le vuelva a insistir, algo molesto para el usuario pasivo.

 

Práctica: regular

 


2. Adecuación entre el sistema y el mundo real.

«El sistema debería hablar el lenguaje de los usuarios mediante palabras, frases y conceptos que sean familiares al usuario, más que con términos relacionados con el sistema. Seguir las convenciones del mundo real, haciendo que la información aparezca en un orden natural y lógico».

Ejemplo 2.1: Cuando el usuario accede a la página principal de la aplicación, se encuentra con que hay un menú que parece el principal abajo y algunas opciones trasladadas a la esquina superior derecha. Si decide tocar el símbolo del «+» intuyendo que eso significa subir contenido, se desplegará un menú. En este menú aparecen las opciones de «Publicar», «Historia», «Reel» y «Transmitir en directo». Esta serie de opciones pueden resultar evidentes para un usuario habitual de la aplicación. Sin embargo, si se trata de un usuario nuevo en la aplicación, es prácticamente imposible que recuerde o intuya el significado de las mismas. Si bien es cierto que la primera vez que accedes a cada una de ellas la aplicación te hace una breve explicación de en qué consisten, resulta complejo averiguar que «Publicar» se corresponde con una foto permanente, mientras que «historia» será una foto que tan sólo sea accesible durante 24 horas.

En este caso, la aplicación no está haciendo uso de lenguaje o términos reconocidos en el mundo real, por lo que no se trata de algo intuitivo para el usuario. No obstante, quizás esta idea se fundamente en una estrategia de marketing en la que el sistema crea sus propios términos para distinguirse del resto y crear así una identidad de marca. Ante esta situación, habría que poner en una balanza ambos conceptos para ver a qué se le quiere dar prioridad o cómo integrar esos términos mejor.

Práctica: mala

 


3. Libertad y control por parte de la persona usuaria.

«Es posible que los usuarios elegirán las funciones del sistema por error y necesitarán una “salida de emergencia” claramente marcada para dejar el estado no deseado al que accedieron, sin tener que pasar por una serie de pasos. Se deben apoyar las funciones de deshacer y rehacer».

 

 

 

Ejemplo 3.1: En caso de que el usuario haya publicado por error una imagen que no quería, podrá eliminarla. Para ello tan sólo necesitará buscar la imagen, pinchar en el menú de tres puntitos que hay en la esquina superior derecha de la imagen y borrarla. Esto le da poder y control sobre sus actos. Además, incluso la propia función de eliminar es reversible y podemos recuperar la foto.

 

Práctica: buena

 

 

 

 

 

 

Ejemplo 3.2: Otro de los casos donde es aplicable es en el envío de mensajes. Si el usuario se ha equivocado al mandarlo, a no ser que el otro usuario lo haya abierto, se podrá anular el envío y se borrará el mensaje. En este caso, si anulamos el envío y luego descubrimos que sí que lo queríamos enviar, tendremos que volver a escribir el mensaje. →

Práctica: buena

 

 

 


4. Consistencia y estándares.

«Los usuarios no deberían cuestionarse si acciones, situaciones o palabras diferentes significan en realidad la misma cosa; siga las convenciones establecidas».

 

Ejemplo 4.1: Uno de los iconos universales más usados para el conocido «me gusta» en redes sociales es el corazón como podemos ver en la captura de pantalla, justo a la izquierda debajo de la foto. Esta idea se aplica en otras redes sociales como Twitter, Facebook, etc. Sin embargo, si nos fijamos en la esquina superior derecha, podemos ver que hay otro corazón. A diferencia de lo que pueda dar a entender como ser otra forma de dar «me gusta» a algo, se trata del botón para consultar las notificaciones. Quizás tendría algo de sentido si fuese únicamente para consultar las notificaciones de «me gusta» del perfil del usuario, sin embargo, en ese mismo símbolo se recogen también las notificaciones de comentarios o de nuevas cuentas que siguen a la del usuario. Esto puede llevar a equivocaciones y malinterpretaciones por parte del usuario, ya que está acostumbrado a iconos más representativos como la campanita.

Hay otros ejemplos en los que la simbología sí que concuerda con la mayoría de sistemas y de convenciones como el icono para los comentarios o el de guardar. También está el de enviar que, aunque menos intuitivo y parecido a otras aplicaciones, sí que se podría llegar a deducir.

Práctica: mala

 


5. Prevención de errores.

«Mucho mejor que un buen diseño de mensajes de error es realizar un diseño cuidadoso que prevenga la ocurrencia de problemas».

Ejemplo 5.1: Si el usuario trata de publicar una imagen permanente en su «feed», es decir, en la cuadrícula de su perfil, cuando no dispone de conexión a internet, la aplicación no informará de ningún error. En este caso, la publicación se quedará en «standby» y se publicará una vez que el dispositivo vuelva a tener conexión a internet. Ésta es una buena técnica para no interferir en la intención del usuario ni responsabilizar a éste de que vuelva a acordarse de intentarlo. No obstante, como veremos que pasa con las historias en el principio de «ayuda a reconocer y diagnosticar errores», sí que es cierto que el mensaje presentado podría ser algo más preciso e informar de cuál es el error exacto que está impidiendo que la foto se publique en la red.

Práctica: regular

 


6. Reconocimiento antes que recuerdo.

«Se deben hacer visibles los objetos, acciones y opciones. El usuario no tendría que recordar la información que se le da en una parte del proceso, para seguir adelante. Las instrucciones para el uso del sistema deben estar a la vista o ser fácilmente recuperables cuando sea necesario».

Ejemplo 6.1: A pesar de que la idea inicial de Instagram era el poder seguir cuentas concretas de usuarios, al cabo de los años ha implementado una nueva funcionalidad basada en poder seguir también lo que se conoce como «hashtags». Los hashtags son etiquetas que definen la temática de las publicaciones. Basta con que el usuario busque un tema en el que esté interesado, acceda al hashtag y lo siga. A partir de ahí, las publicaciones que contentan esa etiqueta también le aparecerán en la página de inicio como si de una cuenta se tratase.

Ésta es una buena implementación de «reconocer antes que recordar» puesto que los temas interesantes para el usuario ya le aparecerán en el inicio, sin la necesidad de buscarlos cada vez que los quiera consultar.

Práctica: buena

 


7. Flexibilidad y eficiencia en el uso.

«La presencia de aceleradores, que no son vistos por los usuarios novatos, puede ofrecer una interacción más rápida a los usuarios expertos que la que el sistema puede proveer a los usuarios de todo tipo. Se debe permitir que los usuarios adapten el sistema para usos frecuentes».

 

 

 

Ejemplo 7.1: Para un usuario avanzado, la forma de publicar una historia será deslizando de izquierda a derecha desde la pantalla inicial para que se abra directamente la cámara desde la que poder grabar o hacer fotos. Es, por así decirlo, la manera más rápida. Sin embargo, para un usuario novato, la forma más o menos intuitiva es pulsar el símbolo del «+» y posteriormente en «historia». Este es un claro ejemplo de un atajo incorporado en la aplicación para brindarle mayor flexibilidad y poder capturar los momentos más rápidamente.

 

 

Práctica: buena

 

 

 


8. Diseño estético y minimalista.

«Los diálogos no deben contener información que es irrelevante o poco usada. Cada unidad extra de información en un diálogo, compite con las unidades de información relevante y disminuye su visibilidad relativa».

Ejemplo 8.1: Al eliminar una historia (publicación de 24 horas) o una publicación permanente, aparecen respectivamente estos diálogos. Si bien es cierto que es información relevante, se trata de mucha información condensada en un mensaje. El tipo de letra ayuda a distinguir las partes más importantes del mensaje, pero el diálogo ocupa casi la pantalla en su totalidad. Además, aparece siempre que se elimina la publicación, no únicamente las primeras veces hasta que aprendamos a usarla.

Práctica: regular

 

 

 


9. Ayuda a las personas usuarias a reconocer y diagnosticar los errores y a recuperarse.

«Los mensajes de error se deben entregar en un lenguaje claro y simple, indicando en forma precisa el problema y sugerir una solución constructiva al problema».

Ejemplo 9.1: Cuando el usuario intenta iniciar sesión, la aplicación informa de qué parte de la información introducida es incorrecta. En caso de que la contraseña sea errónea, te pregunta si has olvidado la contraseña de tu cuenta. Por otro lado si el nombre de usuario contiene algún tipo de error de escritura y justo esa cuenta no existe, te informa de ello para que rectifiques. En este caso, la implementación es buena desde un punto de vista de usabilidad, ya que muchas aplicaciones deciden no incluir qué parámetro falla por motivos de seguridad.

Práctica: buena

 

 

Ejemplo 9.2: No obstante, que un principio se cumple en algunos casos, no significa que se cumpla en todos. Un ejemplo muy claro es cuando no disponemos de conexión a internet e intentamos publicar una historia. En este caso aparece una exclamación roja en la que, al acceder, te indica «No se ha podido subir» y te da la opción de reintentarlo. Sin embargo, si no somos conscientes de que no estamos conectados a internet, lo más seguro es que pensemos que es fallo de la aplicación. Al no dar información precisa de cuál es el problema, no ayuda a que el usuario lo pueda resolver rápido y volver a utilizar la aplicación con normalidad.

Práctica: mala

 

 

 

 


10. Ayuda y documentación.

«Incluso en los casos en que el sistema pueda ser usado sin documentación, podría ser necesario ofrecer ayuda y documentación. Dicha información debería ser fácil de buscar, estar enfocada en las tareas del usuario, con una lista concreta de pasos a desarrollar y no ser demasiado extensa».

Ejemplo 10.1: Algo que como usuaria había pasado totalmente desapercibido para mí es que instagram dispone de un «servicio de ayuda» donde se responden las principales dudas del uso y funcionamiento de la aplicación. Sin embargo, para cumplir con el principio, en mi opinión creo que está un poco «escondido» y quizás no muy accesible para la mayoría de usuarios. Para acceder al servicio, hay que ir a Perfil > Configuración > Ayuda > Servicio de ayuda y una vez en la página, ya sí navegar a través de sus innumerables opciones y preguntas comunes.

Lo ideal sería incluirlo de forma que fuera más accesible para el usuario y que éste no necesitara navegar por tantos niveles de menús desde el perfil del usuario.

 

Práctica: regular

 

Listado priorizado de errores y propuesta de mejora

A continuación se van a detallar los errores detectados durante el análisis heurístico ordenados de mayor a menor prioridad dependiendo del nivel al que afectan a la experiencia de usuario. Además se harán algunas propuestas de mejora como posibles soluciones a esos problemas.

1. Error: El icono de «me gusta» es el mismo que el de «notificaciones», es decir, un corazón en ambos casos.

Propuesta de mejora: Sustituir el corazón de las notificaciones por la típica campana de la que hacen uso otras aplicaciones, de forma que se puedan diferenciar mucho mejor y sea más representativa de su función.

2. Error: Al publicar una historia sin internet aparece «reintentar» y no se sube. En cambio, con las fotos permanentes sí que se nos informa que se publicará en cuanto sea posible. Ahí vemos que en un caso sí que se previene el error y en el otro no, cuando realmente son opciones muy parecidas.

Propuesta de mejora: Copiar la funcionalidad de las fotos permanentes a las historias para que se publiquen tan pronto como sea posible. Además, como se especificará en otro de los errores, concretar mejor que el error se debe a la falta de internet. De esta forma si es un error del usuario y no de la aplicación, se puede recuperar mucho más rápido.

3. Error: Cuando una petición de seguimiento es rechazada por el usuario que la recibe, no se informa al usuario que la ha realizado que ésta ha sido rechazada. Tan sólo se notifica cuando ésta ha sido aprobada. De lo contrario, aparece como si nunca se hubiese hecho.

Propuesta de mejora: Notificar al usuario de que esa petición ha sido rechazada o, al menos, dejar una mínima constancia en el perfil que ha solicitado seguir de que ya se envió una petición y se rechazó. De esta forma evitamos que el usuario piense que nunca tuvo lugar la petición y la vuelva a mandar.

4. Error: Como se explicaba en el error 2, al publicar una historia sin disponer de conexión a internet, el único error que aparece es que «no se ha podido subir» y una opción de «reintentar».

Propuesta de mejora: Especificar que el problema viene de la conexión a internet, así el usuario podría recuperarse de este error mucho más rápido como dando los datos, activando el wifi o sabiendo que tendrá que esperar a tener una conexión disponible.

5. Error: El servicio de ayuda se encuentra bastante escondido, siendo necesario acceder a varios niveles de menú para poder abrirlo. Esto puede hacer que el usuario que realmente lo necesite, no consiga encontrarlo.

Propuesta de mejora: Crear un acceso mucho más directo y visible al servicio de ayuda desde la pantalla de inicio, teniendo en cuenta que no moleste mucho en la navegación para el resto de usuarios.

6. Error: Diálogos muy extensos al eliminar una publicación permanente o una historia, donde se informa que se puede recuperar el contenido más adelante si así se desea. Aparece siempre que se elimina algo y completamente desplegada.

Propuesta de mejora: Crear un enlace con una frase sugerente como «¿Lo podré recuperar?» para que únicamente lea esa información quien no lo sepa o quien esté interesado en profundizar más en esa información. De todas formas, incluso se podría omitir, ya que es algo disponible en el menú de ayuda que queremos hacer más accesible y visible.

7. Error: En los menús de la aplicación se utilizan conceptos propios de ésta, sin una semejanza con el mundo real. La opción de «Publicar» se refiere a fotos permanentes, «Historia» a fotos que permanecen únicamente 24 y «Reel» a un vídeo corto permanente también. No obstante, se ha dejado este error como el menos importante, puesto que se puede tratar de una estrategia de marketing de diferenciación.

Propuesta de mejora: Unificar al menos las opciones del menú para que todas sean sustantivos o verbos. Además sería interesante valorar el cambio de nombre si se tratase de algo que aún no está en producción. Sin embargo, ahora que son conceptos acuñados, no está tan claro que tuviera más beneficios que problemas.

 


 

Como hemos podido concluir con este estudio, incluso las interfaces más usadas y famosas pueden llegar a tener problemas de diseño. Eso no implica que la aplicación como tal deje de usarse, pero sí que nos planteemos si realmente la experiencia de usuario es tan satisfactoria como nos quieren hacer creer al presentarnos simplemente números de los usuarios mundiales que van creciendo.

PEC2 Diseño de Interacción – Wireframe

Se conoce como Wireframe a un boceto en el que se representa visualmente la estructura de una página web o aplicación, sin entrar en detalles de contenido. Como ejemplo, se muestra a continuación un wireframe de una de las noticias del periódico portugués Público (www.publico.pt), publicada en la sección de viajes sobre la nueva apertura de un castillo en Sintra . En este caso, se ha hecho un wireframe de alta fidelidad aunque omitiendo el contenido, puesto que se trata de una página web ya existente y no del prototipo de algo que está por crear. Para ello se ha utilizado la herramienta de Balsamiq Wireframe. Se adjunta también una captura de pantalla realizada con Awesome Screenshot donde aparece la noticia al completo, así como los elementos que se han incluido en esa misma vista.

PEC 2 AI – Conceptualización de la Interacción

Se ha elegido el escenario 3 creado para David, que trata de la visualización de una de las actuaciones haciendo uso de la alternativa de Realidad Aumentada. Esta tecnología es relativamente nueva y ofrece muchas posibilidades que en un pasado eran impensables, por lo que este escenario y su correspondiente user journey son especialmente creativos, ya que es el diseñador el que pone los límites. Por supuesto hay que tener en cuenta que sea realizable y útil, pero se sale de los límites de las experiencias que puedan estar en el subconsciente del diseñador o diseñadora. Eso hace que sea un ejercicio de empatía que requiere mucho más esfuerzo y mucha más imaginación, puesto que la diseñadora no puede adaptar sus emociones o sentimientos a la forma de ser de las personas de referencia ya que no existe esa experiencia ni ninguna referencia a partir de la que desarrollarlo.

Verdaderamente ahí está el reto más grande del diseñador, pero por otro lado, también el más creativo y soñador de todos los ejemplos que tenía a su alcance.

El User Journey resultante de este escenario ha sido el siguiente.

PEC1 – Diseño de Interacción – Parte 2: Información de campo del recorrido.

Para recabar la información de campo del recorrido, se ha optado por la realización de un videoblog, obedeciendo un poco a la idea de que «una imagen vale más que mil palabras». A través de estas imágenes, se ha decidido después narrar dicho recorrido para facilitar la identificación de las diferentes acciones y su posterior agrupación en fases.

 

En este caso, se ha elegido la actividad rutinaria de salir a correr. A continuación se adjunta dicho videoblog y una posterior reflexión sobre los dispositivos, las diferentes actividades realizadas, etc.

En esta actividad, como hemos podido ver, la usuaria interacciona con 4 dispositivos principales:

  • Smartwatch
  • Auriculares inalámbricos
  • Teléfono móvil
  • Semáforo

Los pasos seguidos en orden cronológico son los siguientes:

1. Ponerse el chándal.

2. Ponerse las deportivas.

3. Hacerse una coleta.

4. Coger el móvil.

5. Coger las llaves de casa.

6. Guardar todo en la riñonera.

7. Coger los auriculares y ponérselos.

8. Encender los auriculares.

9. Vincular los auriculares con el móvil.

10. Buscar y seleccionar playlist que quiera escuchar.

11. Realizar calentamiento básico centrado en piernas.

12. Activar la opción de monitoreo en carrera del smartwatch.

13. Salir de casa.

14. Comenzar a correr.

15. Seguir corriendo y mientras:

     16. Pasar de canción*.

     17. Comprobar ritmo cardíaco*.

     18. Comprobar recorrido*.

     19. Comprobar velocidad*.

*Estas acciones son opcionales, pero suelen darse a lo largo de la rutina.

20. Pulsar el semáforo para cruzar la calle.

21. Entrar en casa.

22. Parar el monitoreo de la carrera del reloj.

23. Parar la música de la playlist.

24. Desvincular los auriculares del móvil.

25. Poner los auriculares a cargar en su caja.

26. Sincronizar los datos monitoreados del reloj al teléfono móvil.

27. Desvestirse.

28. Ducharse.

 

Una vez que tenemos todos estos pasos detallados, podemos pasar a realizar un mapa de experiencia lo más fiel posible a la realidad, pudiendo volver a consultar los medios generados en caso de surgir alguna duda.

¡Interaccionamos sin parar!

A pesar de que nuestra mente piense automáticamente que la interacción y las interfaces estás asociadas a las aplicaciones, todo nuestro alrededor es un conjunto de interfaces que condicionan nuestra vida y nuestra forma de relacionarnos con todos los objetos que nos rodean.

Una buena interfaz debería hacer que el uso de ese objeto sea fácil e intuitivo, es decir, que no tengamos que leernos el manual de instrucciones cada vez que queramos darle uso o que instintivamente ese uso que hagamos de él sea incorrecto. Además con la automatización de muchas de las tareas que se hacían manualmente y el hecho de se pretenda meter mucha funcionalidad en un mismo objeto, hace que las interfaces se vuelvan cada vez más complejas de diseñar.

Ruedas de un microondas

No obstante, en nuestro día a día hacemos uso de ellas de manera inconsciente y casi sin darnos cuenta. Uno de esos ejemplos podría ser el microondas. El que se muestra a continuación es el microondas usado a diario en casa. Lo considero un ejemplo de interfaz fácil de usar porque tiene por un lado la potencia y por otro los minutos de uso. Además, los dibujos, o mejor dicho, iconos que componen su interfaz son fáciles de identificar. Incluso acompaña texto para una mayor claridad. Por lo general, una persona capaz de identificar los números y de asociar las líneas curvadas con la potencia sería capaz de usarlo sin ningún impedimento.

Esto no es algo propio como tal del objeto, ya que hay otros muchos microondas con una interfaz más compleja y prácticamente imposibles de utilizar sin manual. Ojalá haber podido acompañar esta foto del microondas de casa con otra foto del microondas que usamos en el trabajo para poder demostrar que a veces se hace difícil lo que de por sí es fácil.

Un ejemplo de interfaz compleja o difícil de utilizar es la vieja cadena de música de mis padres. Siendo ellos unos negados completos para la tecnología, me encuentro con la situación de que me tienen que preguntar continuamente cómo usarla e incluso yo misma a veces tengo que utilizar el manual de instrucciones. Hay mucha información condensada en un espacio pequeño y botones con iconos idénticos situados en lugares diferentes y con una funcionalidad completamente distinta. Además los pocos términos que tiene escritos están en inglés, por lo que a una persona que no tenga un mínimo nivel de vocabulario le podría resultar un mundo. De hecho, como mejor prueba empírica de ello, están las veces que han roto algunas cintas o grabaron por error el contenido de una cinta en otra sin pretenderlo.

Así pues podemos concluir que nuestra interacción con los objetos que nos rodean depende en gran parte de la interfaz que tengan y no tanto en la funcionalidad que vayan a realizar. A veces algo tan simple como calentar la comida se convierte en una pesadilla que te puede hacer perder tu descanso de media hora y tener que comerte las lentejas frías. Y para funcionalidades algo más complejas, una mejor interfaz quizás hubiese evitado que grabaran Manolo Escobar en mi preciada cinta de Estopa.