My work

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.

UX: Observacion participante

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:

  1. 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.
  2. 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.

Seguir leyendo «Ejemplo real de observación participante»

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.

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.

Requerimientos de un proyecto

Ya sea cuando estaba trabajando para clientes pequeños, a nivel interno de una empresa, o para grandes clientes externos dentro de una consultora, me ha tocado en muchas ocasiones estar con los stakeholders (interesados)de un proyecto, definiendo sus requerimientos. Es decir, la lista de funciones, capacidades o características necesarias que debe tener y los planes para crearlos.

Stakeholders en un proyecto

Según la definición del PMBOK® (Project Management Body of Knoledgement), un requerimiento es la condición o capacidad que debe tener un sistema, producto, servicio o componente para satisfacer un contrato, estándar, especificación, u otros documentos formalmente establecido.

Se deben definir en la fase inicial junto con los stakeholders  implicados para obtener una visión completa y compartida de todas las piezas y poder priorizar en base a los objetivos del proyecto.

Los requerimientos no te indican que diseño debe tener tu producto o como desarrollarlo. Te indican que features, funciones y contenidos se espera que tenga, y como deben los usuarios interactuar con él.

Los requerimientos pueden incluso variar con el tiempo, ya que si el proyecto se desarrolla correctamente, en cuanto el MVP se haya desarrollado y se realicen pruebas con usuarios, los resultados pueden cambiar los requisito iniciales.

Tipos de requerimientos

Existen diferentes tipos de requisitos, casi tantos como implicados haya en un proyecto 😉 En un macronivel obtenemos los siguientes:

Requerimientos de negocio

Definen los objetivos y problemas que la empresa quiere resolver con el producto. Deben estar basados en una necesidad real del usuario, sea esta conocida o no por él.

Requerimientos de los usuarios

Describen las expectaciones de los usuarios y como éste interactuará con el producto. Sino son similares a los requerimientos de negocio, el proyecto irá mal encaminado.

Las técnicas de personas, escenarios y customer journeys sirven de ayuda para definir las funciones, tareas y características que definen los requisitos de usuario.

Requerimientos funcionales

Proporcionan detalle de como debe comportarse un producto y especifican lo que se necesita para su desarrollo.

Requerimientos de calidad

Detallan las características que un producto debe poseer para mantener su efectividad y prever posibles problemas y limitaciones.

En términos de experiencia de usuario, si la calidad del producto no concuerda con las expectativas que el usuario posee sobre él, no funcionará.

Requerimientos de implementación

Se usan para detallar cambios en los procesos, roles en el equipo, migraciones de un sistema a otro…

Escribiendo requerimientos

Para definirlos se recomienda usar una sentencia descriptiva que indique qué debe hacer el sitio o producto o debe permitir hacer a los usuarios, detallándola más adelante al ir avanzando en el proceso e ir obteniendo feedback de los test iniciales.

Seguir leyendo «Requerimientos de un proyecto»

Trabajando como Product Owner

Recientemente he trabajado como Product Owner, (PO) y me gustaría dejar constancia de como se estaba realizando esa tarea, ya que me parece un approach muy bueno para el desarrollo de un producto.

En este caso la empresa tenía un equipo de Producto que eran los que efectuaban el desarrollo del producto (research, entrevistas con usuarios, Design Sprints…) y cuyos stakeholders trasladaban las insights y nuevas necesidades de los usuarios al Storiesonboard.

Era mi misión dividir esas nuevas ideas en formato de User Story juntándolas en Releases, en base al valor aportado (marcado por los OKRs) al backlog en JIRA.

A continuación muestro una imagen del ciclo de desarrollo de US que empleábamos:

Produc Owner Cycle

Este ciclo no tenía porque hacerse completo. Si mientras ha estado en el backlog, se habían descubierto nuevas ideas, la User Story volvía al descubrimiento y al StoryMap. La cuestión era:

Minimizar la cantidad de trabajo no realizado.

Empleábamos:

  • Artefactos: Storiesonboard, JIRA, Trello y Slack.
  • Ceremonias (siempre con timing): Daily por squad y grupal (diaria, 15´), Syncro (una cada 2 semanas, 30-45´), Retros (cada 3-4 semanas, 60´) y Asamblea (cada 2 meses, 2h).

Story mapping

Para realizar storymapping usabamos Storiesonboard.com, un software (de pago) que actúa como una panel donde puedes ir distribuyendo las User Stories (US en adelante) en releases y features, y que permite organizar el crecimiento atómico del producto.

Story mapping

En los cuadrados azules, estaban los OKR de la compañía, en los amarillos las MMFs (siglas de Minimum Markatable Feature, característica mínima comercializable) necesarias para alcanzar esos OKR, descritas como adjetivos. Por último, en blanco, debajo de la columna de cada feature, las US necesarias para alcanzarlas. A la izquierda, en letra azul, se marca en que Release o MVP (Minimum Viable Product, Producto mínimo viable) están esas US.

