Verdaderas mentiras de las interfaces de usuario optimistas

Tres interfaces de usuario (UI) van a un pub. El primero pide un trago, luego varios más. Un par de horas después, pide la cuenta y sale borracho del bar. El segundo UI pide un trago, lo paga por adelantado, pide otro trago, lo paga y así sucesivamente, y en un par de horas sale borracho del bar. La tercera interfaz de usuario sale del pub ya borracho inmediatamente después de entrar: sabe cómo funcionan los pubs y es lo suficientemente eficiente como para no perder tiempo. ¿Habías oído hablar de este tercero? Se llama una "interfaz de usuario optimista".

Recientemente, después de haber discutido la optimización del rendimiento psicológico en una serie de conferencias dedicadas tanto al desarrollo front-end como a la experiencia de usuario, me sorprendió ver lo poco que se aborda el tema del diseño de interfaz de usuario optimista en la comunidad. Francamente, el término en sí mismo ni siquiera está bien definido. En este artículo, descubriremos en qué conceptos se basa, veremos algunos ejemplos y revisaremos su trasfondo psicológico. Después de eso, revisaremos las preocupaciones y los puntos principales sobre cómo mantener el control sobre esta técnica de UX.

Lectura adicional en SmashingMag:

• El usuario es el diseñador web anónimo
• Diseño de interfaces de usuario basadas en tarjetas
• Interfaces conversacionales: ¿dónde estamos hoy?
  

Pero antes de comenzar, a decir verdad, ninguna cosa podría llamarse una "interfaz de usuario optimista". Más bien, es el modelo mental detrás de la implementación de una interfaz. El diseño optimista de la interfaz de usuario tiene su propia historia y razón de ser.

Había una vez

Hace mucho tiempo, cuando la palabra "tweet" se aplicaba principalmente a los pájaros, Apple estaba al borde de la bancarrota y la gente todavía ponía números de fax en sus tarjetas de presentación, las interfaces web eran bastante ascéticas. Y la gran mayoría de ellos no tenía ni una pizca de optimismo. Una interacción con un botón, por ejemplo, podría seguir un escenario similar al siguiente:

1. El usuario hace clic en un botón.
2. El botón se activa en un estado deshabilitado.
3. Se envía una llamada a un servidor.
4. Una respuesta del servidor se envía de vuelta a la página.
5. La página se vuelve a cargar para reflejar el estado de la respuesta.

Esto podría parecer bastante ineficiente en 2016; sin embargo, sorprendentemente, el mismo escenario todavía se usa en muchas páginas web y aplicaciones y todavía es parte del proceso de interacción para muchos productos. La razón es que es predecible y más o menos a prueba de errores: el usuario sabe que la acción ha sido solicitada desde el servidor (el estado deshabilitado del botón lo indica), y una vez que el servidor responde, la página actualizada indica claramente el final de esta interacción cliente-servidor-cliente. Los problemas con este tipo de interacción son bastante obvios:

• El usuario tiene que esperar. A estas alturas, sabemos que incluso el retraso más breve en el tiempo de respuesta del servidor tiene un efecto negativo en la percepción que tiene el usuario de toda la marca, no solo en esta página en particular.
• Cada vez que el usuario recibe una respuesta a su acción, se presenta de una manera bastante destructiva (se carga una nueva página, en lugar de actualizar la existente), lo que rompe el contexto de la tarea del usuario y puede afectar su línea de pensamiento. Aunque no necesariamente estamos hablando de multitarea en este caso, cualquier cambio de contexto mental es desagradable. Por lo tanto, si una acción no tiene la intención inherente de cambiar de contexto (el pago en línea es un buen ejemplo de cuándo un cambio es natural), el cambio establecería un tono hostil de diálogo entre el usuario y el sistema.

Buenos tiempos no tan viejos

Luego, llegó la llamada Web 2.0 y proporcionó nuevos modos de interacción con las páginas web. El núcleo de estos fueron XMLHttpRequest y AJAX. Estos nuevos modos de interacción se complementaron con “spinners”: la forma más simple de indicador de progreso, cuyo único propósito era comunicar al usuario que el sistema está ocupado realizando alguna operación. Ahora, no necesitábamos recargar la página después de recibir una respuesta del servidor; en su lugar, podríamos simplemente actualizar una parte de la página ya renderizada. Esto hizo que la web fuera mucho más dinámica, al tiempo que permitió experiencias más fluidas y atractivas para los usuarios. La interacción típica con un botón ahora podría verse así:

