user experience

Carmel Hassan > user experience

Recursos para una intro a la UX

By In Design, Technology0 Comments97 Views

Este artículo está especialmente dedicado al alumnado del Máster Front-end Lemoncode, aunque creo que puede resultar útil a cualquier persona con perfil de desarrollo que quiera comenzar a practicar y saber más sobre la Experiencia de Usuario. 

Empiezo recordando un artículo que no pasa de moda: 14 libros de UX que pueden darte una base sólida teórica y conceptual sobre Diseño y Experiencia de Usuario.

Un recurso  online gratuito y tremendamente valioso es The Encyclopedia of Human-Computer Interaction.

Una vez tengamos alguna base teórica os comparto también recursos prácticos que cualquier perfil puede intentar utilizar en su día a día desde el momento cero.

Cómo hacer entrevistas

Steve Portigal es un referente en este ámbito, su libro Interviewing Users puede resultaros útil para empezar. Aunque si lo que queremos es sacar el máximo rendimiento, podéis seguir los consejos de este artículo:  3 better questions to ask in user interviews.

Read more

Opensouthcode: resultados de la encuesta y datos de la experiencia

By In Blog, Design0 Comments79 Views
task performance opensouthcode survey

El pasado 1 de Junio mi colega Miguel Torres y yo hicimos una presentación en el evento sobre software libre Opensouthcode y hablamos sobre cómo podíamos analizar la Experiencia de Usuario (UX) con Javascript (JS). Durante nuestra charla presentamos un modelo con el que tomar métricas automáticas de usabilidad para poder conocer mejor a las personas que interactúan con nuestros productos digitales construidos con tecnologías web.

Al final de la presentación hicimos una demostración de cómo podía aplicarse a un caso real y para ellos utilizamos como excusa una encuesta que habíamos lanzado semanas antes. La encuesta no serviría más que a la presentación, sin embargo, ya que un buen número de personas se molestaron en contestarla, es nuestro deber compartir la información que recogimos.

Es importante aclarar que la forma en la que almacenamos los datos fue un poco peculiar, y por peculiar me refiero a que usamos el mismo Google Analytics, un servicio en principio destinado a analítica web. En cualquier caso, aquí están los resultados.

Read more

Ciencia de Datos y Experiencia de Usuario

By In Design, Technology0 Comments81 Views

La ciencia de datos no es algo en lo que una persona pueda especializarse en poco tiempo y es, sin embargo, una de las carreras más tendenciosas de los últimos cinco años. Si éste es un perfil profesional único como el de Experiencia de Usuario (UX) el tiempo lo dirá. Han pasado ya veintiocho años desde que Don Norman se llamara a sí mismo ‘User Experience Architect’ y al menos cincuenta desde que se hablara de la Interacción Persona-Ordenador.

Pero ¿cuál es la relación entre estas dos profesiones? ¿debe un especialista en UX saber algo sobre ciencia de datos? ¿debe un diseñador aprender a programar?

En este artículo me gustaría explicar por qué creo que es importante entender qué es la ciencia de datos y cómo puede aprovecharse desde el diseño de experiencias.

Cuantificando la Experiencia de Usuario

Si ya es difícil diseñar experiencias más de uno pensará que es casi imposible cuantificarla. Si bien no todos los factores que influyen en la interacción y la experiencia con el producto final pueden ser medibles, existen multitud de datos relacionados con la misma que pueden recogerse y analizarse para guiar el proceso de diseño:

  • Datos descriptivos de los usuarios (datos demográficos o tecnología que usan).
  • Datos de actividad y comportamiento (contenido que visitan, búsquedas, interacciones, tiempo que dedican…).
  • Conversión de objetivos.
  • Datos sobre la ejecución de tareas específicas (éxito de la tarea, duración, eficiencia, errores, satisfacción, aprendizaje).

Hasta ahora, todos estos datos los hemos venido interpretando de forma puntual y aislada buscando dar respuesta a algunas de las preguntas más importantes que nos hacemos durante el proceso:

  • ¿Cómo son nuestros usuarios? ¿cómo han llegado hasta mi producto?
  • ¿Qué necesidades de información tienen? ¿cómo interactúan para conseguirla?
  • ¿Han realizado determinada acción?
  • ¿Qué contenido funciona mejor que otro?
  • ¿Consideran que el producto es usable?

