Carmel Hassan UX & Product Designer

Diseñar con datos, más allá del A/B Testing

Resumen

Diseñar con datos parece sencillo: haces un test A/B y te quedas con la solución que más conversiones tenga ¿cierto? pero ¿somos conscientes de lo que nos dicen los datos? ¿cómo sabemos qué conviene evaluar? ¿qué hacemos si los resultados contradicen nuestras ideas originales?

¿Hay vida (y datos) más allá de los tests A/B? En esta charla me gustaría compartir algunas ideas y experiencias sobre cómo, cuándo, dónde y por qué podemos usar los datos a lo largo de un proceso de diseño para la Experiencia de Usuario, desde la investigación de usuarios (cuantitativa) hasta la toma de decisiones sobre un producto digital real.

Trataremos también de reflexionar (durante y después de la charla con un café) sobre cómo crear una cultura del diseño informado con datos, donde la experimentación y el desafío sean una constante.

Además, los datos están de moda, el diseño marca la moda, Netflix lo hace ¿qué puede salir mal?

Por qué nos importan los datos

Cuando hablamos de diseño de experiencias de usuario hablamos de diseñar para las personas. Hablamos de diseñar teniendo en cuenta que los productos que desarrollamos deben fomentar cierto tipo de actitudes que faciliten a las personas que son realmente usuarias de ese producto satisfacer sus objetivos o sus necesidades en un contexto dado.

Y con esta premisa de diseño para la experiencia, nos preguntamos ¿por qué nos importan los datos? ¿para qué necesitamos los datos quienes estamos involucrados en la toma de decisiones de un producto?

Los datos que utilizaremos en diseño nos van a hablar de la gente. Cómo son, qué hacen, con qué frecuencia lo hacen, cuántas veces. Los datos del diseño cuantificarán comportamientos y características observables de las personas. Difícilmente nos explicarán por qué hacen lo que hacen, o cuál es la intencionalidad detrás de una acción determinada.

Si, como decía Don Norman, todos somos diseñadores de alguna forma, a todos y todas nos interesa estar informados sobre quien usa nuestros productos y cómo. Ya que todos, jugando nuestro papel, decididimos y diseñamos el entorno tecnológico que nos rodea.

We are all designers. We manipulate the environment, the better to serve our needs. We select what items to own, which to have around us. We build, buy, arrange and restructure: all this is a form of design.

Don Norman

Hablamos del mismo Don Norman quien, desde su equipo de diseño en Apple, fue pionero en acuñar el término ‘Experiencia de Usuario’. Aunque la UX parecía una moda pasajera, en 2019 seguimos hablando de ella porque el objetivo que persigue es más relevante que nunca: diseñar productos para la gente que va usarlos, para que a esas personas les resulten agradables, eficaces, entretenidos, o todo a la vez. A fin de cuentas es dejar de diseñar pensando que nosotros somos los usuarios…

You are not the user

Jakob Nielsen

Y añadiría, dejar de diseñar pensando que nosotros somo Jony Ive. Ese genio diseñador/a que con tan sólo su experiencia y su habilidad es capaz de encontrar soluciones eficaces para todos los problemas de los usuarios.

Porque no somos Ive, y la mayoría de los que estamos aquí no trabajamos para Apple ni estamos constantemente creando nuevos conceptos o lenguajes de interacción debemos de incorporar cierto tipo de prácticas de investigación para facilitar el proceso creativo y que éste nos lleve hacia soluciones que podamos contrastar como eficaces, eficientes y satisfactorias.

De todas estas prácticas, me referiré específicamente a las de investigación de usuarios. Tanto a la investigación cuantitativa (la que utiliza los datos para guiar el proceso de diseño y de la que hablaremos hoy más detalladamente)

Without data you are just a person with an opinion

W. Edwards Deming

Pero también de la cualitativa, que es la que nos ayudará a lanzarnos preguntas y a entender el por qué de la información que descubrimos.

Without an opinion, you are just another person with data

Milo Jones and Philippe Silberzahn. Forbes, 2016.

