Amazon no es una biblioteca

En un almacén de Amazon te puedes encontrar un DVD de Walking Dead cuidadosamente colocado al lado de unos pepinillos en vinagre. No, no es un ejemplo inventado, es literal:

Algunos estaréis ya familiarizados con el llamado “chaotic storage” que usan muchos almacenes: los productos se colocan básicamente al tun-tun, aprovechando cualquier espacio libre sin tener en cuenta la relación entre ellos (más allá de características técnicas como la humedad ambiente, temperatura, etc.)

El “truco” es que los productos se asocian al lugar de almacenaje en el momento de colocarlos (mediante códigos de barras), de forma que en cualquier momento si se necesitan unos pepinillos en vinagre el sistema sabe en qué puntos del almacén se pueden encontrar.

Esta técnica ofrece mucha flexibilidad, ya que no es necesario planificar cómo evolucionarán los stocks de los productos; pero además es muy eficiente, en tres sentidos:

  • Es eficiente en espacio, ya que se aprovechan mejor los huecos, y el espacio libre en general, al no tener que reservarlos para productos del mismo tipo
  • Es eficiente para organizar nuevos ítems, ya que no es necesario conocer dónde van, sino simplemente dejarlos en el primer sitio disponible
  • Y también es eficiente para recoger, ya que un mismo producto es probable encontrarlo en muchos puntos del almacén, consiguiendo así que las cuidadosamente calculadas rutas para recoger varios ítems acaben siendo más cortas

Pero…. Si este sistema de organización es tan bueno, ¿por qué no lo usan también las bibliotecas, por ejemplo?

La respuesta es que los escenarios de uso en ambos casos son distintos. Si en una biblioteca siempre buscáramos libros concretos (conociendo, por ejemplo, su título y autor) el sistema sería factible, pero la realidad es más compleja: nuestro interés en una biblioteca puede ser explorar un tema concreto, sin conocer exactamente qué buscamos; investigar en profundidad alguna cuestión, con un enfoque exhaustivo; o simplemente volver a un libro que ya cogimos en un pasado.

Antes de plantear sistemas de organización y navegación, es indispensable preguntarse si están presentes estos tres escenarios (búsqueda exploratoria, investigación exhaustiva y reencontrar) y no quedarse únicamente con la búsqueda de un elemento conocido.

La información que importa

Overwatch es un reciente videojuego desarrollado por la empresa Blizzard. Se trata de un FPS, un juego de disparos en primera persona, en el que se forman dos equipos de 6 jugadores que compiten entre sí por un cierto objetivo. La derrota o victoria está basada en lo que hace el equipo y no únicamente en el desempeño individual de cada jugador.

Es habitual en este tipo de juegos poder ver en cualquier momento de la partida cómo lo están haciendo tus compañeros, activando estadísticas varias, especialmente el número de bajas (kills) efectuadas por cada jugador.

Tabla de estadísticas del juego
Scoreboard de Battlefield 4 (tomado de Total Gaming Network) mostrando “K/D”, kills/deaths.

En algunos juegos, para estimular que los jugadores no se centren simplemente en matar, no se muestran las bajas, sino unos puntos que se otorgan según las acciones que está haciendo cada miembro del equipo.

Tabla de estadísticas, sin "kills" ni "deaths"
Scoreboard de Team Fortress 2 (tomado de Scalari.net)

Pero uno de los objetivos de diseño de Overwatch, según su director Jeffrey Kaplan, fue eliminar el individualismo y la competencia interna (entre miembros del equipo) inherente de este tipo de juegos. Para contribuir a ello tomaron una decisión interesante: no mostrar ningún dato concreto sobre los demás jugadores.

Imagenes de los jugadores sin datos de la partida actual
Scoreboard de Overwatch (tomado de The Guardian)

La arquitecta de información Abby Cobert, en “How to make sense of any mess” escribe:

The difference between information, data and content is tricky, but the important point is that the absence of content or data can be just as informing as the presence.

En Overwatch, Kaplan y su equipo han decidido eliminar datos para moldear la información que los usuarios percibirán. La realidad, del juego, sigue siendo la misma, pero al cambiar la fotografía que mostramos al jugador estamos influenciando en sus prioridades y, con ello, en su comportamiento.

En palabras de Kaplan:

So we basically stopped displaying any form of scores, kills, deaths because it really wasn’t telling the story of who was doing their job properly to win or lose as a team. And really, what it’s all about is, “Did you win or lose as a team?” None of that other stuff really matters at the end of the day.

Experto en Axure

Como algunos sabréis, sigo desde hace tiempo las andaduras del director de cine (y daily vlogger) Casey Neistat.

Este personaje, que asumo puede despertar odio y amor a partes iguales, tiene un aparente desprecio absoluto por las herramientas que utiliza para grabar. En cualquiera de sus vídeos es fácil comprobar cómo trata despreocupadamente su cámara y es habitual verle visitar tiendas de fotografía para, simplemente, cambiar la lente que acaba de destrozar en la toma anterior.

Varias veces Casey Neistat ha descrito los principios que rigen este comportamiento, pero nunca tan bien como en un reciente vídeo:

“All I want from my camera gear is to get the hell out of my way, so I can make videos”

Todo lo que hay entre él y su audiencia, dice, son dificultades a las que debe hacer frente, pero que en ningún caso son el foco u objetivo de su trabajo.

I hate camera gear. Just leave me alone so I can make movies.
Tomado de Casey Neistat

Todos los que hacemos trabajo no tangible, como arquitectura de información, estamos en una situación similar. Queremos comunicarnos con una audiencia (un cliente, un compañero de trabajo, desarrolladores, un supervisor…) y para ello usamos herramientas de prototipado, entornos para compartir ficheros, servicios de videoconferencia y obviamente el propio sistema operativo de nuestro ordenador.

Lo lógico sería que estos intermediarios digitales fueran lo menos importante de nuestra profesión, pero curiosamente no es así. En algunos cursos de formación del sector se dedican más horas a aprender a utilizar herramientas concretas que a realmente diseñar. Veo más ofertas de trabajo solicitando “Experto en Axure” que “Arquitecto de información”. Y algunos currículos parece que la única forma que tienen de justificar su experiencia es en “horas de vuelo” de Sketch.

Al final todo este asunto me recuerda a la clásica pregunta que hacen algunos curiosos a los fotógrafos: “¿saca buenas fotos esta cámara?”.

De momento, al menos, nadie me ha preguntado si mi Axure saca buenos prototipos.

Exigencia tecnológica

Llego a una puerta, agarro la barra vertical y estiro. No se abre. Estiro de nuevo. Sigue sin abrirse. Veo entonces un cartel indicando “Empujar” y una cierta sensación de estupidez me invade.

No creo que esta situación os resulte muy extraña. La tecnología nos hace sentir estúpidos cuando no sabemos utilizarla. Nos sucede con los ordenadores, los grifos del baño y constantemente con todo tipo de puertas. En The Psychology of Everyday Things, Donald Norman introduce este tipo de situaciones y las ejemplifica justamente hablando de puertas. Son las llamadas “Norman Doors”, puertas cuyo diseño nos indica que se deben abrir de una forma, pero realmente se abren al revés.

La revista Vox hizo recientemente un divertido vídeo con Norman sobre este tema:

Los que nos dedicamos a la usabilidad no solo intentamos que la tecnología, especialmente la digital, sea más fácil de comprender, aprender y utilizar; también pretendemos “evangelizar” para que cuando no sepamos utilizar algo no nos sintamos tan estúpidos, ya que en general la culpa no es nuestra, sino del diseño. ¿Pero lo estemos haciendo bien?

En el encuentro anual de profesionales de experiencia de usuario UXSpain, Asier Arranz hizo una interesante demostración en vivo de realidad virtual con unas Microsoft HoloLens. Durante la demostración intentó hacer una llamada vía Skype al centro de control del auditorio, pero a la primera no funcionó y tuvo que reiniciar Windows 10. “Esto nunca cambiará”, bromeó. Al segundo intento sí arrancó la videoconferencia y la sala estalló en un aplauso.

¿Por qué aplaudimos?

No me malinterpretéis, no le quito mérito a la charla ni al trabajo de Asier, y tengo presente que se trataba de un modelo especial, no comercializado y para desarrolladores; pero el aplauso me parece muy ilustrativo de las bajas expectativas que tenemos, me incluyo, con la tecnología digital.

Mi sensación es que ya no atribuimos tanto los problemas a nuestra torpeza, pero sustituimos la culpabilidad con simple condescendencia. Hemos llegado a un punto en que aceptamos que los programas se queden sin memoria y se bloqueen; que perdamos documentos de vez en cuando; que nuestro router deje de funcionar y tengamos que reiniciarlo (llegando al extremo de personas que compran sin ruborizarse este tipo de dispositivos); o que la mitad de llamadas que hacemos por Skype no conecten a la primera.