Read more

Ebury Chameleon, más que un sistema de diseño

By In Design0 Comments67 Views

En Ebury hace un año teníamos un desafío con uno de nuestros productos digitales más importantes:

¿Cómo podemos acompañar el crecimiento de un producto de éxito pero que requería con urgencia una estrategia para afrontar la deuda de diseño y tecnológica que arrastraba?

Para nosotros Ebury Chameleon representa gran parte de esa estrategia tal y como explicamos en el post recientemente publicado en nuestro blog. Ebury Chameleon es más que un ejemplo de sistema de diseño, es la definición de un sistema de componentes CSS sobre el que construimos nuestra interfaz y sobre la que definimos modelos de interacción y navegación. Es además, la filosofía que nos hace plantearnos decisiones importantes como:

  • Qué elementos deben ser reutilizables.
  • Qué grado de uniformidad y consistencia tenemos que alcanzar.
  • Cómo representamos la información en cada sección.
  • Cómo consiguen los usuarios realizar una actividad concreta.
  • Cómo podemos implementar cambios de forma poco intrusiva pero con mayor impacto.

Si quieres saber más sobre cómo hemos construido este Design System, puedes leernos en “Ebury Chameleon as an example of a Design System“.

 

La química de la experiencia (de usuario)

By In Design0 Comments65 Views

Desde el deseo o intención de uso, las expectativas, la presentación de la interfaz, pasando por la interacción de la persona con el producto, el aprovechamiento de su función y la fidelidad a lo largo del tiempo se construye un marco que podríamos denominar experiencia de usuario.

Esta relación de las personas con la tecnología pasa por establecer un lenguaje común (design system) y ciertas normas de comportamiento (interaction patterns) como mínimo. Pero ¿cuál sería la máxima aspiración que podríamos querer tener respecto a la experiencia?

Por muy Punset o muy Sinek que suene, si el objetivo del diseño para un producto es facilitar una experiencia positiva, de bienestar y felicidad ¿por qué no recordar cómo nos pueden ayudar los químicos del cuerpo a conseguirla? Las redes sociales son un gran ejemplo de cómo diseñar para aumentar los niveles de estos químicos de la felicidad.

“Hay que mirar a los otros no para fustrarse sino para cooperar” – Eduard Punset

La otredad de la tecnología

Oxitocina

Empiezo por la que seguramente es la más subestimada de todos los químicos pero el más importante: “la hormona de los vínculos emocionales” imprescindible para la supervivencia de la especie. Esta hormona dirige al resto y la solución para aumentarla es fácil: abrazar más, regalar, confiar en la gente. Es una hormona que muestra sus resultados a largo plazo, con el tiempo y el esfuerzo.

Soluciones de diseño:

Endorfinas

Las endorfinas son el más simple de todos los químicos y se considera un anestésico natural, su función es aliviar el dolor. Si queremos empezar un hábito las endorfinas nos ayudarán a eliminar el sufrimiento asociado por el esfuerzo que requiere alcanzarlo. Las endorfinas se sienten como una pequeña euforia que calma el dolor. El deporte, bailar, cantar o el trabajo en equipo aumentan el nivel de endorfinas en el cuerpo.

Soluciones de diseño:

  • Hacer una pequeña tarea de forma fácil (tu primer tuit, tu primera foto)
  • Los tours de inicio
  • Recibir un ‘me gusta’

Serotonina

La serotonina la notamos cuando nos sentimos importantes, también tiene su efecto a medio y largo plazo ya que nuevamente depende de nuestras relaciones sociales. Cuanto más respeto y reconocimiento se tiene de nosotros, mayores son los niveles de serotonina. Sentirnos orgullosos de nosotros mismos o recordar momentos felices son formas de incrementar la serotonina.

Soluciones de diseño:

  • Reputación en perfiles sociales a través de métricas (número de seguidores, de likes, etc.)
  • Recordatorios de aniversarios
  • Los tours de inicio

Dopamina