Cómo diseñamos

Para diseñar con datos, primero tenemos que asumir algún proceso, alguna metodología de diseño centrado en el usuario que facilite la utilización de lo que vayamos descubriendo a la hora de tomar de decisiones. No podremos hablar de datos sin no entendemos su contexto. Y el contexto, de nuevo, lo ponen las personas.

Una forma de acercarse a los datos desde una perspectiva humanista la propone la diseñadora e ilustradora Giorgia Lupi donde explica cómo podemos empezar a diseñar formas en las que conectar números con lo que realmente representan, esto es, con el conocimiento, el comportamiento y las personas. Esta visión humanista la tendremos tanto desde la obtención o generación de los datos, como desde su visualización, procesamiento, interpretación y entendimiento de los mismos. Los datos no son números, sino personas y éstos nos harán, no más eficientes, sino más humanos.

Giorgia Lupi – Visual Manifesto, 2017

Por otra parte, tampoco podemos hablar de la tecnología que usamos para gestionar estos datos de una forma neutra. Me apropio de la frase de Donna Haraway ‘estamos dentro de lo que hacemos’. No podemos pretender que las personas que participamos de su proceso generativo no estemos decidiendo ya y construyendo su significado. Sobre todo, cuando nuestros modelos de enseñanza (enseñanza desde la perspectiva de la ingeniera, a sabiendas que comúnmente se conocen como modelos de aprendizaje desde la perspectiva del algoritmo) incluyen la utilización de datos históricos, datos impregnados de injusticias, desigualdad y carencias.

Technology is not neutral. We’re inside of what we make, and it’s inside of us. We’re living in a world of connections — and it matters which ones get made and unmade.

Donna Haraway, El manifiesto Cyborg.

Toda esta introducción no es gratuita sino que trato de dar relevancia a un tema que considero fundamental y llegar juntos a una conclusión: las historias que contamos con datos, deben empezar por mostrar empatía. La empatía como primera fase de un proceso de diseño pensado para las personas, proceso al que quizá estéis más habituados a ver representado de esta forma.


Five stages in the Design Thinking Process, Hasso-Plattner Institute of Design at Stanford

Empatizar

La empatía nos permite dos cosas importantes en diseño:

  1. Dejar a un lado nuestros prejuicios. Dejar de lado las conjeturas y ser capaces de discernir y decidir qué datos hablan de la gente y cuáles no nos dicen nada.
  2. Dirigirnos directamente a la fuente de información más relevante: los usuarios. Entender la formulación del problema desde la observación directa de quienes generan dicha información.

¿Hasta qué punto es necesario trabajar con datos relacionados con el género o la edad de las personas en productos universales? ¿Es la edad la que determina el uso, o son los prejuicios relacionados con ella?

Cuando decidimos entrevistar o analizar a esa masa de población que representa ‘el usuario objetivo’: ¿estamos diversificando o seguimos reflejando nuestra forma de ser y de pensar, nuestro aspecto, en quienes incluimos en nuestros procesos de investigación? La pregunta es ¿por qué no usamos los datos precisamente para eliminar parte de ese sesgo? Para desafiar nuestras propias creencias.

Masako Wakamiya (82 años), programadora del juego Hinadan (+50K descargas) –
KAZUHIRO NOGI/AFP/GETTY IMAGES

Una forma interesante de comenzar un proceso de investigación puede partir de trabajar con datos de poblaciones. Conocer cómo se distribuye la masa de población de los usuarios de tu producto, visualizarla puede ayudarnos a ‘centrar el tiro’ y a encontrar un balance adecuado de individuos que la representan. Podríamos partir de informes estadísticos generalistas, o bien solicitar informes ad-hoc, recoger resultados de encuestas, y analizar analíticas de uso (esa sección de ‘Audiciencia’ en Google Analytics cobra especial sentido).


Age distribution of Titanic passengers is shown with four different bin widths: (a) one year; (b) three years; (c) five years; (d) fifteen years – https://serialmentor.com/dataviz/histograms-density-plots.html