Lógicamente las MMF que tenían más valor estaban más a la izquierda, así como las US con más valor estaban más arriba. Para organizarlo es necesario que el PO disponga de conocimientos y experiencia en aspectos de negocio.

El JIRA estaba dividido en 3 paneles, uno para cada tipo de usuario que trabajaba con él, enlazando así el trabajo del equipo de desarrollo a los objetivos de negocio, muy importante para conocer el estado de una feature y seguir su trazabilidad.

MMF Board

El primer panel, es el MMF Board que posee 3 columnas «To Do, In progress y Done». Puede haber varias MMF por release, enlazadas entre ellas por una etiqueta de JIRA que indica el nombre de la release.

Seguir leyendo «Trabajando como Product Owner»

Product Owning en Flywire

Al dejar Capgemini me surgió la oportunidad de colaborar durante 3 meses como externa en Flywire, una conocida empresa valenciana por su gran equipo de desarrollo.

Flywire

El trabajo en sí consistía en ser Product Owner de uno de sus squads, dentro de la nueva metodología de trabajo que les estaba ayudando a implantar @XaV1uzz, ya que han crecido muy rápidamente, y como sucede en muchas empresas cuando este caso ocurre, el proceso de ajuste y evolución es complejo. No es lo mismo pasar de gestionar 6 personas a 150 en 5 años.

Si acepte el reto (al día siguiente de finalizar en Capgemini) fue porque conocía la empresa gracias a que esponsorizaban los UXAcademy y a gente que trabajaba dentro de ella.

Además creo en los principios Agile y era una manera de aprender como lo estaban aplicando (había estado en otras empresas que se denominan «Agile» y quería ver otro ejemplo), con el añadido extra de que la mitad de la empresa está en Estados Unidos por lo que toda la comunicación es en inglés.

Seguir leyendo «Product Owning en Flywire»

UX Team Leader en Capgemini

Desde septiembre 2015 hasta octubre 2016 he formado parte del equipo UX de Capgemini en Valencia, siendo los últimos 10 meses UX Team Leader de uno de sus clientes más relevantes.

Capgemini

Los primeros meses trabajé con el equipo del Coe Java Devon para clientes de Valencia así como empresas internacionales, realizando entre otros proyectos:

  • una aplicación en la que se priorizaba la importancia visual de poder ver y gestionar unos servicios, tanto para gran pantalla táctil como para desktop,
  • el diseño de una app para los trabajadores que realizaban el reparto de una gran empresa comercial,
  • la realización del nuevo sistema de diseño para el desarrollo interno de todas sus aplicaciones de una gran empresa francesa del sector retail

Entre mis funciones destacaban la toma de requerimientos con el cliente, el prototipado y diseño final del producto, las pruebas y entregas con los usuarios y la creación de documentación para su implementación y entrega.

UX Team Leader

Y aunque estaba muy a gusto trabajando para diversos clientes, el equipo crecía y me dieron la oportunidad de ser UX Team Leader para el cliente más importante, una gran empresa valenciana del sector retail, gestionando un equipo propio formado por 3 increíbles personas.

Principalmente, aparte de las tareas propias de mi cargo de gestión del equipo, gestión del trabajo, reporte a cliente, facturación, estimación y planificación de proyectos… teníamos 2 ramas principales de trabajo:

  1. La creación y evolución de las diferentes Guide User Interface (o Sistemas de diseño) para cada dispositivo (móvil, tablet, desktop, caja registradora, TPV…), para su implementación en un framework con el cual se desarrollaban todas las aplicaciones internas.
  2. El desarrollo de aplicaciones principalmente internas, desde la toma de requisitos, prototipado, testeo, diseño y posterior ejecución.

Me gustaría mucho agradecer la oportunidad que se me dió de gestionar esa responsabilidad, así como a las personas del equipo (ya saben quién son) por el gran apoyo y soporte que fueron, tanto en la fase de onboarding del proyecto como en las horas que pasamos juntas trabajando.

Sin el equipo nada hubiera sido posible.

En septiembre de 2016, tomé una de las decisiones personales más importantes y difíciles de mi vida y decidí buscar nuevos retos.

Nota: Por confidencialidad no puedo subir ejemplos de los trabajos realizados.

Rediseño de la página de reserva

Continuamos mejorando el proceso de reserva de Centraldereservas.com. En concreto se trata de la página más importante para mí, donde el usuario finaliza su reserva de alojamiento, poniendo sus datos personales y bancarios.

La página donde el usuario finaliza su reserva de alojamiento es una de las más delicadas de todo el proceso. El principal problema de la actual era que no era responsive por lo que los usuarios que reservaban con el móvil tenían serios problemas para visualizar y rellenar los campos al estar diseñada para su uso en un ordenador. Con lo cual al ser el punto más doloroso de todo el proceso, es una tarea de prioridad número 1.