He dejado la dopamina para el final ya que se parece mucho a la serotonina pero a corto plazo. La dopamina es la responsable de la motivación. Cuando comenzamos un nuevo hábito, el mero hecho de comenzar a trabajar por un objetivo hace que se disparen los niveles de dopamina. La dopamina provoca un placer instantáneo, como comer, o incluso ver la comida ya es un disparador de este químico.

Soluciones de diseño:

Desafiar al usuario

La dopamina, enforfinas, serotonina y oxitocina son claves para sentirse bien. Cuando nuestro cerebro emite estos químicos para cumplir con su función podríamos decir que nos sentimos felices.

Cuando un producto digital plantea propósitos a sus usuarios, objetivos alcanzables, o retos interesantes, por ejemplo, lo que asegura es un entorno perfecto para provocarlos de la misma forma que provocar estos químicos nos ayudará a alcanzar esos mismos objetivos.

Un ejemplo:

Facebook te ayuda a comunicarte y compartir con las personas que forman parte de tu vida.

Facebook, al igual que muchas otras redes sociales nos desafían, nos alientan a alcanzar un objetivo que parece necesario y vital. Como red social que es, la interacción y cooperación con tus ‘contactos’ es esencial.

Sin embargo es curioso que cuando nos proponemos una meta a nivel personal muchas veces no contamos con la gente que nos rodea, creemos que es algo que debemos alcanzar solos (sólo tenéis que sondear esos propósitos de año nuevo entre vuestros amigos).

Ésto es algo que las redes sociales hacen muy bien, primero porque ponen a nuestros contactos como medio para que ‘comunicarte y compartir’ sea algo significativo. Y segundo porque como hemos visto, ésta es la base fundamental para aumentar los niveles de oxitocina: ser fieles y sentir que mantenemos las relaciones a lo largo del tiempo.

Cada pequeño paso que hacemos (publicar contenido) para cumplir el propósito (comunicarnos) nos provocará un ‘chute’ de placer instantáneo en forma de endorfinas. El esfuerzo que cuesta alcanzar el objetivo se convertirá en placer inmediato, por ello no debemos preocuparnos por si seremos capaces, ya que la satisfacción estará ligada al trabajo que invertiremos.

Por otra parte, es natural compartir cada logro una y cien veces, ésto ayudará a aumentar la serotonina y reducirá, por otra parte, el riesgo de depresión.

Finalmente, las pequeñas metas (una reacción, un comentario) provocará a que la dopamina fluya y nos ayudará a mantenernos motivados.

La ausencia del miedo

Los comportamientos que provocan las redes sociales son habitualmente del tipo proactivo, aunque como en el caso de los propósitos personales, no todos consisten en comenzar a hacer algo nuevo, sino en dejar de hacer algo que no nos conviene.

Esto tiene que ver con evitar el aumento de otro químico igualmente importante: el cortisol. Este químico que se libera en situaciones de estrés e inhibe la oxitocina, surge en situaciones de miedo o ansiedad extrema.

Tener en cuenta estas situaciones es esencial para el éxito del producto. Aspectos como la privacidad, la seguridad en términos informáticos, físicos y morales, o la autenticidad de los individuos (de los usuarios) hace que se reduzcan posibles situaciones de miedo que provoquen altos niveles de cortisol.

No debemos olvidar que algunas redes sociales también matizan o deciden los contenidos que nosotros (los usuarios) vemos con más frecuencia y más prioridad, e incluso el contexto en el que aparecen (porque es popular o lo más comentado). Este ajuste de contenidos intencionado o no también podría afectar a los niveles de cortisol.

 

 

Nota sobre este artículo

Sobra decir que yo no soy experta en química ni biología, pero todas estas cosas me resultan muy interesantes, leo sobre ellas, comparo y escribo en voz alta. Por otra parte, la relación de estos químicos con la experiencia de usuario es algo de lo que ya se ha hablado en la industria. Si te ha gustado esta entrada y tienes más enlaces interesantes me encantaría que los compartieras 🙂

 

Modelar la investigación de usuario con Patrones de Comportamiento

By In Blog, Design0 Comments87 Views

Cuando hablamos de Diseño Centrado en el Usuario siempre nos planteamos un proceso de investigación de usuarios desde donde descubrir sus características, sus circunstancias, sus expectativas y sus objetivos. Sin embargo, una vez que recogemos toda esta información debemos ser capaces de ‘traducirla’ de modo que nos permita tomar decisiones en base a ella en cualquier fase del ciclo de desarrollo.