Con todo esta información podremos ya entender qué características son realmente descriptivas y utilizarlas para comenzar el ‘reclutamiento’ de usuarios para entrevistas u otro tipo de pruebas.

Como sabréis las entrevistas son una técnica clave para entender y conocer bien el contexto y las expectativas de quienes podrían usar nuestro producto. Hablando y, sobre todo, observando a la gente podremos obtener más datos sobre lo que la gente, dice, hace o piensa. ¿No sería interesante saber qué relación hay entre lo que la gente dice y lo que hace?

Esta información solemos representarla con ‘mapas de empatía’, a menudo, de forma individualizada. Si este mismo estudio lo hacemos de forma agregada, es decir agrupando personas con características parecidas, podremos obtener segmentos o cohortes de usuarios (con datos).

Definir

Con o sin mapas de empatía, otro recurso vital en una fase de definición es la utilización de personas (con datos). Las personas, en un proceso de Diseño Centrado en el Usuario, son artefactos que representan de la forma más cercana y realista posible a nuestros usuarios objetivos. Son personajes ficticios basados en hechos reales. Esos hechos pueden y deben estar soportados por el resultado de la investigación cuantitativa. Y una de las razones fundamentales por las que se utilizan es para tener presente a los usuarios y sus características durante todo el proceso de diseño. Los datos en los que se basan son de nuevo una potente fuente de información para:

  1. Descubrir patrones de comportamiento y modelos mentales. Véase en el ejemplo extraído del libro ‘Mental Models’ cómo hacemos un análisis de los procesos y subprocesos observados del comportamiento de personas. Analizar numéricamente estos comportamientos nos ayudará a conocer frecuencias y repeticiones de necesidades y objetivos concretos.
  2. Definir espectros de conocimiento. Precisamente ese conocimiento que forma parte de la experiencia previa y que influirá posiblemente en el uso del producto. Ya sabemos que los modelos mentales de nuestros usuarios determinan su forma de pensar y de actuar en base a su experiencia pasada, por lo tanto, cuantificar lo que les resulta familiar facilita el diseño de eso que llamamos interfaces ‘intuititivas’.
  3. Y ya dependiendo del volumen y calidad de los datos podríamos llegar a identificar tendencias o predicciones.

Éste es un buen punto en el proceso en el que, con datos, podemos empezar a definir con algo más de precisión qué hace especiales a nuestros usuarios, quién encaja dentro de lo que entendemos como ‘usuario intermedio’ y quién dentro de esos ‘usuarios extremos’. Ese ‘type of user’, esa ‘arquetipo’ (persona en inglés), que vemos simplificado a menudo, esconde detrás mucha información. Representa el contexto, el escenario en el que surge la acción.

As a [type of user], I want to [do something] so that I can [get some benefit]

Sin contexto, sin escenario, no hay historia y sin historias no tendríamos eso que llamamos ‘historias de usuario’. A fin de cuentas, las historias de usuario, presentes en todo el proceso de diseño y de desarrollo nos comunican información esencial para la toma decisiones: quién es protagonista de la acción, cuál es la necesidad y cuál la expectativa.

Idear

Aquí hemos venido a hablar de diseño, pero aún no hemos pasado ni por la fase de ideación. Una fase explorativa, creativa y divergente en la que vamos a empezar a generar soluciones sin demasiadas limitaciones.

En una fase de ideación, algo tan concreto y específico como un dato, un valor numérico, más allá que como ‘entrada’ de información, como fuente de información, no parece tener mucha utilidad. Pero me gustaría destacar dos cosas importantes sobre las ideas:

Que las ideas no son más que conjeturas, supuestos en los que ya estamos tomando decisiones de diseño. Por ejemplo, entre muchas técnicas de ideación, hay una denominada diseño especulativo, ése que comienza con preguntas ‘What if…’ (¿Qué pasaría si…?). Ésta filosofía del ‘como si’ nos fuerza a plantear posibles futuros.