1. El usuario hace clic en un botón.
2. El botón se activa en un estado deshabilitado y se muestra una rueda giratoria de algún tipo en el botón para indicar que el sistema está funcionando.
3. Se envía una llamada al servidor.
4. Una respuesta del servidor se envía de vuelta a la página.
5. El estado visual del botón y la página se actualizan según el estado de la respuesta.

Este nuevo modelo de interacción abordó uno de los problemas antes mencionados del antiguo método de interacción: la actualización de la página ocurre sin una acción destructiva, manteniendo el contexto para el usuario e involucrándolo en la interacción mucho mejor que antes.

Este tipo de patrón de interacción ha sido ampliamente utilizado en todos los medios digitales. Pero queda un problema: los usuarios todavía tienen que esperar una respuesta del servidor. Sí, podemos hacer que nuestros servidores respondan más rápido, pero no importa cuánto intentemos acelerar la infraestructura, los usuarios todavía tienen que esperar. Nuevamente, a los usuarios no les gusta esperar, por decirlo suavemente. Por ejemplo, la investigación muestra que el 78% de los consumidores sienten emociones negativas como resultado de sitios web lentos o poco confiables. Además, según una encuesta realizada por Harris Interactive para Tealeaf, el 23 % de los usuarios confiesa haber maldecido sus teléfonos, el 11 % les ha gritado y un 4 % ha tirado su teléfono al experimentar un problema con una transacción en línea. Los retrasos se encuentran entre esos problemas.

Incluso si muestra algún tipo de indicador de progreso mientras el usuario espera, a menos que sea muy creativo con el indicador, hoy en día eso simplemente no es suficiente. En su mayor parte, la gente se ha acostumbrado a las flechas giratorias que indican la lentitud de un sistema. Los spinners ahora están más asociados con la espera puramente pasiva, cuando el usuario no tiene otra opción que esperar la respuesta del servidor o cerrar la pestaña o la aplicación por completo. Entonces, ideemos un paso para mejorar este tipo de interacción; veamos este concepto de una interfaz de usuario optimista.

IU optimista

Como se mencionó, una interfaz de usuario optimista no es más que una forma de manejar la interacción humano-computadora. Para comprender las ideas principales detrás de esto, nos apegaremos a nuestro escenario de "el usuario hace clic en un botón". Pero el principio será el mismo para casi cualquier tipo de interacción que desee hacer optimista. Según el Oxford English Dictionary:

op-ti-mis-tic , adj. esperanzado y confiado en el futuro.

Comencemos con la parte de "confianza en el futuro".

¿Qué opinas? ¿Con qué frecuencia tu servidor devuelve un error en alguna acción del usuario? Por ejemplo, ¿su API falla con frecuencia cuando los usuarios hacen clic en un botón? ¿O tal vez falla mucho cuando los usuarios hacen clic en un enlace? Francamente, no lo creo. Por supuesto, esto puede variar según la API, la carga del servidor, el nivel de manejo de errores y otros factores en los que usted, como desarrollador front-end o especialista en UX, podría no estar dispuesto a involucrarse. Pero siempre que la API es estable y predecible y el front-end comunica correctamente las acciones legítimas en la interfaz de usuario, entonces la cantidad de errores en respuesta a las acciones iniciadas por el usuario será bastante baja. Me atrevería a afirmar que nunca deberían superar el 1 o el 3 %. Esto significa que en el 97 al 99 % de los casos, cuando el usuario hace clic en un botón de un sitio web, la respuesta del servidor debería ser exitosa, sin errores. Esto merece ser puesto en una mejor perspectiva:

Piénsalo por un momento: si tuviéramos entre un 97 y un 99 % de certeza sobre una respuesta exitosa, podríamos confiar en el futuro de esas respuestas, bueno, al menos mucho más confiados en el futuro que el gato de Schrödinger. Podríamos escribir una historia completamente nueva sobre la interacción de los botones:

1. El usuario hace clic en un botón.
2. El estado visual del botón se activa en modo de éxito al instante.