El cambio a una versión responsive ha sido un proceso complejo y duradero, pero indiscutiblemente necesario.

Otra de las páginas más complejas, el listado de alojamientos disponibles, ya había sido lanzado siendo un éxito el incremento de búsquedas en móviles. Ahora le tocaba a la página donde el usuario tiene que perder su tiempo rellenando un odiado formulario (¿a quien le gusta rellenar formularios?), y pagar.

Listado alojamientos

La cuestión es que dado como estaba construida esa página no era tan sencillo cambiar las CSS y adaptar la página a todos los dispositivos. Si se quería aprovechar el mismo código para todas las versiones y no generar 3 páginas diferentes (desktop, iPad y móvil) con su incremento de coste de mantenimiento, implicaba un cambio en la estructura del código de la página y la ubicación de ciertos bloques de contenidos.

Lógicamente, en el proceso están implicados muchos stakeholders, incluido el CEO. No siempre es fácil hacer entender a una persona ajena al código, que si se quiere usar el mismo código para todos los dispositivos la ubicación de ciertos elementos a lo mejor no puede ser igual. Se trabajó mucho en ello, reestructurando la información para que se visualizase en el orden adecuado en todos los dispositivos.

Dada la importancia que tiene en el negocio que el proceso sea fluido y sencillo, el cambio debía ser muy estudiado, ya que cualquier equivocación puede llevar a un descenso en el número de clientes que finalizan sus reservas.

A continuación se muestra a la izquierda como era el diseño anterior y como es la versión actual en su vista de escritorio.

sr-3

Aquí vemos como fue el diseño para dispositivos móviles, tanto del listado como de la página de confirmación.

Página de reserva móvil

Página de confirmación

Una vez que el usuario ha seleccionado el método de pago y este se ha efectuado, el usuario necesita ver la página donde se le confirma que el pago se ha realizado correctamente y los detalles de la reserva.

Seguir leyendo «Rediseño de la página de reserva»

Mejorando la experiencia de pago

Con motivo de la brecha que hubo en seguridad el verano pasado cuando millones de tarjetas de crédito fueron clonadas, se implementó en el proceso de pago una pasarela segura.

El momento del pago genera estrés en los usuarios

Se ha visto en estudios que los usuarios en el momento de introducir sus datos o de tomar la decisión de apretar el botón sienten ansiedad debido a diferentes causas:

  • Falta de información
  • Falta de confianza en el sitio web
  • No saben acabar el proceso
  • Ruidos o distracciones

La redirección a la plataforma segura de pago durante el proceso de pago con tarjeta implicaba que el usuario es redirigido a la interfaz del banco donde debe introducir sus datos de tarjeta.

Esto que parece muy sencillo, no siempre lo es.

Para facilitar la comprensión de los pasos de pago y reducir la ansiedad en este momento informando al usuario de lo que iba a pasar, se decidió crear una serie de imágenes que resumieran el proceso de manera visual.

Aquí podeis ver el resultado:

Pasos del pago con tarjeta
Zona del pago con tarjeta del formulario de reserva 

Antes de llegar a este diseño, lo que había era completamente diferente:

Seguir leyendo «Mejorando la experiencia de pago»

Seguimos mejorando el listado de reservas en los móviles

Hace unas semanas lanzábamos el nuevo listado del sistema de reservas adaptado a móviles. 

Y como empresa AGILE que somos, hemos observado los primeros datos y pensado en como podemos optimizar el diseño.

Listado de alojamientos

Mejoras diseño
Orden y filtros

Lo primero que hemos hecho ha sido subir las funcionalidades de ordenar y filtrar a la parte superior, justo debajo de la búsqueda, quitando en la primera visualización la barra del pie. Al hacer scroll la barra inferior vuelve a aparecer.

Esto se ha hecho al analizar el número de usuarios que usaban esta función versus los datos que teníamos previamente.

Seguir leyendo «Seguimos mejorando el listado de reservas en los móviles»

Listado de alojamiento adaptado a móviles III

Entre las novedades más destacadas está la visualización de las imágenes del alojamiento y la posibilidad de interactuar entre los filtros y el mapa.

Galería de fotos

La galería es una de las zonas más visitadas por los usuarios a la hora de reservar un alojamiento.

Por ello, para facilitarles el acceso pusimos que tanto desde el listado como desde la ficha pudieran acceder a ella.
Galeria en el móvil

Debajo de la imagen pone el nombre del alojamiento, y el número de foto que estás visualizando, así como el número total de imágenes para que el usuario sepa cuantas imágenes le quedan por ver.

Mapa

El mapa era otro de los puntos críticos que queríamos que quedara muy sencillo e intuitivo para el usuario, ya que mucha gente busca su alojamiento en función de donde esté situado.

Seguir leyendo «Listado de alojamiento adaptado a móviles III»

Scroll hacia arriba