Nos sentimos tan identificados con el chiste de “esto nunca cambiará” al reiniciar Windows 10 que reímos implicados.

450 personas que nos dedicamos a la experiencia de usuario aplaudimos cuando algo, simplemente, se limita a funcionar como estaba previsto.

Da que pensar sobre dónde estamos realmente en la jerarquía de necesidades de Stephen P. Anderson.

Pirámide, de abajo a arriba: Functional, Reliable, Usable, Convenient, Pleasurable, Meaningful.
Modelo jerárquico de Stephen P. Anderson

 

Arquitecturas de cerveza

Michael Jackson

Es difícil escribir de alguien llamado Michael Jackson sin pensar en el rey del pop, pero hoy quiero hablar de otro Michael Jackson, un escritor y periodista inglés, que dedicó mucha tinta a una bebida que todos conocemos.

Michael Jackson sujetando uno de sus libros.
Michael Jackson (imagen promocional)

Viajó por el mundo probando cervezas y escribió libros como World Guide to Beer o el Michael Jackson’s Beer Companion, obras con gran influencia en cómo entendemos hoy en día los estilos de esta bebida.

En su clasificación, por ejemplo, diferenciaba entre “Ales” y “Lagers”, cervezas de alta o baja fermentación; y dentro de “Ales” organizaba varios estilos en dos grandes categorías: cervezas británicas y cervezas belgas. A las primeras se les atribuía el origen de la “Pale ale”, una cerveza que originalmente se hacía con maltas pálidas, y dentro de “Pale ale” describía la “India Pale Ale”, un subestilo pensado para ser exportado a la India, que incluía dosis exageradas de lúpulo por sus propiedades conservantes y bactericidas.

Los libros de Jackson utilizan esta clasificación para que el lector no solo considere las características puramente organolépticas. Jackson daba mucha importancia al contexto cultural de cada cerveza, cómo y dónde se elaboraba y cómo la llamaban los autóctonos de cada lugar.

Al principio del Beer Companion, Jackson escribe:

“No one goes into a restaurant and requests ‘a plate of food, please’. People do not simply ask for ‘a glass of wine’, without specifying, at the very least, whether they fancy red or white, dry or sweet, perhaps sparkling or still … when their mood switches from the grape to the grain, these same discerning people folk often ask simply for ‘a beer’, or perhaps name a brand, without thinking of its suitability for the mood or the moment … beer is by far the more extensively consumed, but less adequately honoured. In a small way, I want to help put right that injustice.”

BJCP

Otra clasificación reciente a la que los cerveceros dan bastante importancia es la publicada en la guía de estilo de 2015 del Beer Judge Certification Program. Esta organización se dedica básicamente a proporcionar a la comunidad unas guías de cómo debería ser una cerveza para pertenecer, o no, a un cierto estilo. Para ello usan criterios básicamente organolépticos, dando menos importancia al contexto cultural o incluso procedencia de la cerveza, a no ser que ésta sea, justamente, la que marque claras distinciones sensoriales.

Beer Judge Certification Program 2015 Style Guidelines

La guía que publican, de hecho, está pensada para ser utilizada en concursos de cerveza casera, donde los cerveceros inscriben sus creaciones y compiten en categorías concretas. Se valora, pues, no tanto las características hedónicas de cada cerveza, sino su buen encaje en el estilo en el que se ha inscrito.

Un ejemplo de este criterio es el siguiente:

“English brewers, particularly when dealing in a historical context, might separate ales from porters and stouts as types of beer (although in the next breath, saying there is no difference between porters and stouts). When dealing in even more historical contexts, they might go even further to describe ale as distinct from beer in that beer was hopped (or more highly hopped) than ale. These historical notes are important for understanding old recipes and writings, but have little relevance today in the common usages of terms describing beer.”

Este criterio es lo que provoca situaciones curiosas, como tener una categoría “IPA” (India Pale Ale) que comprende estilos como “American IPA” o “Rye IPA”, pero ignora la “English IPA” que está incluida en otra categoría llamada “Pale Commonwealth Beeer” junto a estilos como la “British Golden Ale”.

Índice de la guía de estilo del BJCP
English IPA en “Pale Commonwealth Beer”