¡Eso es todo! Al menos desde el punto de vista del usuario, no hay nada más: no hay que esperar, no mirar un botón deshabilitado y no hay otra rueda giratoria molesta. La interacción es perfecta, sin que el sistema intervenga bruscamente para recordarle al usuario sobre sí mismo.

Desde el punto de vista del desarrollador, el ciclo completo se ve así:

1. El usuario hace clic en un botón.
2. El estado visual del botón se activa en modo de éxito al instante.
3. La llamada se envía al servidor.
4. La respuesta del servidor se envía de vuelta a la página.
5. En el 97 al 99% de los casos, sabemos que la respuesta será exitosa, por lo que no necesitamos molestar al usuario.
6. Solo en el caso de una solicitud fallida, el sistema hablará. No se preocupe por esto por ahora; llegaremos a este punto más adelante en el artículo.

Veamos algunos ejemplos de interacciones optimistas. Probablemente estés familiarizado con los botones de "me gusta", que se encuentran en Facebook y Twitter. Echemos un vistazo a este último.

Comienza, obviamente, con el clic del botón. Pero tenga en cuenta el estado visual del botón cuando el usuario ya no está presionando o pasando el mouse sobre el botón. ¡Cambia al estado de éxito al instante!

Veamos qué está pasando en la pestaña "Red" de las herramientas de desarrollo de nuestro navegador en este mismo momento.

La pestaña "Red" muestra que la solicitud del servidor se ha enviado pero aún está en curso. El número del contador de "me gusta" aún no se ha incrementado, pero con el cambio de color, la interfaz está comunicando claramente el éxito al usuario, incluso antes de haber obtenido una respuesta del servidor.

Después de recibir una respuesta exitosa del servidor, el contador se actualiza, pero la transición es mucho más sutil que el cambio de color instantáneo. Esto proporciona al usuario una experiencia fluida e ininterrumpida, sin que se perciba ninguna espera.

Otro ejemplo de interacción optimista se ve en Facebook, con su propio botón Me gusta. El escenario es bastante similar, excepto que Facebook actualiza el contador al instante, junto con el color de éxito del botón, sin esperar la respuesta del servidor.

Sin embargo, una cosa a tener en cuenta aquí. Si nos fijamos en el tiempo de respuesta del servidor, veremos que es de poco más de 1 segundo . Teniendo en cuenta que el modelo RAIL recomienda 100 milisegundos como el tiempo de respuesta óptimo para una interacción simple, esto normalmente sería demasiado largo. Sin embargo, el usuario no percibe ningún tiempo de espera en este caso debido a la naturaleza optimista de esta interacción. ¡Agradable! Este es otro ejemplo de optimización del rendimiento psicológico .

Pero seamos realistas: todavía existe una probabilidad del 1 al 3% de que el servidor devuelva un error. O tal vez el usuario simplemente está desconectado. O, más probablemente, quizás el servidor devuelva lo que técnicamente es una respuesta de éxito, pero la respuesta contiene información que el cliente debe procesar más. Como resultado, el usuario no obtendrá un indicador de falla, pero tampoco podemos considerar la respuesta como un éxito. Para entender cómo lidiar con tales casos, debemos entender por qué y cómo funcionan psicológicamente las IU optimistas en primer lugar.

La psicología detrás de las IU optimistas

Hasta ahora, no he escuchado a nadie quejarse de las interacciones optimistas antes mencionadas en las principales redes sociales. Entonces, digamos que estos ejemplos nos han convencido de que las IU optimistas funcionan. Pero, ¿por qué funcionan para los usuarios? Funcionan simplemente porque la gente odia esperar. ¡Eso es, amigos! Puede pasar a la siguiente parte del artículo.

Pero si todavía estás leyendo, probablemente te interese saber por qué es así. Entonces, profundicemos un poco más en el terreno psicológico de este enfoque.

Una interfaz de usuario optimista tiene dos ingredientes básicos que merecen un análisis psicológico:

• la rápida respuesta a la acción del usuario;
• el manejo de fallas potenciales en el servidor, en la red y en otros lugares.

Respuesta rápida a la acción del usuario

