Conferencia Agile Spain
Este año voy a asistir a la CAS 2017 en Sevilla como voluntaria.
Me apatece un montón porque aunque he ido a muchos eventos nunca he participado con ese rol, y ahora que dispongo de tiempo me parece una forma genial de aprender y conocer a gente.
Para los que no lo sepan la Conferencia Agile Spain (@confagilespain) es un evento que se celebra cada año en una ciudad diferente, generado por personas que viven el desarrollo de software de una manera diferente.
Profesionales del sector comparten conocimientos y experiencias en torno a las metodologías ágiles y como personalmente creo en ellas para desarrollar productos y servicios, es una oportunidad única de compartir conocimientos con empresas y personas de España que piensan igual.
¡Nos vemos allí el 7!
Y el sábado a primera hora a coger el AVE directa a Zaragoza a la Women TechMakers! Moriré de cansancio???? Nooo, I can!!!
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.
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.
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.
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:
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.
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.
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.
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.