Esta decisión, que puede parecer absurda, tiene toda la razón de ser si la analizamos desde el punto de vista de un juez de un concurso de cata: independientemente de que una “American IPA” sea una evolución histórica de la “English IPA”, los niveles de amargor y el balance de estos estilos son muy distintos. No tendría sentido hacer competir en la misma categoría cervezas tan diferentes.

Y que se decida desterrar la “English IPA” de la categoría “IPA” es pura consecuencia de la evolución del significado de la expresión “IPA”:  hoy en día, cuando un consumidor pide una IPA se espera unas características que están muy alejadas de lo que aporta una “English IPA” tradicional.

Mercadona

Visto todo lo anterior, puede sorprender que al entrar en el sitio web de Mercadona nos encontremos con solo tres distinciones de cervezas: “Especialidades”, “Normal” y “Sin alcohol”.

En “Especialidades” Mercadona no solo sitúa alguna que otra cerveza de importación tipo Grimbergen Double Ambrée, sino también referencias mundanas como una Shandy Cruzcampo (una clara) o incluso lo que llama “Cerveza Fuerte Voll-Damm” (sic).

Listado de especialidades dentro de Bebidas - Cervezas
Las “especialidades” de Mercadona

En los supermercados físicos la clasificación es parecida: sin ningún etiquetado evidente simplemente se agrupan las cervezas “normales”, realmente lagers industriales tipo pils, como podría ser una Estrella Damm; y en otro lado se nos ofrecen “especialidades” como cervezas de importación y alguna que otra cerveza artesana local.

Arquitecturas de cerveza

¿Está mal la clasificación de Mercadona? ¿Es mejor la del BJCP? ¿O quizás es Jackson quien acierta?

Antes de clasificar algo debemos preguntarnos por qué estamos clasificando y para quién lo estamos haciendo.

El libro de Jackson es una herramienta de aprendizaje para cerveceros; la guía de la BJCP un instrumento de evaluación para jueces; y Mercadona un supermercado, sin ningún interés pedagógico, para cualquier persona cuya máxima aspiración cervecera será, probablemente, “probar hoy algo nuevo”.

Crear arquitecturas, como decía Le Corbusier, es “poner en orden”. Ordenando generamos arquitecturas de las que es posible interpretar una cierta información. Nuestra responsabilidad, como arquitectos, es facilitar esa interpretación creando las arquitecturas adecuadas a la información que queremos transmitir.

Los principios de usabilidad de Nielsen

Jakob Nielsen ya no es tan popular como hace unos años, pero me atrevería a afirmar que el conjunto de principios de usabilidad más conocido sigue siendo el suyo:

  • Visibility of system status
  • Match between system and the real world
  • User control and freedom
  • Consistency and standards
  • Error prevention
  • Recognition rather than recall
  • Flexibility and efficiency of use
  • Aesthetic and minimalist design
  • Help users recognize, diagnose, and recover from errors
  • Help and documentation

Estos principios pretenden explicar problemas de usabilidad que podemos encontrar en una interfaz; pero la cuestión de la que quiero hablar es: ¿cuántos problemas explican? ¿la mayoría?

Para responder esta pregunta es práctico conocer de dónde provienen estos principios.

En el año 1990 Rolf Molich y Jakob Nielsen publicaron el artículo “Improving a human-computer dialogue” en el que describían los resultados de un estudio sobre evaluación de interfaces. En el estudio montaron un concurso, con premio y todo, que anunciaron en la revista Computerworld. Consistía en encontrar problemas de usabilidad en una interfaz diseñada con algo de mala baba por los propios autores.

Interfaz monocroma en modo texto del concurso de evaluación de usabilidad.
“The telephone index system” Seductora, ¿verdad?

Molich y Nielsen determinaron su propia lista de problemas y los compararon con los que mandaban los participantes.

El tema que nos atañe es que para inventariar los problemas que ellos detectaron se sacaron de la manga nueve principios de usabilidad “inspirados” en las “Apple Human Interface Guidelines” de 1987. Eran estos:

  • Simple and Natural Dialogue
  • Speak the User’s Language
  • Minimize the User’s Memory Load
  • Be consistent
  • Provide Feedback
  • Provide Clearly Marked Exits
  • Provide Shorcuts
  • Provide Good Error Messages
  • Error Prevention