Cuando hablamos de un diseño de interfaz de usuario optimista, estamos hablando de un tiempo de respuesta óptimo en la interacción humano-computadora. Y las recomendaciones para este tipo de comunicación han existido desde 1968. En ese entonces, Robert B. Miller publicó su artículo seminal "Response Time in Man-Computer Conversational Transactions" (PDF), en el que define hasta 17 diferentes tipos de respuestas que un usuario puede obtener de una computadora. Miller llama a uno de esos tipos una "respuesta a la activación del control": el retraso entre la pulsación de una tecla y la retroalimentación visual. Incluso en 1968, no debería haber excedido de 0,1 a 0,2 segundos. Sí, el modelo RAIL no es el primero en recomendar esto: el consejo existe desde hace unos 50 años. Miller señala, sin embargo, que incluso este breve retraso en la retroalimentación puede ser demasiado lento para los usuarios expertos. Esto significa que, idealmente, el usuario debería recibir un reconocimiento de su acción dentro de los 100 milisegundos . Esto está entrando en el rango de una de las acciones inconscientes más rápidas que el cuerpo humano puede realizar: un parpadeo. Por esta razón, el intervalo de 100 milisegundos suele percibirse como instantáneo. “La mayoría de las personas parpadean alrededor de 15 veces por minuto y un parpadeo dura en promedio de 100 a 150 milisegundos”, dice Davina Bristow, del Instituto de Neurología del University College London, y agrega que esto “significa que, en general, pasamos al menos 9 días al año parpadeando. ”

Debido a su respuesta visual instantánea (incluso antes de que finalice la solicitud real), una interfaz de usuario optimista es uno de los ejemplos de las técnicas de finalización temprana que se utilizan en la optimización del rendimiento psicológico. Pero el hecho de que a la gente le gusten las interfaces que responden en un abrir y cerrar de ojos no debería ser una sorpresa para la mayoría de nosotros, de verdad. Y tampoco es difícil de conseguir. Incluso en los viejos tiempos, deshabilitábamos los botones instantáneamente después de hacer clic en ellos, y esto generalmente era suficiente para reconocer la entrada del usuario. Pero un estado deshabilitado en un elemento de la interfaz significa una espera pasiva: el usuario no puede hacer nada al respecto y no tiene control sobre el proceso. Y esto es muy frustrante para el usuario. Es por eso que omitimos el estado deshabilitado por completo en una interfaz de usuario optimista: comunicamos un resultado positivo en lugar de hacer esperar al usuario.

Manejo de fallas potenciales

Pasemos al segundo aspecto psicológico interesante del diseño de interfaz de usuario optimista: el manejo de fallas potenciales. En general, hay mucha información y artículos disponibles sobre cómo manejar los errores de la interfaz de usuario de la mejor manera posible. Sin embargo, aunque veremos cómo manejar las fallas más adelante en este artículo, lo que más importa en una interfaz de usuario optimista no es cómo manejamos los errores, sino cuándo lo hacemos.

Los seres humanos organizan naturalmente su actividad en grupos, terminados por la realización de un propósito o subpropósito definido subjetivamente. A veces nos referimos a estos grupos como un "tren de pensamiento", un "flujo de pensamiento" (PDF) o simplemente un "flujo". El estado de flujo se caracteriza por el disfrute máximo, el enfoque energético y la concentración creativa. Durante un flujo, el usuario está completamente absorto en la actividad. Un tweet de Tammy Everts ilustra muy bien esto:

En la web, la duración de tales grupos de actividad es mucho más corta. Repasemos el trabajo de Robert B. Miller por un momento. Los tipos de respuesta que cita incluyen:

• una respuesta a una simple consulta de información listada;
• una respuesta a una consulta compleja en forma gráfica;
• una respuesta a “Sistema, ¿me entiendes?”

Vincula todos estos al mismo intervalo de 2 segundos dentro del cual el usuario debe obtener el tipo de respuesta relevante. Sin profundizar más, debemos señalar que este intervalo también depende de la memoria de trabajo de una persona (refiriéndose al lapso de tiempo dentro del cual una persona puede mantener una cierta cantidad de información en su cabeza y, lo que es más importante, ser capaz de manipularla). Para nosotros, como desarrolladores y especialistas en UX, esto significa que dentro de los 2 segundos de interactuar con un elemento, el usuario estará en flujo y concentrado en la respuesta que espera. Si el servidor devuelve un error durante este intervalo, el usuario todavía estará en "diálogo" con la interfaz, por así decirlo. Es similar a un diálogo entre dos personas, donde dices algo y la otra persona no está de acuerdo contigo. Imagínese si la otra persona pasara mucho tiempo asintiendo con la cabeza (el equivalente a nuestra indicación de un estado de éxito en la interfaz de usuario) pero finalmente le dijera "no". Incómodo, ¿no? Por lo tanto, una IU optimista debe comunicar la falla al usuario dentro de los 2 segundos del flujo.

