UX Manager
Desde el pasado 11 de diciembre formo parte como UX Manager de Torresburriel Estudio, una empresa de Diseño centrado en el usuario creada por Daniel Torres Burriel en Zaragoza.
Imagen del Estudio
Principalmente mi trabajo se centra en la gestión del equipo de UX, 6 personas que trabajamos diseñando productos digitales centrados en el usuario y las necesidades de negocio, desde conceptualización hasta entrega de mockups de alta fidelidad para clientes nacionales e internacionales.
Sesión de test con usuarios en el Estudio
Con laboratorio de usabilidad propio, somos expertos en realizar research con todo tipo de test con usuarios: Think aloud, card sorting, tree test, user journeys… , benchmark, análisis heurísticos…
Design Thinking
Soy muy partidaria de que cuando diferentes personas participan en la creación de un producto o se centran en la solución de un problema es cuando aparecen las mejores ideas. Ya que es imposible que una sóla persona sepa toda la información hay que aprovechar el conocimiento de todos para crear algo diferente.
Para obtener un resultado creativo y novedoso, tiene que existir cierta cantidad de caos, pero es necesario empezar por un orden.
Pero en el día a día nos olvidamos de esto, y en vez de juntar los cerebros trabajamos de forma individual, desaprovechando esos increibles recursos que son las personas que tenemos a nuestro alrededor.
Design Thinking es un método para la resolución práctica y creativa de problemas.
Ayuda a facilitar el proceso de innovación permitiendo trabajar en grupo de forma dinámica, comunicativa y eficiente hablando el mismo idioma y sin tener en cuenta egos, ni posiciones jerárquicas e involucrando a todo el mundo de la misma forma.
Trabajando de forma dinámica y positiva
Gracias al poder de la escritura y el dibujo todo el mundo tiene oportunidad de aportar sus conocimientos de la misma forma. Logra evitar que siempre hablen los mismos, poniendo al mismo nivel todas las ideas e integrando el conocimiento de todos en el trabajo común.
Cuando alguien habla, solo esa persona tiene el poder en ese momento.
Si en vez de hablar, se escriben las ideas en dibujos o etiquetas, todo el mundo trabaja a la vez, construyendo algo de forma conjunta. Además se evita el bias del poder de la oratoria e influenciar en otras personas aunque sea una mala idea.
Al escribir la idea deja de ser de la persona pasando al grupo.
El hecho de dibujar o escribir dinamiza la actividad, ya que es más entretenido que estar escuchando a una persona. Y es que la capacidad de atención del ser humano es limitada, siendo cada vez menor.
Workshop de Design Thinking usando Manual Thinking
Además al ordenar las etiquetas o post-its nos movemos, cambiando el equipo de forma constante de posición y postura, tanto de forma mental como física.
Checklist de arranque de proyecto UX
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…
Imagen extraída del checklist de Olga Revilla
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 y más importante, alinear expectativas con el cliente de lo que espera del proyecto.
Cómo debe ser una buena arquitectura de la información
La Arquitectura de Información (en inglés Information Architecture, también llamada por el acrónimo IA) tiene por objetivo clasificar y etiquetar información para facilitar su asimilación, el acceso a los distintos bloques de contenido y asegurar la consistencia y escalabilidad futura de la estructura de contenidos.
Buscando un símil, es como el plano de un edificio sobre la que se construyen y organizan las puertas de acceso, los pasillos para ir entre salas, las habitaciones… Traducido a nuestro elemento se refiere a los menús de navegación de las aplicaciones, los bloques de contenidos…
Morville y Rosenfeld, definen en 2006 que una buena arquitectura de información se sustenta en tres pilares: el contexto organizacional en el que se desarrolla, el contenido que alberga y los usuarios que la visitan y consultan.
No es lo mismo definir un etiquetado para usuarios con conocimientos técnicos avanzados sobre un tema, que para personas que no los posean.
Por eso es muy importante saber a que tipo de usuarios nos dirigimos cuando debemos organizar la información de un sistema.
Características de la arquitectura de la información
Una buena arquitectura de información es:
- Intuitiva, aprendida a manejar en un corto periodo de tiempo.
- Flexible apoyando la realización de tareas para los diferentes perfiles de usuario y diversas variables en el contexto de uso actual.
- Consistente, permitiendo predecir el comportamiento del sistema durante la interacción.
- Escalable, orientando el crecimiento de los contenidos según un modelo establecido, en lugar de hacerlo por “apilamiento” de ítems en los menús.
Estructura de información
La estructura de la información se basa en el análisis de las necesidades funcionales que dan como resultado los diferentes bloques de contenidos. La estructura de la información se encarga por tanto de analizar, clasificar y etiquetar la información.
La estructura de la información está íntimamente relacionada con el modelo de acceso que contempla la navegación, la orientación y las herramientas de búsqueda. Por ello tiene que ver con la clasificación y tipos de contenidos, la agrupación de los mismos en extensión y profundidad y su etiquetado.
Seguir leyendo «Cómo debe ser una buena arquitectura de la información»
Consultoría UX para simplificar un proceso complejo para el usuario
Seguimos con las consultorías a startup, en este caso el modelo de negocio se basa en un market place de venta de un producto técnico de segunda mano.
El proceso de venta es así:
- El vendedor sube el producto indicando sus características, fotos y estado técnico de cada pieza, definiendo el precio que cree que es adecuado para su producto.
- Una vez que un comprador decide que quiere un producto, la empresa se encarga de ir a buscarlo gratuitamente a donde lo tienen el vendedor y llevarselo a un técnico de confianza para que lo revise. Aquí pueden darse 2 casos:
- Si el estado del produto es correcto, se le manda al comprador, que ingresa el dinero y el vendedor recibe su parte.
- Si el técnico ve fallos no descritos o más graves de los comentados por el vendedor, se cambia la pieza, bajando el precio definido por el vendedor para pagar ese gasto. En el caso de que el vendedor no lo acepte debe pagar para que le devuelvan el producto.
El punto crítico era el formulario de subida de un producto a la venta.
Es un proceso complejo, ya que hay que subir fotos, conocer cierta información técnica y definir muy claramente el estado técnico de ciertas piezas, siendo muy importante que el vendedor sea sincero en este punto, ya que un técnico va a evaluar después si es verdad esa información.
Además aunque la persona quiera ser sincera, es complejo determinar a veces el estado de una pieza, ya que lo que para una persona es aceptable para otra no lo es.
Además hay que informar al usuario claramente en el proceso de lo que puede ocurrir si el técnico decide que hay que cambiar alguna pieza:
- que el precio definido por el vendedor se va a ver reducido por ese gasto o,
- que sino acepta el cambio o el producto no tiene arreglo debe pagar para que le devuelvan su producto (ya que el coste de transporte de la devolución no está incluído).
El miedo que tenían era si el usuario leía esto antes de iniciar el proceso, a lo mejor ya no subía el producto. Pero después de comprobar con varios casos reales, que la experiencia que generaba al vendedor ese desconocimiento era mucho peor, querían probar a comunicarlo de forma más directa.
Después de escuchar y comentar varios puntos del problema con ellos en una sesión de unos 45 minutos, pasé a proponerles varias cosas.
La solución que se propuso iba por dos caminos:
- Informar que existía una revisión del producto (en la landing y en el proceso).
- Informar de las posibilidades que existen en el caso de que las características del producto no cumpliera con lo afirmado por el vendedor.
Revisión del producto como estándar de calidad
En el diseño actual en la landing dirigida al vendedor ya se comentaba que en un momento dado un técnico iba a revisar el producto, pero estaba en la parte inferior de la página (haciendo bastate scroll) y entre otra información que reducía la importancia visual de esa información.
Por ello se recomendó que en el nuevo diseño estuviera resaltada en la parte superior, junto con las otras ventajas que existen de usar este marketplace.
Esta revisión por parte de una persona imparcial permite asegurar un producto de calidad, y debe ser entendida y trasmitida bajo ese concepto.
Es asi mismo muy importante trasmitir el concepto de que la revisión va a ser justa para ambas partes, y no es una manera de sacar más beneficio por parte de la empresa.
Tambien a lo largo del nuevo proceso de subida (que estaba mejorado para que la definición del estado de las piezas fuera más sencilla y acertada) se aconsejaron una serie de cambios para que el mensaje apareciera de forma amigable y no amenazante (otro de los miedos que tenía la empresa).
Psicológicamente está comprobado que tenemos más tendencia a comportarnos de forma correcta si nos sentimos observados.
El conocimiento a lo largo de diferentes puntos de que un técnico va a revisar el producto para asegurar la calidad, implicará que el vendedor sea más consciente de la información que sube e intente que sea lo más verídica posible.
Seguir leyendo «Consultoría UX para simplificar un proceso complejo para el usuario»
Realización de una prueba de usabilidad con test de usuarios
Esta semana he estado colaborando con una empesa realizando un análisis heurístico y varios test de usuarios para evaluar la usabilidad de 2 webs que querían analizar.
Momento del montaje de la sala para la realización del test
El propósito de las pruebas de usabilidad realizadas era recopilar información sobre cómo los usuarios usan el sitio, ver si existen problemas al navegar, al interactuar con los elementos y al leer la información, y comprobar si existen mejoras que permitan aumentar la conversión del objetivo principal de la web: la reserva una habitación.
Para ello se han definido varios elementos que eran necesarios:
- La metodología de prueba
- Los tipos de usuarios para la prueba
- La declaración del problema y las tareas/escenarios propuestos
- Entregables con las conclusiones obtenidas
Durante la prueba se han realizado 3 test:
- Test para recolectar los participantes: test de filtrado mandado a los partipantes interesados via formulario online para que lo rellenasen y detectar en base a sus respuestas cuales entraban dentro de la tipología definida.
- Test con las tareas a realizar en la prueba: Definición de las tareas a realizar en la prueba (4 en este caso)
- Test realizado después de cada prueba para su evaluación: Después de cada tarea y al finalizar la prueba mediante un ipad que disponíamos al lado del ordenador, el usuario debía valorár del 1 al 10, 3 preguntas por tarea para analizar su satisfacción de lo realizado y el sentimiento generado.
Tipología de usuario para la prueba
Después de analizar el perfil del usuario en base a entrevistas con el cliente, al producto ofrecido, y la posible competencia, se definió un usuario tipo a buscar para la prueba con varias preguntas de control.
El participante debía cumplir los siguientes requisitos:
- Que viajasen mínimo 1-3 veces al año a hoteles (se les preguntaba además número de noches dormidas en hotel el pasado año).
- Que viajasen por placer y acompañados de la familia o pareja (se les preguntaba además año de nacimiento).
- Que utilizasen internet más de 2 horas al día (se les preguntaba para que lo usaban).
- Que fueran ellos los que realicen las reservas (se les preguntaba donde reservaban habitualmente).
Además, lógicamente se agradecía su tiempo con un cheque regalo de 30€.
Escenarios propuestos para el test de usabilidad
EL objetivo de la prueba es proporcionar datos cualitativos sobre la experiencia del usuario en la web.
Seguir leyendo «Realización de una prueba de usabilidad con test de usuarios»
Consultoría UX para empresas
Hoy os quiero contar la sesión de consultoría de Experiencia de Usuario que estuve realizando con el equipo de Waidis, una startup de Demium, cuyo modelo de negocio se basa en proporcionar ayuda a grandes empresas que requieren un volumen extra de trabajadores en determinados momentos puntuales agilizando el proceso y mejorando la calidad de sus contrataciones.
Fue una reunión de 2 horas muy productiva donde trabajamos en varias líneas.
Por un lado yo había previamente realizado un análisis heurístico de la web y les pase ciertas cosas mejoras e ideas que había visto (hay que decir que la web la crearon hace meses y ellos mismo la tenían pendiente de cambio).
Por otro lado, realizamos varios story mapping desde el punto de vista de los 2 principales grupos de usuarios para identificar posibles problemas, y contemplando de forma rápida mediante bocetos cuales podrían ser las mejores soluciones.
Charla UX en Demium
El pasado martes di una formación en Demium sobre Experiencia de usuario a los integrantes del último AllStartup.
180 diapositivas y dos horas de duración para explicar por qué es importante trabajar con metodologías centradas en el usuario, como nació la Experiencia de usuario, ejemplos divertidos de qué es y qué no es UX, técnicas para encuentrar el problema y conocer a los usuarios y sus necesidades, consejos sobre hasta qué nivel de detalle necesitas llegar al realizar un diseño, ejemplos de diferentes tipos de test con usuarios, y como medir en base a lo que queremos analizar.
Además remarqué especial importancia sobre como trabajar el proceso de discovery de producto y la experiencia de usuario en un equipo, siguiendo la técnica Lean UX, que muestra como colaborar con otros miembros del equipo obteniendo feedback cuanto antes y de forma continuada.
Y es que ya que la charla iba dirigida a empresas que están comenzando nada mejor que remarcar la importancia que tiene la cultura de empresa y la forma de desarrollar un producto y trabajar en equipo.
Y es que la suma de las partes supera al todo.
Lean UX es un conjunto de principios que adaptados a cada empresa y equipo, sirven de guía para encontrar mejores y más deseables soluciones para los usuarios. Explica una serie de técnicas y una forma de aplicarlas haciendo diseño y descubrimiento participativo entre los diferentes pefiles implicados en el proyecto en un entorno siempre cambiante e impredecible.
Y es que para diseñar un gran producto o servicio no se debe confiar en la figura de una única persona, ya que no exiten los Gurús o Ninjas que lo sepan todo. Es sumando el conocimiento de los diferentes perfiles del equipo, lo que permite obtener un MVP (Minimum Viable Product) con el menor coste de recursos posibles que permita probar cuanto antes las suposiciones ideadas entre todos.
Y es que todo son suposiciones hasta que no se testea.
Ejemplo real de observación participante
La observacion participante es una de las técnicas utilizadas en la etnografía para recoger información de las personas a través de la observación para obtener conocimiento acerca de lo que quieren los usuarios, cómo lo necesitan, como lo solicitan, que quejas o demandas tienen…
El rol del investigador puede variar dependiendo de las necesidades del proyecto. Algunas veces es observador y en otras participante. En este caso, en un trabajo realizado hace unos años, iba a ser participante ya que quería observar cómo podía mejorar el día a día de las personas que trabajaban en Call Center.
Imagen de Call Center en Centraldereservas.com
Sus principales tareas eran:
- atender por teléfono a los clientes que querían reservar un hotel,
- cancelar uno ya reservado y,
- dar soporte de emergencia cuando llamaban con algún problema una vez iniciado ya el viaje (siiii, llamadas súper alegres como podéis imaginar).
Su interacción con el cliente era hablada por teléfono, mientras a la vez delante de un ordenador usaban la web de la empresa u otros programas internos para realizar las tareas necesarias.
Quería observar como realizaban este trabajo por dos motivos:
- Ver si podía mejorar su experiencia diaria y aumentar su satisfacción laboral, mejorando si era posible la página web o el software desarrollado internamente.
- Observar como interactuaban con las personas que llamaban, es decir, qué necesidades tenían los clientes, para ver si podía obtener alguna idea para introducir mejoras en la web cuando el cliente la usaba por si mismo.
Call Center es uno de los departamentos que más importancia deberían tener en las empresas
Para mi, desde siempre, como especialista en experiencia de usuario, las personas que forman Call Center son de vital importancia en las empresas, ya que:
- Están en contacto directo y diario con los clientes por lo que son los que más oyen y conocen sobre lo que necesitan
- Son la voz de la empresa hacia el mundo exterior
- Muchas veces soportan las peores situaciones, es decir, los clientes suelen llamar cuando hay un problema y está enfadados (si, que sea nochevieja y que tu hotel haya pedido la reserva porque la mayorista no la ha procesado bien no es de buen gusto…)
Lo peor, es que muchas empresas suelen externalizar este servicio alejando esta impresionante fuente de información y encima no reconociendo el mérito que su trabajo merece, ya que suele estar bastante mal pagado y realizarse 24 horas al día.
Volviendo al tema que nos ocupa, aunque la empresa ya tenía un canal de sugerencias y mejoras para que los trabajadores expusieran su opinión (e incluso otorgando premios a las mejores) las personas de Call Center (y en general en toda la empresa) no lo empleaban.
Ya existía una canal de sugerencias, pero dado que parecía que no era escuchado se había dejado de usar.
Y es que muchas de estás ideas y mejoras acababan siendo ignoradas, ya fuera porque había otras tareas prioritarias o por no recaer en la persona correcta.
Experiencias de realizar tests con usuarios
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.
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.