A veces, el uso de determinados artefactos como las Personas nos ayudan a recordar qué datos son relevantes en nuestra investigación al mismo tiempo que nos ofrecen una guía sobre cómo comunicar dicha información.

Algo similar sucede con los Escenarios de uso. Una forma práctica de descubrir para quién diseñamos es identificando a todos los actores que estarían involucrados en escenarios o experiencias de uso habituales. Sería parecido como cuando estudiamos Casos de Uso pero en esta ocasión ampliaremos las miras más allá de la interacción directa con la tecnología e intentaremos analizar el contexto en el que sucede la acción.

Cuando partimos de roles que definen personas, por ejemplo, para una plataforma de aprendizaje tendríamos a estudiantes y a profesores, creemos que tenemos hecho el trabajo, asumimos los prejuicios que están asociados al rol, sin embargo no todos los roles se comportan, piensan y actúan necesariamente de la misma manera.

Siguiendo con el ejemplo, no se comporta igual un estudiante que cursa una asignatura por primera vez, que el estudiante que está cursando un grado desde hace varios años.

Considerar estos matices son los que a la hora de plantear la arquitectura de la información, la estrategia de contenidos y el diseño se tienen en cuenta en el desarrollo de la plataforma que dará soporte a la nueva herramienta.

Las investigación de usuario no debería estar basada en los prejuicios asociados al rol que se espera que cumplan en el contexto de uso de la tecnología.

Patrones de comportamiento

Una forma de modelar la información relacionada con los usuarios y sus experiencias de uso de una forma mucho más amplia y objetiva es estudiando sus modelos mentales y sus patrones de comportamiento.

En el libro Designing Interfaces nos presentan catorce patrones de comportamiento que se repiten en muchas ocasiones en las personas:

  1. Safe exploration (The user feels positive to explore and discover)
  2. Instant gratification (wants to accomplish something now)
  3. Satisfying (thinks good enough instead of best)
  4. Changes in midstream (stops in the middle)
  5. Deferred choices (skips questions and come back later)
  6. Incremental construction (performs creative activities)
  7. Habituation (use shortcuts or workarounds)
  8. Microbreaks (repeats short tasks frequently)
  9. Spatial memory (remembers things where they are)
  10. Prospective memory (wants to remember things for later)
  11. Streamlined repetition (repeats complex tasks frequently)
  12. Keyboard only (wants to use keyboard exclusively)
  13. Other people’s advice (wants the advice from others)
  14. Personal recommendations (wants to share recommendations and opinions)

Podemos usarlos como referencia a la hora de identificar de qué forma nuestra solución ayuda a estos usuarios (independientemente del rol que tengan) a usar la aplicación de una forma más eficiente.

En cuanto a los modelos mentales tomemos como el ejemplo el rol ‘Desarrollador’ en un escenario en el que esta persona accede a una web con información sobre una herramienta de desarrollo. Podríamos identificar distintos objetivos:

  • Desarrolladores que desconocen la herramienta y quieren ver si les resulta útil en sus procesos habituales de desarrollo
  • Desarrolladores que con cierta experiencia en la herramienta necesita extenderla y adaptarla a sus necesidades
  • Desarrolladores que quieren comparar esta herramienta con otras para saber si es mejor o peor opción
  • Desarrolladores que tienen muchísimas experiencia en automatización pero quieren utilizar una herramienta más mantenible, más estándar, más flexible…
  • Desarrolladores que quieren simplemente ser los primero en tuitear 🙂

Todos estos patrones no son más que arquetipos que nos ayudarán a entender mejor cuáles son las necesidades que hemos de satisfacer y dónde podríamos otorgar una oportunidad de cambio o mejora.

El rol Desarrollador ya no nos dice nada en sí mismo sin el contexto, el escenario y el objetivo. Si cambiáramos la palabra ‘desarrollador’ por ‘persona’, nos daríamos cuenta de que es prácticamente irrelevante el rol, las personas que han llegado a nuestra web ya sea porque han buscado por palabras clave o han leído un artículo que enlazaba nuestra web se comportan de un modo específico según sus objetivos y su experiencia previa, pudiendo estar en modo ‘descubrimiento’, modo ‘aprendizaje’, ‘experimentación’ o incluso en modo ‘desarrollo’.