¿Qué pasaría si en el futuro todo el mundo se desplazara con vehículos eléctricos?

Si os fijáis, ésta dinámica de pensamiento es muy parecida a lo que hacemos con un test de hipótesis o una prueba de significación: partiendo de un presente conocido, controlado, válido, consideramos una hipótesis alternativa posible. Lo que hay detrás de esta idea no es más que la base teórica de lo que conocemos como tests A/B. Resumiendo mucho un test A/B consiste en lanzar dos versiones de un mismo producto (la controlada y conocida y la alternativa plausible) y comprobar cuál de las dos funcionar mejor.

Ya que las hipótesis nos dirigen hacia soluciones de diseño, esto me lleva a concluir también que las ideas tienen que validarse.

El caso Netflix

Ya que estamos hablando de tests A/B y validación os voy a contar una pequeña historia de un servicio que quizá os resulte familiar y representa mejor que nadie ésta forma de usar los datos.

Netflix fue fundada en Los Gatos, California, en 1998, como un negocio de suscripción de venta y alquiler de DVDs. Uno de las razones de su rápido crecimiento al comienzo fue debido a su cuidada selección de películas y series, hasta que 2007 la tecnología se puso de su lado y se introdujeron en el modelo de vídeo bajo demanda por Internet (sin abandonar su servicio original de distribución de DVDs). En Octubre del año pasado, Netflix alcanzó los 137 millones de clientes en más de 40 países. La historia de Netflix la podéis leer con más detalle en Wikipedia por supuesto. Pero a mí me interesa que echemos un vistazo al diseño de su página de inicio a lo largo de su historia.

http://archive.org

Observamos que los contenidos son siempre los mismos: Cómo funciona, Navegar por los títulos y Suscripción, son constantes. A veces lo vemos tras una pestaña, otras veces destacado como parte del contenido de la página de inicio. A veces es una llamada a la acción y otras veces el formulario de registro está incrustado directamente. Todo esto son decisiones de diseño, ideas, conjeturas.

Sin embargo, desde el momento en el que comienza el servicio de streaming el equipo de diseño se plantea una cuestión importante:

  1. ¿Para qué explicar ‘cómo funciona’ si podemos ofrecer la posibilidad a la gente de que experimente el servicio de forma gratuita durante un mes? Esto podríamos encontrarlo casi lógico, estamos acostumbrados a ver este modelo de venta en muchos servicios en Internet.
  2. Lo que escapa quizá más de nuestra lógica es la siguiente pregunta ¿Hasta qué punto es necesario mostrar el catálogo de títulos antes de que la gente se suscriba? Es decir, la hipótesis era que el hecho de permitir a la gente que navegara por el contenido les iba a ayudar a decidir suscribirse con más probabilidad. Des esa forma además no se retrasaría la experiencia y se atenderían a las demandas de los ‘clientes’ (mejor dicho, los ‘no miembros’). Esta idea que se había dado por hecho durante muchos años suponía un coste que Netflix quería realmente evaluar. Aunque pareciera de sentido común el equipo prefirió desafiarse, y antes que escuchar a sus usuarios, quisieron observarles.

Ésta es la imagen que presenta Netflix hoy en día en su página de inicio. No sólo no muestran un catálogo navegable sino que después de muchos otros tests demostraron que mostrar una imagen resumen de los últimos títulos más populares era mucho más efectiva que dejar a los usuarios perderse en su catálogo sin llegar a suscribirse y sin llegar a ver nada.

Netflix.com, 2019.

Netflix hoy en día ha incorporado una cultura del diseño experimental envidiable. Otro ejemplo lo vemos en sus constantes variaciones en el diseño de carteles donde han acabado descubriendo que las imágenes que contienen expresiones faciales que convinan con el tono del título tienen una mejor tasa de conversión.

Selecting the best artwork for videos through A/B testing, https://medium.com/netflix-techblog/selecting-the-best-artwork-for-videos-through-a-b-testing-f6155c4595f6


