Archivo de la etiqueta: Psicología

Investigación etnográfica

Tiempo de lectura: 4 minutos

La investigación etnográfica (del griego, “ethnos” que significa: pueblo, tribu y “grapho: escribo) es una técnica que tiene sus orígenes en la antropología y la sociología, siendo el estudio de personas y culturas, observando las prácticas culturales de los grupos sociales pudiendo participar en ellos.

Es uno de los métodos más relevantes que  se utilizan en investigación cualitativa.

Nos permite interpretar el día a día del usuario o consumidor desde lo que hace y no sólo por lo que dice que hace, dentro de su realidad social, cultural, demográfica y geográfica. En en algunas investigaciones el rol varía pudiendo el investigador ser observador y en otras participante.

La finalidad es conocer el comportamiento de las personas, mediante la observación directa de las acciones e interacciones que forman parte de esa realidad y preguntando la explicación de su por qué.

Para el sociólogo británico Anthony Giddens, la etnografía es “el estudio directo de personas y grupos durante un cierto periodo, utilizando la observación participante o las entrevistas para conocer su comportamiento social, registrando una imagen realista y fiel del grupo estudiado; el trabajo de campo resulta ser una herramienta imprescindible“.

Estas 2 técnicas, junto con los cuestionarios nos permiten obtener gran cantidad de información sobre los usuarios y la realidad que rodea al proyecto en el que estamos trabajando.

Checklist de arranque de proyecto

Muchas empresas antes de empezar el proyecto, mandan al cliente una checklist de preguntas para obtener la máxima información de contexto, y obtener así una primera impresión del proyecto, su naturaleza, su competencia, su historia, responsables, objetivos…

A continuación os dejo un ejemplo de este tipo de preguntas realizado por Olga Revilla en 2009, pero  cuyo contenido sigue siendo actual: Requerimientos iniciales de un proyecto. Son 69 preguntas repartidas en varias categorías:

  • Datos básicos
  • La empresa y su entorno
  • Los usuarios y clientes
  • Misión y objetivos del sitio
  • Tareas
  • Expectativas, requisitos y preferencias
  • Contenidos
  • Requisitos de accesibilidad
  • Recursos humanos disponibles
  • Recursos técnicos disponibles

Estas preguntas son perfectas para una primera toma de contacto. Pueden realizarse en persona, pero a veces por motivos de tiempo, o de no estar ubicados en la misma ciudad, es mejor mandarlas y que el cliente las responda cuando pueda.

Una vez recibidas, e incluso estudiando alguna un poco en profundidad, por ejemplo las relativas a la competencia (preguntas 8 y 9, Quiénes son sus competidore directos e indirectos y Cuáles son los productos y servicios de la competencia), ya se puede realizar una reunión en profundidad con el cliente (llamada kick-off en algunos entornos) hablando de las cuestiones propias del proyecto y las personas implicadas en él.

Entrevista

En relación a la experiencia de usuario, las entrevistas nos permiten intentar conocer:

  • Qué quiere el usuario
  • Qué necesita
  • Su perspectiva
  • Los matices que posee el usuario sobre la realidad que investigamos

Y digo “intentar” porque aunque realicemos las preguntas correctas no quiere decir que el usuario sepa las respuestas. A esto debemos añadirle la capa subjetiva de interpretación del investigador.

Sigue leyendo Investigación etnográfica

Resolución de problemas mediante “Framing”

Tiempo de lectura: 3 minutos

Las personas, cuando nos encontramos con un problema, tendemos a querer resolucionarlo cuanto antes con la primera solución que se nos ocurre para quitárnoslo de en medio y pasar a otro asunto, que seguramente será otro problema.

Tenemos que romper este loop infinito, parándonos a pensar ya no si esa primera solución es la más adecuada, sino si ese problema es correcto, y si es el más prioritario en resolver (De este tema habla mucho el libro “UX Lean” en su capítulo 3, lectura súper recomendada)

Es como cuando intentas ir a un lugar desconocido sin mirar primero el mapa: creemos que podemos llegar bien -y, de hecho, podríamos- pero lo más probable es que no lo hagamos.