En el libro Mental Models, la autora Indi Young nos muestra a través de un ejemplo práctico cómo llevar a cabo dicha investigación. Recomiendo su lectura para entender mejor dicho enfoque.

Cómo adoptar un proceso de diseño centrado en el usuario en equipos ágiles

By In Blog, Design0 Comments87 Views

Es bastante común en las empresas de desarrollo tener equipos enteros trabajando mediante metodologías ágiles mucho antes de incorporar ningún rol especializado en Experiencia de Usuario. Incluso cuando cuentan con Diseñadores Gráficos, los referentes clásicos en prácticas como Scrum o Kanban no son muy explícitos en cómo o cuándo deben participar dichos roles durante el proceso. Cuando estos equipos necesitan de una vez por todas tomar una estrategia donde el producto que desarrollan sí tenga en cuenta al usuario para el que está destinado surgen las preguntas: cómo lo hacemos.

Diseñadores de …

Hace unos años cuando preguntaba a los desarrolladores qué esperaban de mí como diseñadora respondían algo así:

Espero que los diseñadores me entreguen un diseño de las pantallas y los flujos donde quede claro cómo debe comportarse la aplicación. Todo esto lo espero antes de empezar a trabajar en una User Story.

Básicamente proponían que el lugar de un diseñador era el de crear especificaciones (las interfaces de usuario vendrían a sustituir los diagramas de casos de uso, de flujo y modelado de negocio) siempre desde el lado del producto (ya que durante el desarrollo ni se nos ve ni se nos espera).

Evidentemente hoy en día no se concibe que un desarrollador sea ajeno al qué debe tener un producto al igual que no es realista que un diseñador no participe en el cómo debe funcionar. Sin embargo, las fórmulas para combinar a estos roles tan especializados dentro del flujo de trabajo ágil no resultan aún claras y, peor aún, generan la sensación de que aún existe más carga de trabajo.

La metodología como producto

Cuando se empieza a poner en práctica algo que hasta entonces no se había hecho o no había dado resultado tenemos que tener en cuenta que pueden llegar fricciones: hay que balancear la cantidad de cosas nuevas que se tienen que adoptar, lo bien o mal que nos las llevamos a la práctica y/o lo útil que resultan para el producto o el equipo.

Si consideramos la metodología de diseño centrado en el usuario como un producto, el equipo serían nuestros usuarios, por lo tanto la ‘percepción’ que tengan es tan importante como la propia eficacia y eficiencia de la metodología.

A continuación expongo algunas ideas sobre cómo enfocar ciertas actividades típicas de metodologías de trabajo como Kanban o Scrum para incorporar prácticas de análisis, diseño y validación para el desarrollo de productos con una mejor Experiencia de Usuario.

User Stories

La idea de las user stories o historias de usuario en desarrollo es muy sencilla, se han usado durante muchos años en la industria, aunque no fue hasta los años 90 que comenzó a recomendarse el uso de una plantilla en la que no sólo se contaba la historia desde la perspectiva del usuario, sino que que se añadía cierto contexto e intencionalidad. La plantilla más sencilla es la siguiente:

As a [type of user]

I want to [do something]

So that I can [get some benefit]

Las historias de usuario son una oportunidad para comenzar la conversación con el equipo de desarrollo y de producto incluyendo la información que hemos obtenido en nuestra investigación.

Type of user (Persona). No hablaremos solamente de tipos de usuarios, sino que podremos ser más específicos y mencionar a la Persona protagonista (la cual lleva consigo una información de valor que podría considerarse parte de los requisitos no funcionales de la plataforma).

Do something (Motivation). Cada historia de usuario debería estar enfocada a resolver un problema concreto, éste problema vendría especificado por la necesidad de un usuario a realizar una actividad.

Get some benefit (Expected outcome). Las actividades y necesidades que los usuarios quieren poder hacer con nuestra solución buscan alcanzar un objetivo concreto, incluirlo como parte de la historia nos ayudará a entender el propósito e incluso a identificar escenarios de test.