No sólo cambian las imágenes para que parezca que el contenido es más reciente sino para ponernos a prueba. Quién sabe dónde más estarán aplicando tests A/B.

No hay nada de criticable en la historia de Netflix (a simple vista) pero aquí viene algo que quizá os interese saber:

We don’t need A/B testing, we need A testing

No todo tiene ni puede ser medible mediante Tests A/B ni todos los tipos de validación tienen por objetivo probar que un diseño convierta mejor que otro. Las diseñadoras/es necesitamos los datos para aprender a hacer mejores diseños también cuando queremos mejorar soluciones existentes (a través de la monitorización de métricas) o cuando queremos descubrir, como hemos visto antes, algún patrón determinado.

Sometimes, data is not the answer but the leading question

Prototipar

Ya hemos hablado antes de la necesidad de un proceso. Las diseñadoras/es necesitamos incorporar la validación a nuestro proceso de diseño como hábito. Si no lo hacemos con suficiente tiempo nos terminaremos dando cuenta en el mejor momento, el peak of the day , el momento en el que surgen todas las dudas y necesitamos respuesta inmediata a todas nuestras preguntas: el momento de prototipar.

Most teams (88.7) conduct research during the design and prototyping phase – The State of User Research Report 2018

https://www.userinterviews.com/blog/the-state-of-user-research-report-2018

Los que lo hacen, de acuerdo con otra encuesta del Nielsen-Norman Group, sólo el 27% de los encuestados reconocían hacer sistemáticamente investigación al menos una vez por proyecto.

Y de los que lo hacen, en su mayoría usan la analítica como método preferido. Lo que nos devuelve otra vez al punto de inicio. Os pregunto de nuevo: ¿a quién le importan los datos?

En mi opinión, para diseñar hay conocer los datos detrás de la experiencia, necesitamos estar informados para decidir arquitecturas de información, para optimizar interacciones, para validar ideas… Necesitamos los datos para saber a quién dirigirnos.

Más allá de si consigue o no su objetivo ¿Cuánto tiempo necesita un usuario para conseguirlo?¿Cuánto esfuerzo? ¿cuántos errores comete? ¿es más probable que abandone si requiere de más o menos interacciones? ¿hay secuencias de interacciones que se repiten? ¿es la falta de interacción de un problema de usabilidad?

Pero no son sólo cuestiones relacionadas con lo que hacen sino con el contenido con el que interactúan ¿hay filtros o búsquedas que se hacen más que otras? ¿hay textos más o menos atractivos? ¿hay zonas de la pantalla que no alcanzan a ver? ¿qué estructura favorece encontrar información? Esto, creo, es más que un diálogo interior propio, son preguntas que surgen antes incluso de decidir ¿qué colores, tipografía, alineamiento… pueden ayudar a la comprensión de los elementos interactivos y no interactivos? Son preguntas sobre la gente y el uso que tendrá el producto, antes de enfrentarme al problema de diseñar un botón, un formulario o una pantalla.

Validar

Por esta razón, por todas estas cuestiones, en Ebury nos decidimos a establecer un framework y una metodología de validación que nos ayudara, como mínimo, a reducir la incertidumbre.

Respecto al framework, quizá habréis oído hablar de las métricas HEART propuestas por el equipo de investigación de Google. Éstas tienen como objeto medir experiencias de usuario a gran escala en base a cinco indicadores:

  • Happiness: actitud o satisfacción.
  • Engagement: cuánto interactúa una persona con un producto.
  • Adoption: número de usuarios nuevos por un período de tiempo.
  • Retention: número de usuarios que mantenemos activos por una cantidad de tiempo.
  • Task Performance: tiempo y/o esfuerzo para realizar una tarea con éxito.

Lo bueno de partir de un framework como éste es que resulta muy fácil de entender y de comunicar a través de distintos equipos. Además genera un debate interesante, cuando el equipo tiene que decidir sobre qué señales son indicativos de ‘felicidad’ – ¿hacemos encuestas? ¿recogemos feedback a través de un formulario en línea? ¿Hacemos sentimental analysis sobre los comentarios que nos dejan en un foro? – o ‘retención’ – cuando comparamos usuarios nuevos con usuarios recurrentes ¿qué características hacen que sea una persona sea considerada ‘nueva’?. En cualquier caso, lo importante en estos casos es tener un criterio común.