Armados con la psicología de cómo manejar fallas en una interfaz de usuario optimista, finalmente lleguemos a ese 1 a 3% de solicitudes fallidas.

El lado pesimista del diseño de interfaz de usuario optimista

Con mucho, el comentario más común que escucho es que el diseño optimista de la interfaz de usuario es una especie de patrón negro: trampa, por así decirlo. Es decir, al emplearlo estamos mintiendo a nuestros usuarios sobre el resultado de su interacción. Legalmente, cualquier tribunal probablemente apoyaría este punto. Aun así, considero la técnica una predicción o una esperanza. (¿Recuerdas la definición de "optimista"? Aquí es donde dejamos algo de espacio para la parte "esperanzadora".) La diferencia entre "mentir" y "predecir" está en cómo tratas ese 1 a 3% de las solicitudes fallidas. Veamos cómo se comporta fuera de línea el optimista botón "Me gusta" de Twitter.

En primer lugar, de acuerdo con el patrón de IU optimista, el botón cambia al estado de éxito justo después de hacer clic, nuevamente, sin que el usuario presione o pase el mouse sobre el botón por más tiempo, exactamente como se comporta el botón cuando el usuario está en línea.

Pero debido a que el usuario está desconectado, la solicitud falla.

Entonces, tan pronto como sea posible dentro del flujo del usuario, se debe comunicar la falla. Nuevamente, 2 segundos suele ser la duración de dicho flujo. Twitter comunica esto de la manera más sutil posible, simplemente revirtiendo el estado del botón.

El lector concienzudo aquí podría decir que este manejo de fallas podría llevarse un paso más allá, notificando al usuario que la solicitud no se pudo enviar o que ocurrió un error. Esto haría que el sistema fuera lo más transparente posible. Pero hay una trampa, o más bien, una serie de problemas:

• Cualquier tipo de notificación que aparece repentinamente en la pantalla cambiaría el contexto del usuario, incitándolo a analizar la razón detrás de la falla, una razón que probablemente se presentaría en el mensaje de error.
• Al igual que con cualquier mensaje de error o notificación, este debe guiar al usuario en este nuevo contexto al proporcionar información procesable.
• Esa información procesable establecería otro contexto.

Bien, ahora todos podemos estar de acuerdo en que esto se está complicando un poco. Si bien este manejo de errores sería razonable para, por ejemplo, un formulario grande en un sitio web, para una acción tan simple como hacer clic en un botón Me gusta, es excesivo, tanto en términos del desarrollo técnico requerido como de la memoria de trabajo de los usuarios.

Entonces, sí, debemos ser abiertos sobre el fracaso en una IU optimista, y debemos comunicarlo lo antes posible para que nuestro optimismo no se convierta en una mentira. Pero debe ser proporcional al contexto. Para un Me gusta fallido, revertir sutilmente el botón a su estado original debería ser suficiente, es decir, a menos que al usuario le guste el estado de su pareja, en cuyo caso es mejor que funcione todo el tiempo.

Pesimismo extremo

Podría surgir otra pregunta: ¿Qué sucede si el usuario cierra la pestaña del navegador justo después de obtener un indicador de éxito pero antes de que el servidor devuelva la respuesta? El caso más desagradable sería si el usuario cierra la pestaña antes de que se haya enviado una solicitud al servidor. Pero a menos que el usuario sea extremadamente ágil o tenga la capacidad de ralentizar el tiempo, esto es casi imposible.

Si una interfaz de usuario optimista se implementa correctamente y las interacciones se aplican solo a aquellos elementos que nunca esperan más de 2 segundos por una respuesta del servidor, entonces el usuario tendría que cerrar la pestaña del navegador dentro de esa ventana de 2 segundos. Eso no es particularmente difícil con una pulsación de tecla; sin embargo, como hemos visto, en 97 a 99% de los casos, la solicitud será exitosa, ya sea que la pestaña esté activa o no (solo que no se devolverá una respuesta al cliente).