Backlog

El backlog es la herramienta que se utilizar para gestionar las User Stories que definen el producto digital, aunque también se incluyen otros conceptos como Epics (User Story de gran tamaño) y Themes (conjunto de epics). Organizar un y priorizarlo no es una tarea menor, aunque se simplifica si mantenemos claro los objetivos y creamos ciertas convenciones.

  1. Epics y Themes deben servir para crear una visión de producto a alto nivel
  2. Las User Sotries deben facilitar la ejecución y entrega del producto

A mí me gusta trabajar con prototipos de baja fidelidad para el primer objetivo y refinar con prototipos de alta fidelidad para el segundo. Es importante considerar para este segundo caso la velocidad a la que se tienen que tomar ciertas decisiones, la cual es posible alcanzar si se han creado recursos como guías de estilo y componentes de la Interfaz de Usuario (UI en sus siglas en inglés).

Desde el aspecto de la validación también se puede trabajar a diferentes niveles de acuerdo con estos objetivos.

Para el objetivo primero definiremos los escenarios que pueden ser más interesantes testear y los KPIs que nos indicarán el resultado y para el segundo la métrica que ayudará a calcular dichos KPIs.

Hay equipos que trabajan con dos backlogs (product backlog y sprint backlog) diferentes para cada uno de los objetivos. Esto tiene como ventaja la libertad para estructurar ambos pipelines como resulten más cómodos, pero carga de mayor trabajo a la hora de priorizar y planificar. Trabajar en un solo backlog requiere sin embargo de más consenso en la convención que quiera tomarse y cuando se trata de incorporar nuevas actividades se generará aún más fricción.

Qué podemos esperar

Cuando las cosas van bien…

  • el equipo entiende el problema y forma parte de la definición de la solución óptima
  • el equipo tiene claro los requerimientos de la solución
  • el equipo sabe lo que tiene que hacer en cada momento

Cuando las cosas van mal…

  • el equipo deja cosas sin terminar
  • el equipo deja de comunicar cosas importantes
  • el equipo hace tareas sin entender de dónde viene la necesidad
  • el equipo no va alineado

Una mánager me dijo hace tiempo algo que me encantó

No hace falta estar de acuerdo sino estar alineados.

Cuando se trata de definir procesos, podemos estar más o menos convencidos de que van a funcionar, pero si el equipo decide conjuntamente seguirlo cualquier persona que se desalinee hará que el resto no funcione de forma óptima.

La mejor estrategia es ir incorporando nuevas técnicas poco a poco, que el equipo se acostumbre a usar ciertos términos e identificar la necesidad de hacer una mejor investigación, mejor diseño y mejor testing y por lo tanto de seguir incluyendo más y mejores técnicas de diseño centrado en el usuario.

Conclusiones

Las técnicas de diseño centrado en el usuario no deben ser incompatibles con las metodologías ágiles, la forma en la que definimos el problema y describimos la solución pueden ayudar a mantener un enfoque más dirigido hacia las personas que usan el software y a conducirnos hacia soluciones que las tengan más en cuenta. Tanto lo que hacemos en diseño como la forma en lo que lo hacemos es parte de la comunicación y el proceso de entrega, así como de la creación e identificación de necesidades del producto.

La siguiente pregunta que me formulo es ¿estamos dispuestos a asumir el esfuerzo?

Tiene sentido definir un término como la Experiencia de Usuario

By In Blog, Design0 Comments91 Views

La Experiencia de Usuario (UX) es una disciplina holística, lo es todo, es el alfa y el omega, el principio y el fin, el caos y el orden y si le preguntas a un diseñador de UX te dirá que “cualquier cosa que hagas tú que no haya hecho él NO es UX”. Somos así.

UX es un término difícil de definir y, sin embargo, después de tantos años, me sigo encontrando con el mismo problema cuando tengo que explicarlo en algún taller o charla de introducción. Mejor o peor, esta es la forma en la que intento enfocar la definición del término: contando la historia sobre cómo llegué a valorar lo que significa ‘Experiencia de Usuario’.

Cómo llegué a entender el valor de la UX