La parte más desafiante según qué empresa es la de establecer una cultura y unas herramientas que permitan la recolección de esos datos de una forma relativamente sencilla. Os invito a explorar tanto el blog de Research como el de Technology de Netflix para que entendáis hasta qué punto están estas ideas en su ADN.

Ebury Framework – Design with data –
https://labs.ebury.rocks/2019/01/14/visualizing-user-experience-data-part-i/

Nosotros empezamos de menos a más, partiendo de cosas muy sencillas. Primero revisamos los servicios que ya teníamos en marcha recogiendo información de usuarios: Google Analytics (servicio de analítica web), Inspectlet (servicio de grabación y reproducción de sesiones de usuario, al estilo Hotjar o Fullstory) e Intercom (servicio de chat que nos permite dar soporte a los clientes en tiempo real). Como no queríamos lidiar con tres APIs diferentes encontramos Segment (un modelo de datos que permitía conectar aplicaciones como fuentes y destinos de datos). Lo que nos abrió la posibilidad de experimentar y añadir más servicios de almacenamiento de datos (como Big Query) y de analítica, probar cuáles funcionaban mejor, cuáles no, etc. Ésta idea de interactuar con un único API (el de Segment) ya la teníamos en mente cuando nos montamos nuestra propia librería en JS (huha.js, disponible en Github) para recoger y enviar eventos de interacción y de usuario desde la aplicación web.

Respecto a los datos que identifican a los usuarios sólo los incluimos los descriptivos y relevantes (nada de sexo o edad), por ejemplo el tipo de cliente que es, qué permisos tiene activo, qué idioma tiene configurado o a qué oficina está asignado. Además añadimos datos relacionados con su contexto, para saber desde dónde se conectan, si están en un entorno de producción, de desarrollo o de demo.

Para los eventos de interacción decidimos no sólo enviar eventos sencillos disparados por una interacción (un click en un enlace, por ejemplo para saber el número de descargas de un documento determinado). Sino que queríamos crear un modelo de tarea que nos permitiera recoger información parecida a la que obtendríamos de la realización de un test de usuarios convencional. Cuando se realiza un test de usuarios, a los participantes se les da una serie de objetivos y de ellos (además de observar la experiencia) se mide el inicio y el fin de la tarea (el resultado, con o sin éxito) y cuánto tiempo, esfuerzo y errores le supone a un usuario realizarla. Esta misma información es la que recoge el Modelo de Tarea de forma automática y masiva.

Lecciones aprendidas

En la actualidad, ese framework no se limita sólo a resolver las dudas existenciales del equipo de diseño, sino que es utilizado por los equipos de producto, datos y desarrollo tanto para conocer el impacto de estos datos en el negocio, como para descubrir y resolver posibles problemas de la plataforma (que no existen, nuestra plataforma online es perfecta).

Durante todo este tiempo jugando y experimentando con datos hemos aprendido ciertas cosas que me gustaría compartir:

Más no es siempre mejor

Hay que ser honestos con lo que se quiere saber de verdad, debemos recoger los datos justos y necesarios. Más no es siempre mejor y de hecho los científicos de datos lo saben, nosotros también tenemos que hacerlo, hay que limpiar, filtrar y comprobar la integridad de los datos antes de realizar ningún análisis.

Hay que dejar margen a descubrir cosas inesperadas

Incluso aunque estemos seguros de que una solución de diseño en base a un estándar o un patrón es predecible, obtener datos y combinarlos con otros nos puede ayudar a descubrir y a aprender cosas que no esperábamos y no formaban si quiera parte de nuestras hipótesis iniciales.

No todas las métricas significan ‘conversión’