Por lo tanto, este problema puede surgir solo para el 1 al 3% que recibe un error del servidor. Por otra parte, ¿cuántos de ellos se apresuran a cerrar la pestaña en 2 segundos? A menos que estén en una competencia de velocidad de cierre de pestañas, no creo que el número sea significativo. Pero si cree que esto es relevante para su proyecto en particular y podría tener consecuencias negativas, emplee algunas herramientas para analizar el comportamiento del usuario; si la probabilidad de tal escenario es lo suficientemente alta, entonces limite la interacción optimista a elementos no críticos.

Intencionalmente no he mencionado casos en los que una solicitud se retrasa artificialmente; estos generalmente no caen bajo el paraguas del diseño de interfaz de usuario optimista. Además, hemos pasado más que suficiente tiempo en el lado pesimista de las cosas, así que resumamos algunos puntos principales sobre la implementación de una buena interfaz de usuario optimista.

Reglas de juego

Espero sinceramente que este artículo lo haya ayudado a comprender algunos de los conceptos principales detrás del diseño de interfaz de usuario optimista. Tal vez le interese probar este enfoque en su próximo proyecto. Si es así, aquí hay algunas cosas que debe tener en cuenta antes de comenzar:

• Un requisito previo para todo lo que hemos hablado hasta ahora: asegúrese de que la API en la que confía sea estable y arroje resultados predecibles. Basta de charla.
• La interfaz debe detectar posibles errores y problemas antes de que se envíe una solicitud al servidor. Mejor aún, elimine por completo cualquier cosa que pueda resultar en un error de la API. Cuanto más simple sea un elemento de la interfaz de usuario, más sencillo será hacerlo optimista.
• Aplique patrones optimistas a elementos simples de tipo binario para los que no se espera más que una respuesta de éxito o fracaso. Por ejemplo, si el clic de un botón supone una respuesta del servidor como "sí", "no" o "quizás" (todos los cuales pueden representar un éxito en diversos grados), ese botón estaría mejor sin un patrón optimista.
• Conozca los tiempos de respuesta de su API. Esto es crucial. Si sabe que el tiempo de respuesta para una solicitud en particular nunca es inferior a 2 segundos, probablemente lo mejor sea rociar algo de optimismo sobre su API primero. Como se mencionó, una interfaz de usuario optimista funciona mejor para tiempos de respuesta del servidor de menos de 2 segundos. Ir más allá podría generar resultados inesperados y muchos usuarios frustrados. Considérate advertido.
• Una interfaz de usuario optimista no se trata solo de hacer clic en los botones. El enfoque podría aplicarse a diferentes interacciones y eventos durante el ciclo de vida de una página, incluida la carga de la página. Por ejemplo, las pantallas de esqueleto siguen la misma idea: predice que el servidor responderá con éxito para completar los marcadores de posición para mostrar al usuario lo antes posible.

El diseño optimista de la interfaz de usuario no es realmente una novedad en la web, ni es una técnica particularmente avanzada, como hemos visto. Es solo otro enfoque, otro modelo mental, para ayudarlo a administrar el rendimiento percibido de su producto. Al estar basado en los aspectos psicológicos de la interacción humano-computadora, el diseño optimista de la interfaz de usuario, cuando se usa de manera inteligente, puede ayudarlo a crear experiencias mejores y más fluidas en la web, al tiempo que requiere muy poco para implementar. Pero, para que el patrón sea realmente efectivo y para evitar que nuestros productos mientan a los usuarios, debemos comprender la mecánica del diseño de interfaz de usuario optimista.

Recursos

• "Tiempo de respuesta en transacciones conversacionales hombre-computadora" (PDF), Robert B. Miller, Fall Joint Computer Conference, 1968
• "Presentamos RAIL: un modelo de rendimiento centrado en el usuario", Paul Irish, Paul Lewis, Smashing Magazine, 2015
• “Estrés de la web móvil: el impacto de la velocidad de la red en el compromiso emocional y la percepción de la marca”, Tammy Everts, Radware Blog, 2013
• Aplicaciones de Flow en el Desarrollo Humano y la Educación , Mihaly Csikszentmihalyi, 2014
• "Detalles de diseño móvil: Evite el Spinner", Luke Wroblewski, 2013
• "Por qué importa el rendimiento, Parte 2: Gestión de la percepción", Denys Mishunov, Smashing Magazine, 2015