En todo este tiempo de profesión creo que no llegué a entender bien la importancia de la UX hasta un día que, visitando el museo de Ciencia e Industria de Mánchester, muy recomendable por cierto, me encontré con una historia muy curiosa que me fascinó y está relacionada con la siguiente ilustración la cual representa un ‘día cualquiera’ en una fábrica algodonera.

 

IndustrialRevolutionManchester
Entre 1780 y 1820. La revolución de las máquinas

Ésta es una ilustración de cómo eran las máquinas entonces, el detalle de esta imagen está en esa niña pequeña. La razón por la que esa niña (al igual que otros niños de la época) trabajaba como un adulto era, entre otras cosas, porque las máquinas algodoneras estaban diseñadas de tal forma que obligaban para su funcionamiento que una persona, generalmente un niño, de no más de un metro de altura se moviera bajo el tejal para recoger el sobrante textil, evitar que la máquina se atrancara y mantener la cadencia de producción, incluso a riesgo de su propia salud física.

La verdad es que hasta que no vi estas imágenes no entendí el impacto tan grande y tan relevante que podía tener algo mal diseñado, mal ‘planteado’. Porque eso es lo que era, estas máquinas estaban simplemente pensadas para producir, para funcionar en un contexto mercantilista, pero no para que las manipulase un ser humano (adulto a ser posible) durante diez horas al día.

Todo esto sucede en el contexto de la Primera Revolución Industrial, época que incrustó en nuestra sociedad la creencia de que mediante la transformación tecnológica se perpetuaría la filosofía de la innovación, la modernidad y el progreso. ¿Os suena este pensamiento?

Mientras tanto el recién nacido mundo del cine comenzaba a reflejar cómo evolucionaría esta hasta la exageración proyectando distopías como la que veíamos en Metrópolis. Nada más lejos de la realidad ¿no?

Volviendo a la ciencia no ficción.

La ergonomía se ocupó entonces, y menos mal, de practicar un diseño que se adaptara a nuestras características físicas, psicológicas y ambientales. Personas, máquinas y contexto como principios fundamentales para el desarrollo de la tecnología.

Intencionada o no, las consecuencias de un buen diseño tendrían un enorme e irremediable impacto en nuestra sociedad como hemos visto. Tal y como vemos actualmente.

Seguimos con la historia y no tuvimos que esperar mucho para Revolución de la Computación. Personajes como Ada Lovelace o Alan Turing contribuyeron al surgimiento de una era histórica única, una era en la que las máquinas serían cada vez más inteligentes y sustituirán, quizá, el esfuerzo intelectual, de cálculo y procesamiento de información. La Informática como rama de estudios de todas estas ideas, nada que no sepáis.

eniac
Dos mujeres programando la ENIAC (1945-47) – US Army

Y desde este contexto, el equivalente histórico: la Interacción Persona-Ordenador, como área de conocimiento que estudia el diseño de estas ‘máquinas inteligentes’ para construirlas de acuerdo a las características de las personas que estaban destinados a usarlos.

Digamos que uno, quizá el primero, de los pasados de la Experiencia de Usuario reside desde el aspecto técnico, pero no es el único. César Astudillo lo cuenta muy bien en su artículo ‘¿Para quién luchamos?’. En el campo UX conviven ‘linajes distintos’. Como hemos visto los profesionales del diseño, pero también de las ciencias humanas, psicología, sociología, gente de negocio, de márketing y comunicación.

Pero ¿qué tenemos en común? Que todos desde nuestra forma de ejercer esta profesión vemos en la Experiencia de Usuario un espíritu de cambio. La UX surge como fenómeno transformador de la tecnología de trascendencia humanista.

La UX ya ha transformado el concepto de Usabilidad. No se limita por tanto únicamente a analizar la facilidad de uso (eficacia, eficiencia y satisfacción) de las personas que utilizan productos interactivos sino que alude también a un factor emocional del usuario. No se limita a calificar los productos de usables o útiles, sino que abarca las vivencias y las relaciones de las personas con dichos productos a lo largo del tiempo.

Como dice Nate Bolt, autor del libro Remote Research:

You don’t come up with an iPod just by making a Walkman really easy to use.