Ésto se explica muy bien en el libro ‘Designing with data’ donde se explican las diferencias entre el diseño dirigido por datos (como la ejecución sistemática de tests A/B) y el diseño informado por datos (donde el equipo utiliza los datos junto con otras fuentes de conocimiento para tomar decisiones).

No todas las métricas significan ‘conversión’, hay datos más allá del test A/B hay datos que hablan de las actitudes de las personas por ejemplo. Datos que nos hablan de cómo son y cómo se comportan las personas que de verdad utilizan el producto y que no necesariamente tienen por qué servir como KPIs del negocio.

Conocer a tus usuarios es un privilegio

Conocer a tus usuarios es un privilegio. Hay que crear oportunidades para que en tu compañía conozca más sobre la gente que usa el producto. Hay que explicar y mostrar cómo el proceso de diseño puede convertirse en algo experimental y el diseño experimental es algo esto favorece la innovación como en el caso de Netflix. Antes recomendaba el blog de Netflix, Spotify también lo hace fenomenal compartiendo sus descubrimientos a través del blog:

— Un ejemplo de la importancia del contexto cuando analizamos los datos nos viene de la mano de Spotify. Spotify sabe que la música que escuchamos no depende sólo del estado de ánimo que tenemos actualmente sino también del que queremos tener, o de la actividad que vamos a realizar, no es lo mismo la música que escuchamos cuando nos dirigimos a un sitio, que cuando hacemos ejercicio o cuando trabajamos. Pero además Spotify sabe que nuestros gustos musicales cambian según la estación del año, por lo visto en Invierno escuchamos más música ‘local’ (asociada a nuestro país) que en otras estaciones del año. Ellos suponen que es porque a la gente le gusta volver a sus raíces en esta época del año. Los mismos datos que revelan un patrón determiado, pueden servir para iniciar una investigación cualitativa.

Ningún usuario va a pedirte datos

Ningún usuario va a pedirte datos, nadie va a decirte ‘por favor observa lo que hago y analiza estadísticamente si puedo hacerlo mejor’, sin embargo, existe una obligación de contarles para qué se usan esos datos: ¿estamos mejorando el diseño, el soporte (cuando hay fallos y podemos reproducir lo que los usuarios hicieron)? ¿o forman parte del modelo de negocio?

Por otra parte la personalización es una expectativa y esto se consigue gracias a recoger información contextual e individualizada. Eso sí, una cosa es permitir a tus usuarios ajustar contenidos a sus necesidades e intereses y crear un sistema inteligente de recomendaciones, y otra es asumir intereses en base a prejuicios y limitar la visibilidad de ciertos contenidos sin que las personas sean conscientes.

Cierre

En diseño intervienen muchos factores y en las experiencias de usuario existen muchos matices. Mi objetivo no era convenceros de que todo lo medible es representativo de lo que persigue un equipo de diseño. Como podemos ver y podréis comprobar vosotros mismos, el diseño abarca muchísimas otras cosas. Sin embargo, he intentado contar lo valioso que puede ser enfrentarse a este proceso creativo con datos. Donde esos datos puedan convertirse en información y ésta, a su vez, haga que tengamos un mejor conocimiento de las personas que utilizan nuestra tecnología, su tecnología, y quizá algún día alcancemos la sabiduría que nos ayude a entender por qué la gente hace lo que hace cuando interactúa productos digitales. El único secreto cuando diseñemos con datos es que:

Depende de nuestra curiosidad el saber más y de nuestra empatía ser capaces de descubrirlo.

Carmel Hassan

Referencias

Add comment

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

Carmel Hassan UX & Product Designer

Hi there!

I'm UX/Product Designer at Ebury. I have a chaotic side project called Cinefilica and founded the most interesting tech community in Málaga: Yes We Tech. I enjoy writing random thoughts on UX, Design, Technology and Society. Something I should know? Comment on my blog, Twitter or email me to carmel.hassan@gmail.com

Categorías

¡Suscríbete!

Introduce tu correo electrónico para suscribirte a este blog y recibir notificaciones de nuevas historias.

Entradas recientes