Y eso que el coste de no hacerlo es elevadísimo. Imagínalo como construir una casa. Una vez construída, no se puede cambiar su ubicación.

Problem Framing

Y es que uno de los pasos más difíciles es definir con precisión esa oportunidad o problema, lo que se traduce como “problem framing“.

Un mejor encuadre (del problema) conduce a mejores soluciones.

Piensa en una pintura, el marco (frame) delimita lo que es la pieza de arte y lo que es parte del mundo exterior. Decidir ese límite, puede ser complicado para el artista, pero es una parte esencial de la pieza de arte.

Y plantear la pregunta adecuada, no es tan sencillo como parece.

Los problemas complejos normalmente son lo que Rittel y Webber llaman “wicked problems (problemas malvados), no se descubre cuál es realmente el problema hasta que se está a un tercio del camino a través de su resolución.

Muchas veces la definición inicial de un problema no es la correcta. Aunque al principio estamos seguros de que ese es EL PROBLEMA, basta con indagar un poco para ver que no lo es. Técnicas como “Lateral Thinking” (libro de Eduard de Bono que también recomiendo leer o “Design Thinking” ayudan a definir el problema correcto y no focalizarse antes de tiempo.

Definiendo el problema correcto

Una forma de determinar el marco adecuado es jugar con la perspectivas, observando la situación desde diferentes puntos de vista (tiempo, personas, riesgo, recursos…) hasta encontrar el enfoque correcto.

Otro enfoque consiste en seguir esta serie de pasos:

Lo primero es reunir información preliminar sobre el problema, generando varias declaraciones del tipo:

Situación – Complicación – Pregunta clave

Una vez escritas, en equipo, a ser posible integrado por gente con diferentes conocimientos, compararlas y generar una conversación observando si se ha dejado algo fuera. Lo siguiente es elegir cuál es más relevante y por qué, analizando cómo se puede mejorar y si cada palabra de esa frase es justificable.

Es importante recalcar que puede que esa declaración no sea la más correcta, pero si que se debe estar seguro de que, sobre la base de la información a mano en este momento, es lo mejor que puede hacer.

Sigue leyendo Resolución de problemas mediante “Framing”

Optimizar un test con usuarios

Tiempo de lectura: 4 minutos

Continuación del post anterior “Experiencias de realizar tests con usuarios

Hoy en día, con los recursos tecnológicos actuales, lo más caro de un test con usuario es el tiempo empleado en decidir que testear y en hacer el recruiting.

Lo primero nadie lo puede hacer por tí, ya que:

Nadie conoce mejor el negocio que tu equipo o tú.

Por lo que piensa bien que testear y haz el mínimo trabajo necesario para comprobar esas asunciones. Partiendo de que nada es válido hasta que se comprueba, gastar el menor tiempo y número de recursos en validar una idea hará que la empresa sea más proclive a seguir testeando.

Por eso como comentan también en el libro UX Lean ( y también por experiencia propia) es mejor externalizar esa parte, ya sea que una empresa busque los usuarios presenciales o en remoto (en la herramienta de testeo que busca también los usuarios u otra de BBDD).

Preparar un test con usuarios

Imagen sacada del libro Sprint, donde se ve a M. Margolis de Goggle Ventures realizar un test con usuarios.

Si hacemos el test presencial, soy de las que opinan que, para evitar que el se pierda tiempo generando documentación extra, lo ideal es que el equipo lo presencia en directo en una habitación continua. Para ello, en un mismo día se convocan a todos los candidatos (unos 5) y se reservan las 5-8 horas de todo el equipo para que vean en directo los resultados de lo que se ha trabajado previamente.

Si es una empresa del tipo “alguien llamado X” decide (que no está en el equipo), invitarlo también a que los vea en directo.

Es asombroso como alinea ideas ver a los usuarios teniendo problemas con algo que antes parecía tan claro.

O como de claro es ver que una idea sobre la que se tenía dudas, consigue sacar sonrisas y encantar a los usuarios. Ese subidón, es una recompensa al trabajo bien hecho.

Lógicamente si el test de usuario lo realiza una empresa externa, lo más normal es que se genere un informe de usabilidad donde se reporten las incidencias y su grado de gravedad. Al estar contratado externalmente estos test suelen ser mucho más costosos que los in-house y los informes muchas veces no los suele leer nadie. Aparte de que es mucho más complejo concienciar e implicar al equipo de esta forma.

Reclutar a los participantes correctos y realizar una correcta sesión de test con usuarios no es fácil. La persona encargada deba trasmitir confianza y confortar.

Es un arte guiar una buena sesión de test con usuarios.

Sonreír, trasmitir una buena postura corporal, realizar preguntas generales al inicio (la famosa “Small talk” inglesa), que generen una situación cómoda, que permitan al usuario sentirse como con un amigo, para ser honestos, abiertos y críticos.

Sigue leyendo Optimizar un test con usuarios

Experiencias de realizar tests con usuarios

Tiempo de lectura: 3 minutos

Vamos a hablar de la técnica más fiable (pero menos usada) para comprobar si algo funciona o se entiende: el famoso TEST CON USUARIOS (Síiiiiii, en algún lugar muy muy remoto de la galaxia existen!!)

Tanto en el ámbito digital para comprobar si las propuestas de navegación, contenidos o funcionalidad son adecuadas, como en el ámbito físico, para ver si un concepto se entiende, como demuestran en el libro Sprint Design, los test con USUARIOS REALES permiten averiguar si DE VERDAD funciona lo que hemos creado.

Te voy a decir una gran verdad, raro es encontrar una empresa que los haga de manera regular

Tristemente, debo decir que a día de hoy la mayor parte de las empresas (me atrevería  decir el 90-95%, por lo menos digitales) no los realiza. Y ya no digo de hacerlos de manera regular como comentan (y apoyo) en en libro UX Lean.

Y no porque sean caros, que no tienen porque serlo ( y más con la tecnología actual)

O yo creo que no lo son dado todo lo que se pueden ahorrar. Sino los hacen es porque nunca los han hecho y los ven como algo imposible, y no tienen a nadie que tire del carro y les convenza y les impulse a hacerlo.

Test con usuarios

Ejemplo de test con usuarios (Imagen extraída del libro de Steve Krug “Don´t make me think”)

También cuando se trabaja en empresas de tipo consultoría o agencias, los timing no están pensados para realizar test con usuarios, y de hecho, es de las primeras cosas que se quitan de los presupuestos UX (o no se llegan a incluir).

Psst… Sin usuarios no hay UX

Tristemente, debo decir que a veces los que “venden” esos proyectos, tienen cero o ninguna formación o experiencia en UX para poder hacerle entender al cliente lo que de verdad puede necesitar, que a lo mejor es probar la idea con un prototipo y no vender 400 horas de desarrollo en algo que no funciona. Pero si, dile eso a un comercial (luego se quejará de que el cliente se va a otro lado).

Por experiencias vividas, es más fácil conseguir hacerlos si están dentro de la empresa y convences de su valor al CEO, que estar en una empresa externa y tener que pasar por 20 capas de directivos que los vendan por ti.

Un consejo: gánate primero la confianza con tu trabajo previo. Así es más fácil convencer que lo que vas a hacer (el test con usuarios) vale la pena (la inversión de tiempo y recursos).

Si estás dentro de una empresa pequeña (y normalmente menos dinero) es más fácil convencer al CEO que es un grave error gastar muchísimo dinero en desarrollar aplicaciones y servicios web en base a la experiencia previa de un grupo de diseñadores, pudiendo haberlo probado con un prototipo, que cuesta bastante menos dinero con usuarios reales.

Pero si formas parte de una gran empresa es mucho más complicado convencer a toda la cadena jerárquica de los beneficios de los test con usuarios.

Debes estar en una posición que permita “mover los hilos” para ser escuchado.

De hecho a veces, parece que se tiene un pavor a hablar con las personas que van a usar la aplicación. A mi me ha pasado incluso que NO me dejaban hablar con los usuarios al inicio del proyecto, y eso que eran usuarios propios de la empresa al ser una aplicación interna.

Podemos saber mucho de un negocio, y tener muy claras ciertas cosas, pero no es hasta que se prueba con usuarios reales, que de verdad podamos ver si está funcionando o no.

Si te gusta el tema, sigue leyendo mi siguiente post de consejos para optimizar un test con usuarios.

Poka-Yokes, heurísticos de usabilidad y affordances

Tiempo de lectura: 2 minutos

Un poka-yoke (en japonés, ポカヨケ), es un término japonés que significa: Poka: “error no intencionado, equivocación…” y Yoke: “evitar”, es decir, “evitar equivocaciones”.

Es una técnica de calidad que se aplica con el fin de evitar errores en la operación de un sistema, introducida por el ingeniero japonés Shigeo Shingo en Toyota (1960), basada en que la causa de los errores estaba en los trabajadores, y que los defectos en las piezas fabricadas se producían porque no se corregían.

Anteriormente ya existían precedentes de poka-yokes, pero fue en ese momento cuando se consolidó este método como una técnica preventiva de control de calidad.

Para Shingo, los defectos de producción son la consecuencia de la cadena de errores generados por los trabajadores, por lo que no tenía sentido analizar el producto final cuando el defecto se producía durante el proceso de trabajo.

Es decir, el buscaba mejorar la calidad en su origen, actuando sobre la fuente del defecto, en lugar de tener que realizar correcciones, reparaciones y controles de calidad posteriores.

Para ello ideo 2 métodos sobre los que basarse para mejorar el proceso de trabajo y evitar errores.

  1. Control: Conseguir la imposibilidad o la dificultad de que el operario pueda equivocarse en proceso diseñando un sistema que lo impida (¿Te suena el término “affordance” introducido en el campo de HCI por Donald Norman en 1998 (propiedad en la cual las características físicas de un objeto o entorno, influencian en su función y uso)?).
  2. Advertencia: asumiendo que el error puede suceder, se diseña in dispositivo que dirija la atención hacia él para reaccionar y poder corregirlo.

¿No os suena esto a los principios heurísticos de usabilidad?

  • Conocimiento del estatus del sistema: el sistema debería siempre mantener a los usuarios informados de lo que está pasando, ofreciendo feedback en un tiempo razonable.
  • Control y libertad del usuario: cuando elegimos funciones del sistema por error necesitamos una “salida de emergencia” sin tener que ir a través de una serie de pasos complicados.
  • Prevenciones de errores: mejor que buenos mensajes de error, lo ideal sería un diseño que previniera que ocurrieran los problemas.

Hoy en día, es muy común ver dispositivos diseñados a prueba de error, no solo dentro de una empresa de producción o de servicio, sino en nuestro día a día, siendo una ventaja para todos los usuarios, ya que además de evitarse errores, pueden salvar vidas.

affordance

Imagen extraída de http://www.pdcahome.com/poka-yoke/

¿Algunos ejemplos?

Sigue leyendo Poka-Yokes, heurísticos de usabilidad y affordances

Cambiando la metodología de trabajo (o al menos intentarlo)

Tiempo de lectura: 4 minutos

He trabajado en varias empresas que querían modificar su proceso de desarrollo de producto. Algunas (2013) querían implantar una nueva metodología (Agile en este caso) y otras ya la tenían, pero necesitaban un pequeño reajuste para adecuarla a su cultura de empresa.

Y es que desde mi punto de vista, cualquier metodología o proceso de trabajo tiene sus herramientas e indicaciones, pero no siempre sirven al 100%, sino que debe adaptarse a lo que la empresa necesita en ese momento.

Son una base sobre la que trabajar para encontrar el proceso que realmente funcione para cada grupo de trabajo.

En ambos casos las empresas contrataron los servicios de una persona que facilitase y guiase el cambio. En una el proceso duraba X meses, para luego la empresa continuar por su cuenta con lo aprendido, mientras que en la otra la fase de implantación duraba X meses, pero prosiguiendo después el trabajo con el facilitador.

Es decir, (o por lo menos lo que yo creo que es lo ideal) esa metodología por la que se estaba apostando no era algo cerrado, inmutable para siempre, sino que seguiría evolucionado en el tiempo.

En ambas empresas, como muchos imaginaréis, el proceso no fue sencillo.

Para mi existen 2 puntos claves en el proceso:

  1. ¿El cambio viene impuesto desde arriba o es algo en lo que todo el equipo cree y apuesta?
  2. Como en cualquier materia, la constancia y repetición son claves para hacer algo bien.

Si el cambio viene impuesto desde la dirección, va a ser muy difícil que suceda si los principales implicados no lo aprueban. El facilitador se va a encontrar con un muro muy difícil de romper, no digo que imposible, pero muy complicado.

Lo ideal es partir de una base en la que la mayor parte cree que es necesario el cambio porque lo existente no funciona. O funciona pero podría ir mejor.  Pero aun siendo algo querido por todos, cambiar unas costumbres suele ser muy complicado.

No olvidemos que estamos trabajando con personas.

Personas que pueden llevar 5, 10, 15, 20 años trabajando de una misma forma. Personas que han luchado por sacar adelante un proyecto. Personas que no se han sentido escuchadas. Personas que van agobiadas porque tienen unos plazos de entrega. Personas con un baggage emocional hacia la empresa y otros compañeros.

Sigue leyendo Cambiando la metodología de trabajo (o al menos intentarlo)

Trabajo en remoto o presencial

Tiempo de lectura: 4 minutos

LLevo unos 10 años trabajando en empresas de todo tipo, grandes y pequeñas, y hablando con mucha gente sobre el tema, tanto dentro como fuera de España.

Como ya he comentado en anteriores artículos creo que una buena relación entre trabajador y empresa se basa en una confianza plena. En dar ambos lo mejor de si mismos para cuidar esa relación en beneficio de ambos.

Trabajo en remotoEscritorio de bambú LILLÅSEN (IKEA)

Si no se confía en la responsabilidad del trabajador, el jefe debe estar constantemente encima, controlándolo. Qué hace, qué horario lleva… Eso a mi modo de ver, impide que la organización crezca de una forma sana, aparte de un desperdicio de recursos al tener a los managers haciendo de “padres”.

Puede que en determinados puestos de trabajo con una alta rotación tenga que ser así, pero en el sector que me encuentro quiero pensar que no.

Trabajo presencial

Para mi la mayor ventaja que tiene el trabajo presencial es la posibilidad de interactuar con las personas directamente, y la creación de equipo. No digo que no se pueda crear equipo en remoto, pero creo que cuesta más.

Y es que pese a que hoy en día la comunicación es más directa y efectiva que nunca, se pierden matices, como los correspondientes a la comunicación no verbal, que son los que transmiten mayor confianza.

El roce hace el cariño, ya lo dice el refrán

He estado en varias empresas que por tener separados a 2 departamentos en distintas planta del edificio ya no existía ese sentimiento de grupo e implicación. Y eso que eran ambos desarrolladores! Que cuando son dos departamentos diferentes, Call Center y Devs, por ejemplo, la cosa empeora (menos mal que está UX por en medio intentando que se comuniquen je je!)

Creo que se podrían haber hecho muchas cosas por intentar evitar eso, pero volviendo al tema, el estar trabajando en remoto, obliga a realizar un mayor esfuerzo de empatía por esas personas que no conoces físicamente.

Trabajo en remoto

El trabajo en remoto tiene para mi varias ventajas:

  • Acceso a los mejores profesionales allá donde estén, ya no tienes que preocuparte de buscar gente que viva en tu ciudad sino que tienes el mundo entero para buscar.
  • Evitar perder tiempo y dinero en transporte (y menos contaminación en muchos casos). Ese ahorro de tiempo repercute en una mayor calidad de vida.
  • Flexibilidad laboral. Normalmente las empresas que realizan este tipo de trabajo, al confiar en las personas, no les obligan a estar de 9:00 a 18:00 en su sitio, permitiendo que se organicen como quieran. Lo importante es que el trabajo salga.
  • Muchas veces, el estar rodeado de personas, hace que haya estímulos que interrumpen el estado de “flow” propuesto por el psicólogo Mihály Csíkszentmihályi en 1975. El estar en remoto mucha veces hace que cunda más el tiempo de trabajo al no gastarlo en distracciones no productivas.
  • Se evita que todos los trabajos se concentre en las ciudades más grandes, pudiendo vivir el trabajador donde desee. En España, hay muchas más oportunidades laborales en Madrid y Barcelona, y mucha gente se ve obligada a vivir allí si quiere prosperar profesionalmente. Esto es una serpiente que se muerde la cola, al masificarse y encarecerse estas ciudades, bajando su calidad de vida, y dejando otros núcleos vacíos.
  • Ahorro de costes para la empresa al no necesitar pagar el alquiler de un local.

Esa mayor calidad de vida y confianza, genera en los empleados una sensación de gratitud y estima hacia la empresa. Los trabajadores se vuelven leales.

Creo que funciona mucho mejor cuando todos los miembros están en remoto, pero aun así con sólo una parte también funciona, siempre que exista la cultura y las herramientas adecuadas.

¿Algunos ejemplos? Ahí van…
Sigue leyendo Trabajo en remoto o presencial

¿Qué busca el usuario en una web?

Tiempo de lectura: 3 minutos

Las personas accedemos a internet buscando satisfacer una necesidad de información y/o realizar una transacción.

Este artículo vamos a hablar sobre el primer caso: la satisfacción de una necesidad de información, basándonos en el libro de Mario Pérez-Montoro Gutiérrez, “Arquitectura de la información en entornos web“. Te recomiendo su lectura si te gusta el tema.

Tipos de necesidad de información

Existen 4 tipos de necesidades informativas:

  1. Necesidad de información concreta (NIC) o búsqueda de un item conocido. Esta necesidad responde al momento en que el usuario busca cuánto vale un vuelo de Barcelona a Nueva York o quién ganó la copa de futbol en 1982. Es una necesidad que se puede formular de forma exacta y que se resuelve a partir de una única respuesta.
  2. Necesidad de información orientada a problemas (NIOP). En este caso, no acostumbra a presentar unos límites bien definidos o no se puede establecer si se necesita más información para resolverla. Para ello, el usuario navegará a través de diferentes items de información hasta que crea que ha resuelto su necesidad. El ejemplo que nos presenta Mario Pérez-Montoro en su libro sería conocer la relación entre la educación de un país y su economía.
  3. Necesidad de información exploratoria (NIE) o búsqueda exploratoria. En este caso se busca una respuesta útil dentro de un conjunto de respuestas localizadas previamente. Lo que ocurre es que no estamos seguros de que la respuesta elegida sea la más adecuada. Por ejemplo ocurre, cuando después de haber investigado varios hoteles para las vacaciones que se ajustan a nuestro presupuesto, buscamos opiniones de otros usuarios que nos ayuden a decidirnos sobre el tema.
  4. Necesidad de información sobre búsquedas previas (NIBP) o recuperación de una búsqueda. En este caso el problema de necesidad de información se resuelve volviendo a localizar una información que ya habíamos encontrado previamente, como cuando abrimos una página web que tenemos guardada en favoritos.

¿Cómo resuelvo mi necesidad de información?

Dependiendo del contexto, la forma de satisfacer esa necesidad cambia. Un niño pequeño, le pregunta a su madre, en el instituto le preguntamos al profesor, en un aeropuerto a la persona del mostrador de información, antiguamente si estábamos perdidos con el coche por una ciudad, al primer peatón que pase.

Sigue leyendo ¿Qué busca el usuario en una web?

Investigación de usuarios en la BBC, un caso práctico con impacto

Tiempo de lectura: 4 minutos

Júlia Ivorra da una de las charlas que más me ha gustado este año: Investigación de usuarios en la BBC, un caso práctico con impacto.

Nos cuenta como en la BBC Sport habían desarrollado un ecosistema de productos y servicios (online y offline) para su audiencia y querían, aprovechando un verano lleno de deporte, mejorar los servicios de la BBC online y preparar la cobertura de las Olimpiadas de Tokyo 2020.

El objetivo era averiguar cuáles eran las motivaciones de nuestros usuarios para conocer porque usaban unos productos u otros. Es decir, averiguar como estaba la BBC integrada en la vida de las personas.

Pero no querían hacer una investigación que sólo generase un informe tocho de entrega al final del verano que solo vieran (en el caso de que lo lean) los jefes, en vez de todo el equipo, por lo que definieron como querían que fuera su proyecto de investigación:

  • Tenía que ser agile
  • Tenía que ser reportada diariamente. Integrada con el trabajo. No sólo un informe al final del proceso
  • Involucrando a todo el mundo

Tenían unos 30 eventos para analizar en 3 meses y medio. Y pensarás, ¿por qué tantos?
Pues porque cada evento es único, y la gente que los sigue es diferente, no es la misma persona la que sigue el golf que la que ve el futbol.

Dividieron la investigación en 4 rondas con 4 participantes cada uno, realizando un análisis de resultados en cada ronda y difundiendo al equipo lo que estaban descubriendo.

Informaban al resto del equipo en vivo, mientras estaban pasando los eventos.

Iban publicando todo lo que iban averiguando en un canal de Slack consiguiendo que la gente les hiciera preguntas para que el equipo de investigación se las preguntase a los usuarios. O si veían algo raro en las analíticas, lo comentaban para que intentaran averiguar porque sucedía.

Como todo el mundo seguía el canal, muchos incluso se acercaban a las entrevistas que les interesaban.

Todo el equipo estaba hablando de usuarios, de cómo usaban sus productos.

Consiguieron erradicar, el típico “yo creo”, “a mi me gusta” o “he leído un post que dice esto”.

A nivel formal después de cada ronda iban difundiendo lo que aprendían colgando en una pared de la oficina las cosas para que todo el mundo las tuviera presente.

Caso de research en la BBC

También crearon artefactos UX: un journey map de toda la información que les estaba llegando. 
Y lo mejor, es que estos artefactos se siguen usando a día de hoy, no son algo puntual.

Están basados en algo real. En casos de usuarios reales.

Y a un nivel superior, pasó algo muy bonito. Los jefes ya no estaban encerrados en reuniones decidiendo que iban a hacer, sino que iban leyendo el mismo canal y haciendo preguntas cuando creían conveniente.

Y es que como comenta Julia, si sólo involucras a los jefes mandándole sólo a ellos el informe, en vez de a todo el equipo, acaba pasando que parece que están en una bola de cristal, aislados, con conocimientos únicos que solo poseen ellos.

Habían conseguido q los stakeholders hicieran User Centre Design.

Así cuando los jefes tuvieron que tomar decisiones estratégicas, las tomaban en base a casos reales.

Y cuando compartían los nuevos objetivos estratégicos a seguir todo el mundo los entendía y supo porque se habían tomado esas decisiones.

A mi modo de ver, una de las cosas que más fallan las empresas es en conseguir que todo el mundo comparta la misma visión del negocio. Qué los de arriba tengan información del día a día para tomar decisiones y encaminar el futuro de la empresa y qué las elegidas sean entendidas por toda la compañía.

Porque se puede IMPONER remar en una dirección, pero se avanza mucho más rápido cuando todo el equipo CREE que es la correcta.

En resumen, Ivorra finaliza compartiendo lo que ha aprendido en base a este proceso y que aplica en su día a día:

  • Ser agile: dividirlo todo y realizarlo a menudo
  • Ser transparente: todo el mundo tiene acceso a leer los proyectos e involucrarse en la investigación
  • La investigación tiene que tener un propósito, se hace para ayudar a otros a hacer mejor su trabajo.

Muchas gracias Julia por compartir un caso real de trabajo. Me ha encantado!