Años más tarde, en “Usability Engineering”, un libro publicado por Nielsen, se adaptaban ligeramente los nombres de algunos principios y aparecería uno nuevo:

  • (Provide) Help and documentation

El propio Nielsen decía en el libro:

“These principles can be used to explain a large proportion of the problems one observes in user interface designs”

Ya tenemos una primera aproximación a la respuesta de nuestra pregunta: “a large proportion”; pero sigamos investigando.

Nielsen en el 94 escribió “Enhancing the explanatory power of usability heuristics” donde sintetizaba un nuevo conjunto de principios de usabilidad. Se basó en su experiencia profesional y el análisis de varios conjuntos de heurísticos de distintas compañías (como Sun, Apple y Xerox) y otros especialistas.

Planteó inicialmente una lista de siete principios que os resultaran familiares:

  • Visibility of system status
  • Match between system and the real world
  • User control and freedom
  • Consistency and standards
  • Error prevention
  • Recognition rather than recall
  • Flexibility and efficiency of use

¿Os habéis preguntado alguna vez por qué este orden y no otro?

Nielsen los “probó” con unos 250 problemas que tenía inventariados. Cada principio explicaba una cierta cantidad de dichos problemas y se limitó a ordenarlos de forma descendiente según la proporción. Es decir: existían más problemas categorizados como “Visibility of system status” que “Consistency and standards”.

A los siete principios añadió dos, menos frecuentes en general, pero importantes para poder explicar problemas “serios”:

  • Aesthetic and minimal design
  • Helping users recognize, diagnose and recover from errors

Lo divertido del asunto son las frecuencias concretas indicadas en el artículo. El primer principio solo explica un 6% de los problemas; la lista entera de nueve no llega ni al 35%.

Vamos, que más de la mitad de los problemas que podemos encontrar/cometer en una interfaz quedan fuera de los diez famosos principios de usabilidad de Nielsen.

Con esto no pretendo decir que los ignoréis. Alumnos míos saben que dedico una apasionante sesión de 4 horas a explicarlos. Considero que deben ser aprendidos e interiorizados, que son una gran herramienta para evaluar y diseñar; pero deben ser tomados como lo que son: solo un punto de partida.

¿Qué es la experiencia de usuario?

80.000 resultados en LinkedIn de diseñadores de experiencia de usuario, pero sigue la confusión generalizada y los especialistas no se ponen de acuerdo.

Peter Merholz, uno de los fundadores de la prestigiosa consultora de diseño Adaptive Path, concluye:

“there is no such thing as UX Design

Rebobinemos 30 años.

1986

Brenda Laurel, licenciada en Bellas Artes y doctora en teatro, publicaba en 1986 “Interface as Mimesis”, un capítulo del libro “User Centered System Designs”, editado por Donald Norman y Stephen Draper.

Brenda Laurel. CC BY-SA 2.5 Jon Lebkowsky - Flickr
Brenda Laurel. Foto CC BY-SA 2.5 Jon Lebkowsky (Flickr)

En el capítulo, Laurel invita a pensar en los ordenadores como un escenario de teatro en el que los usuarios pueden “experimentar un mundo”. El desafío es cómo diseñar para que puedan “entrar” en este mundo.

Comenta:

“seeking design principles for good interfaces, we must […] ask, not what the users are willing to endure, but what the ideal user experience might be, and what sort of interface might provide it”.

Y termina el capítulo diciendo:

“The idea of interface as mimesis is based on the primacy of experience. It requires us to focus, not on what we can deliver within the constraints of current technology and convention, but what kinds of experiences we want to have with interactive representations. […] It takes as its model a theory that employs logic and aesthetics to create representations that engage humans in pleasurable ways”.

Esta es, probablemente, una de las primeras veces que se utilizó la expresión “experiencia de usuario” en el ámbito de lo que hoy en día se conoce como diseño de interacción.

1995

Casi una década después, en 1995, tres miembros de Apple (Donald Norman, Jim Miller y Austin Henderson) escribieron un “organizational overview” para la “Conference on Human Factors in Computing Systems” de la ACM en el que explicaban que:

“we prefer to call [the critical aspects of human interface research and application at Apple] the User Experience”.

En 1996, en la revista “Interactions” del ACM, Lauralee Alben publicaba el artículo “Quality of experience: defining the criteria for effective interaction design”, en el que se describía cómo el jurado de la revista valoraría el concepto “calidad de la experiencia” en el concurso de diseño de interacción que organizaba:

“By ‘experience’ we mean all the aspects of how people use an interactive product: the way it feels in their hands, how well they understand how it works, how they fell about it while they’re using it, how well it serves their purposes, and how well it fits into the entire context in which they are using it.”

Dos años más tarde, Peter Merholz escribía a Donald Norman sobre el origen de la expresión “experiencia de usuario”. Su respuesta era en la línea de la definición anterior:

“I invented the term because I thought Human Interface and usability were too narrow: I wanted to cover all aspects of the person’s experience with a system, including industrial design, graphics, the interface, the physical interaction, and the manual. Since then, the term has spread widely, so much so that it is starting to lose its meaning.”

2007

Donald Norman. Popularizó la expresión "experiencia de usuario". Foto CC BY 2.0 jordanfischer Flickr
Donald Norman. Foto CC BY 2.0 jordanfischer (Flickr)

En 2007, el propio Merholz volvió a hablar con Norman, esta vez le preguntó qué pensaba sobre la expresión. La respuesta fue:

“user experience, human centered design, usability; all those things, even affordances. They just sort of entered the vocabulary and no longer have any special meaning. People use them often without having any idea why, what the word means, its origin, history, or what it’s about.”

Sin embargo, pese a la pesimista visión de Norman, en “User experience – a research agenda”, un artículo publicado en 2006, Marc Hassenzahl y Noam Tractinsky comentaban:

“UX has gained momentum in recent years, mostly as a countermovement to the dominant, task- and work-related ‘usability’ paradigm”

Y añadían:

“Ideas represented by UX are important, but by no means original. Early writings on usability already expressed the notion that manifestations of usability such as productivity or learnability are not primary. Primary is the person’s experience at the moment experienced”

En sus orígenes, pues, el propósito de la expresión “experiencia de usuario” parecía ser doble: por un lado, intentaba abarcar aspectos hedónicos del uso de una interfaz a los que no todo el mundo prestaba atención al hablar de “usabilidad”; por otro, se quería entender el uso del sistema como algo holístico que involucrara otros puntos de interacción que no fueran únicamente la propia interfaz digital.

2009

En “Understanding, scoping and defining user experience: a survey approach”, un artículo de 2009, se plasmaban las conclusiones de una investigación con 275 profesionales del sector para intentar comprender qué se entendía por experiencia de usuario. El estudio reconocía algunos problemas de definición:

  • Algunas variables ya de por sí difusas son asociadas arbitrariamente al concepto experiencia de usuario, como “emocional”, “afectivo”, “experiencial”, “hedónico”, “estético”, etc.
  • La unidad de análisis es maleable: el usuario, la interacción entre usuarios, interacciones individuales o múltiples, el servicio, etc.
  • La investigación académica está fragmentada en múltiples disciplinas y modelos teóricos como la emoción, el afecto, el valor, el placer, la belleza, etc.

El estudio también desprende algunas conclusiones y aspectos que son comunes sobre cómo entendemos la expresión, por ejemplo:

  • Reconocemos que depende del contexto y del sistema.
  • No consideramos que sea algo puramente subjetivo.
  • No lo vemos como algo nuevo; entendemos que bebe, en parte, de la investigación sobre Human Computer Interaction y está basada en prácticas de User Centered Design.

Y se reconocen al menos dos características importantes:

  • Al hablar de experiencia de usuario nos referimos a experiencias individuales, no sociales (pese a que las interacciones sociales puedan influir en la experiencia individual).
  • Hablamos de experiencia de “uso”, no de experiencias en general. Podemos usar productos, servicios, sistemas u objetos, pero no podemos usar marcas, arte, eventos ni humanos.

2010

Hoy en día existe un estándar internacional de la ISO, el 9241-210, publicado en 2010, que define formalmente qué es la experiencia de usuario.

La definición es breve y suficientemente precisa:

“A person’s perceptions and responses that result from the use or anticipated use of a product, system or service”.

2016

Actualización: Parece que Donald Norman sigue irritado por cómo se utiliza hoy en día la expresión “experienca de usuario”:

“Today that term [UX] is being horrible misused. It’s used by people to say “I’m a user experience designer: I design websites or I design apps” and they have no clues of what they’re doing and they think the experience is that simple device, the website or the app or who knows what… No! It’s everything! It’s the way you experience the world, is the way you experience your life, is the way you experience the service”.