En este sentido el contexto emocional se suma al contexto de uso como factor determinante de la posible experiencia de usuario. En dicho contexto, se tienen en cuenta tanto sentimientos pre-asociados, como el actual estado de ánimo y emociones evocadas por el producto y afecta entre otras cosas a la capacidad de aprendizaje, atención, memorización, rendimiento y percepción de utilidad.

El término de UX según Donald Norman

En cualquier caso, si todo esto no ha terminado de convencerte mi sugerencia es leer y escuchar a los más grandes en este campo.

 

Diseño persuasivo, diseño alienante

By In Blog, Design, People2 Comments68 Views

Habrás escuchado una y mil veces que el diseño de interacción tiene que ser persuasivo, convincente, emocionante, tiene que motivar e influir en nuestra decisiones a la hora de interactuar con un producto o servicio.

It’s about understanding the emotions that influence people’s behavior and decision-making, and then acting on that information to design compelling user interactions

El objetivo del diseño de interacción persuasivo es modificar el comportamiento del usuario a través de las emociones usando teorías de la psicología y la sociología.

Desde luego hay otros principios básicos en diseño de interacción como los conceptuales y los de interfaz, pero en lo que concierne a la relación persona-máquina, persuadir es la clave. Persuadir, repito, para modificar el comportamiento.

La motivación de la persuasión es uno más de los límites que debemos saber identificar para no contribuir a la creación de una cultura de consumidores interactivos alienados. De esos que se convierten en el producto cuando no pagan por él. De esos cuyo tiempo de calidad lo pasan enganchados a la tecnología por puro entretenimiento.

¿Quiero decir que el entretenimiento es malo? En absoluto, lo que quiero decir es que el diseño de experiencias que persiguen la alienación de los usuarios es éticamente reprobable si se quieren seguir ciertos valores. Los que nos propone el libro About Face (una biblia para mí desde hace diez años que sigue teniendo conceptos imprescindibles) me parecen un buen punto de partida:

  • Ethical (considerate, helpful)
    • Do no harm
    • Improve human situations
  • Purposeful (useful, usable)
    • Help users achieve their goals and aspirations
    • Accommodate user contexts and capacities
  • Pragmatic (viable, feasible)
    • Help commissioning organizations achieve their goals
    • Accommodate business and technical requirements
  • Elegant (efficient, artful, affective)
    • Represent the simplest complete solution
    • Possess internal (self-revealing, understandable) coherence
    • Appropriately accommodate and stimulate cognition and emotion

Sin embargo nadie dice que esto sea fácil, más si cabe cuando las experiencias no se pueden diseñar ni construir, si acaso facilitar. Es ahora, después del uso y del tiempo cuando hemos podido identificar las consecuencias de ciertos diseños, por ejemplo, del famoso botón ‘like’. Una lectura de las experiencias de usuario generadas tras ese diseño llevada quizá al extremo la pudimos ver en el capítulo ‘Caída en picado’ de Black Mirror, donde la reputación dependen totalmente de cómo los demás te valoren y ahí está la tecnología para ‘ponerlo fácil’.

Building your own tools with existing software

By In Blog, Design, Technology0 Comments65 Views

I’m sure you’re sick to death to hear whether designers should learn to code or not.

To me, coding skills have let me create my own designer toolkit by reusing and extending current software tools. Have you ever imagine how cool would be to become your own user while developing a solution?

At the moment there are thousands of open-source apps available for anyone to improve them. Some of them do just basic things like To-Do lists apps and others are a bit more sophisticated like Chats.

I’m not even talking about libraries and that crazy need of knowing the whole universe of packages and extensions of a programming framework. I’m talking about already built-in solutions with a purpose, with an API, and with an easy-to-consume documentation.

This is an experiment that I love to make from time to time: just pick an existing tool, see the code, imagine a different purpose with the current interaction model, a different way of using the visual grammar and customise it to see how the UI paradigm will work for a different goal.

If you include yourself as the target user, as a designer no one better than you what you want and need so, you can go ahead and create something fantastic to make your life easier, funnier or more productive.

Designer, you have the power of imagination, the good habits of a well-stablished UX process, and a strong creativity and ability to conceptualise things that most people can hardly envision, you just need to know the keys to play with the code and cross the red line.

It is to me the funniest way to learn.

Soon I’ll share my latest experiment: buidling my own UX testing framework 😉