DCU

Customer Experience y Agile

Una de las charlas que no pude ver en la CAS2017 (por estar coordinando otra de las salas) y que más me ha gustado al verla, fue la titulada: «No hay mejora de Customer Experience sin Agile» de Carlos Iglesias (@CarlosTheSailor)

El secreto es que esta relación no es unidireccional y el concepto más podereoso que espera aportar, es que Customer eXperience (CX) es una palanca para permitirnos introducir la cultura agile en las organizaciones.

Ejemplo Customer Journey Map

Para que explicar la diferencia entre User Experience (UX) y CX, Carlos nos empieza realizando un customer jorney de la típica experiencia de una boda, sacando las risas del público, lo cual ya les deja con ganas de saber más.

Definición Experiencia

Posteriormente pasa a comentar la definición de Experiencia de la RAE, destacando varios aspectos:

  • El tema de sentir
  • La práctica en el tiempo, prologanda
  • Vivido por 1 persona

Y esto último lo remarca, el tema de vivido por una persona, por un individuo. Porque pasa a explicar el mismo proceso de la experiencia de una boda, pero de SU boda.

Customer Journey Map boda Carlos

Pasa a comentar un tweet de Isidro López (@islomar) leyendo un libro de Foster Wallace «This is water»:

«La misma experiencia puede significar dos cosas totalmente diferentes para dos personas diferentes, dados dos tipos diferentes de creencias y dos maneras diferentes de construir significado desde la experiencia.»

¿Qué quiere decir esto?

No tenemos un cliente, sino muchos.

Tenemos que identificar cuales son nuestros arquetipos de clientes y trabajar de forma separada cada uno, entendiendo su journey, su experiencia completa.

Customer Jorney Map

Esto se hace con un Customer Jorney Map, poniéndo Carlos el ejemplo de uno simplificado en 5 pasos: Descubrimiento (Awareness), Consideración, Compra, Servicio y Post-compra.

Customer Journey Map

En el se identifica una serie de momentos por los que pasa el cliente,  mapeando la experienca en cuanto recuerdos positivos y negativos.

Seguir leyendo «Customer Experience y Agile»

La II Guerra Mundial, Japón y su importancia en la UX

Últimamente he estado leyendo mucho sobre Lean, Agile, Scrum, Kaizen… Y bastantes términos y artículos mencionan Japón, viniendo en muchos casos relacionados con su rápido resurgimiento después de la destrucción que vivió durante la Segunda Guerra Mundial.

Por ejemplo, el framework Scrum fue creado por Ken Schwaber y Jeff Sutherland directamente después de la publicación de Ikujiro Nonaka e Hirotaka Takeuchi de «The New New Product Development Game» en 1986, en la Harvard Business Review (HBR).

Pues bien, Nonaka fue contratado por el gobierno japonés después de la Segunda Guerra Mundial para ayudar a analizar por qué perdieron la guerra.

Otro ejemplo más relacionado con la UX o Experiencia de Usuario es el caso de W. Edwards Deming y su sistema de medios para generar de forma sostenible y económica productos y servicios que satisfagan los requerimientos del cliente (¿te suena?)

William Edwards Deming

Como consecuencia de la II Guerra Mundial, Japón estaba muy dañado, y a pesar de diferentes cómites de los países aliados, no había grandes mejoras.

La situación era grave ya que no podía producir la suficiente comida para alimentar a la población, y no podían exportar bienes para ganar dinero para comprar alimentos, ya que la producción industrial era muy mala (patrimonio negativo).

El Dr. Deming (1900-1993), ingeniero y consultor de gestión estadounidense, fue invitado por el director ejecutivo de la a Unión de Científicos e Ingenieros Japoneses, JUSE (Japanese Union of Scientists and Engineers), Qenichi Qoyanagi, para que les diera a los investigadores, líderes empresarios e ingenieros, una serie de conferencias sobre métodos de control de calidad y sus teorías de gestión en agosto de 1950 en Tokyo (Hakone Convention Center).

En ellas animaba a los japoneses a producir con calidad, siguiendo el método de realizar una investigación y mirar a futuro para producir bienes que tuvieran mercado durante mucho tiempo. Al finalizar el verano, el mensaje había llegado a le gerencia de la mayoría de las grandes compañías, como Sony.

Muchos consideran que Deming fue una de las inspiraciones del milagro económico japonés de posguerra (1950 a 1960) al influenciar con sus ideas la forma de trabajar, entre ellas:

  • Mejorar el diseño de los productos para mejorar el servicio
  • Conseguir el mejor nivel uniforme de calidad de producto
  • Mejorar las pruebas de productos en el lugar de trabajo y en los centros de investigación
  • Aumentar las ventas gracias a los mercados secundarios (globales)

En resumen, el mensaje a los líderes japoneses fue que si invertían en calidad e investigación, la mejora en el diseño y la calidad, a la larga reduciría los gastos, al tiempo que aumentaría la productividad y la cuota de mercado.

Ciclo de Deming

Conseguir esta satisfacción del cliente se logra a través de 4 fases que permiten la mejora continua:

  1. Planificación
  2. Acción
  3. Inspección
  4. Adaptación

Ciclo de Deming

Esto se conoce como el ciclo de Deming, pero te cuento una anécdota. El ciclo, fue presentado en 1929, por otro estadista, Walter A. Shewart, mentor de Deming. De hecho Deming lo llamaba «Shewhart Cycle», pero al hacerse más famoso él, es más reconocido como ciclo de Deming.

Varios fabricantes japoneses aplicaron sus técnicas de mejora continua y experimentaron niveles de calidad y productividad desconocidos hasta el momento. Combinando el aumento de calidad junto con un coste reducido creó una nueva demanda internacional de productos japoneses.

Seguir leyendo «La II Guerra Mundial, Japón y su importancia en la UX»

Eventos en Scrum I

Los eventos se usan en Scrum para crear un patrón constante y minimizar la necesidad de reuniones no definidas.

Todos los eventos son «time boxeados», es decir, tienen una duración máxima, pudiendo acabarse, siempre que se logre el objetivo del evento.

La idea es evitar el desperdicio de tiempo

El Sprint es un evento «contenedor«para todos los demás eventos, siendo cada uno de ellos una oportunidad formal para inspeccionar y adaptar algo. Y es que los creadores de Scrum,Jeff Sutherland y Ken Schwaber, diseñaron estos eventos para conseguir la máxima transparencia e inspección.

Scrum events

Existen 5 eventos diferentes:

  1. Sprint
  2. Sprint Planning, o Planificación del Sprint en castellano
  3. Daily Scrum, normalmente llamada Daily
  4. Sprint Review, o Revisión del Sprint
  5. Sprint Retrospective, o Retrospectiva del Sprint

He estado en algunas empresas que unifican Sprint Planning con Sprint Review, llamándo al evento «Syncro» o «Planificación» (adaptan Scrum a lo que han visto que mejor le funciona).

1. El Sprint

El Sprint es la base del Scrum. Es un periodo de tiempo de 1 mes, 3 o 2 semanas, durante el cual se crea un incremento de producto, utilizable y potencialmente liberable. Lo ideal es que siempre tengan la misma duración.

Para entender el párrafo anterior, debemos ver cada Sprint como un proyecto con un horizonte no mayor a un mes. Y al igual que un proyecto, el Sprint se utiliza para lograr algo. Cada Sprint tiene una definición de lo que se va a desarrollar, un diseño y un plan flexible que guiará su construcción, el trabajo y el producto resultante.

Un nuevo Sprint comienza inmediatamente después de la conclusión del Sprint anterior.

Un sprint está formado por el Sprint Planning, las Daily Scrums, el trabajo de desarrollo, Sprint Review y Sprint Retrospective.

Consideraciones a tener en cuenta durante el Sprint

  • No se realizan modificaciones que pongan en peligro el Sprint Goal.
  • Los objetivos de calidad no disminuyen.
  • El alcance (scope) puede ser clarificado y renegociado entre el Product Owner y el Developmente Team a medida que se descubren las cosas.

La limitación máxima de un mes es para minimizar riesgo y desperdicio. Si es más tiempo, en el mundo tan cambiante en el que estamos, la definición de lo que se está construyendo puede quedarse obsoleta, aumentando además la complejidad de lo creado.

Seguir leyendo «Eventos en Scrum I»

Product Manager

He estado trabajando bastante tiempo con empresas tecnológicas. En cada una tenía un nombre diferente, pero con el tiempo y hablando con la gente me he dado cuenta que se pueden aglutinar bajo uno solo: Product Manager.

Y es que uno de mis principios desde que realicé la carrera de Diseño, ha sido crear productos que la gente adore: bonitos, funcionales y usables, y sean sostenibles para la empresa.

Porque para construir un buen producto o servicio digital, el equipo o persona encargado de su Road Map, debe tener un conocimiento mixto de negocio, tecnología y experiencia del usuario (UX).

product_manager

Aunque como es imposible saber de todo, debe ser experto en al menos uno (en mi caso UX), ser apasionado por los 3 y haber trabajado en los 3 en general.

  • Negocio: no hay que olvidar que alguien tiene que pagar la fiesta. El Product Manager se centra en la optimización de un producto para alcanzar los objetivos comerciales mientras se maximiza el retorno de la inversión.
  • Tecnología: es muy complicado definir qué construir si se desconoce como se va a hacer y más importante, los recursos requeridos.
  • Experiencia del usuario: el Product Manager es la voz del usuario dentro de la empresa: debe hablar constantemente con los usuarios, testear el producto, analizar datos, detectar y priorizar los problemas a solucionar…. .

Funciones del Product Manager

Se debe establecer una visión del producto, investigando constantemente el mercado (informes de investigación, tendencias…), los usuarios (comentarios, atención al cliente, investigación etnográfica…) y el problema a resolver (mapas de empatía, customer journeys, análisis cuantitativo y cualitativo…).

Esa visión debe ser conocida por todo el equipo.

Si se realiza bien, cada miembro del equipo, desde ventas hasta desarrolladores, debe ayudar a crearla y sentirse parte de ella. Todos deben remar en la misma dirección.

Una parte importante es el establecimiento de las prioridades a desarrollar, el Road Map, el cual no es un documento definitivo, sino que puede variar dependiendo de la investigación que se vaya haciendo (recuerda que estamos en un mundo de constante cambio y es imposible predecir nada a futuro).

Seguir leyendo «Product Manager»

Falacias, sesgos y engaños

Os dejo la Keynote de la presentación en el UXSpain 2017 celebrado en Gijón de Luis Arnal‏ (@luisarnal) que no tiene desperdicio.

Luis nos cuenta ejemplos de cómo los diseñadores usan (a menudo inconscientemente) los principios de la economía del comportamiento para diseñar interfaces.

Black UX: sesgos, falacias y engaños

Imagen extraida de la keynote de Luis Arnal

Como diseñadores tenemos que darnos cuenta de la responsabilidad que tenemos con cada decisión de diseño que tomamos, ya que tienen un impacto en la forma en que las personas interactúan con los sistemas.

Arnal comenta que necesitamos diseñar de una manera más consciente para integrar los sesgos y las falacias cognitivas en las interacciones que creamos, poniendonos ejemplos de cada caso.

Si quereis ver algún resumen más del UXSpain 2017 os dejo aquí el enlace.

Eduardo Mercovich

Una de las charlas que más me ha gustado del Interaction South America 2016 (ISA), con permiso de la ofrecida por Cooper 😉 fue la de Eduardo Mercovich (@edumerco).

Nos habla de la evolución que muchos de nosotros hemos sentido cuando empezando como diseñadores web, preocupándonos de los elementos del diseño, y al ir teniendo más experiencia pasamos a preocuparnos por el usuario, la usabilidad, la UX y finalmente lo que el llama HuX (Human User Experience).

Nos cuenta como vamos aprendiendo técnicas, organizar procesos, armar equipos e intentar luchar por impactar en organizaciones para desarrollar el mundo que queremos.

Si puedes escucharla no lo dudes!

Nota: Interaction South America (ISA) es una de las conferencias de Diseño de Interacción, Experiencia de Usuario, Tecnología e Innovación más importantes de América del Sur.

Mejorando la experiencia de usuario gracias a Soporte (II)

Seguimos con el resumen de la genial charla de Inés Luna (@cuquiesp) en la Tarugoconf 2016 sobre lo aprendido al montar un equipo de soporte desde cero en una startup. (Leer antes la primera parte)

2º Fase: Escala o muere

Vas creciendo y tienes un volumen de clientes más grandes, es un caos contestarles por email, has tenido problemas con los equipos porque no sabes que hacer cuando alguien reporta un bug, los bugs no se arreglan…

Luna comenta que cuando el equipo crece busca personas que no necesariamnete tengan experiencia en soporte, sino que sean grandes comunicadores y que tengan una gran capacidad empática con los clientes, pero que tengan «huevos grandes» para tomar decisiones porque muchas veces hay que decirles que no a los clientes, pelerse con ventas que han mentido a los clientes, con producto…

Inés nos cuenta que la clave es formar un equipo fuerte y solidario. No solamente personas alineadas con la cultura de la organización sino q esten alineadas con el resto del equipo para crear un equipo muy unido ya que atención al cliente puede ser muy ingrato. ¿Cómo?:

  • Hacerles participe en el proceso de nuevas incorporaciones
  • Que el equipo cree documentos de onboarding para ayudar a los nuevos miembros
  • Poner un mentor a la persona nueva para ayudarle y que aprendan entre ellos

Segmentar a los usuarios

Cuando creces y tienes muchos clientes, seguramente ya has cabredo a más de uno (y parece que se acabe el mundo! Pero no). Si, como en su caso, eres un producto freemium, tienes que empezar a tomar decisiones,y segmentar a tus usuarios, ya que no es el mismo soporte el que le das a una persona que no paga, a una que paga poquito o a una que paga mucho.

Tienes que empezar a segmentar a los usuarios y empezar a entender:

  • Cómo de rápido puedes contestar a la gente
  • Qué tipo de incidencias equieren atención urgente
  • Cual es el canal más adecuado para cada segmento, no es lo mismo una gran corporación que tiene el pooducto instalado a medida, que una persona que lo usa gratis una vez al mes…

Zendesk

Es el momento de empezar a pensar a usar una herramienta de Customer Service profesional como ZenDesk y empezar a trabajar en los procesos, como las automatizaciones, el workflow de los tickets… ya que vas a ser mucho más eficiente en lo que haces.

Gestión de indidencias

Tambien en esta etapa debes empezar a coordinarte mucho más con el resto de los equipos, como en el caso de las incidencias técnicas o bugs, trabajando con QA, desarrollo, producto… para definir que algo es una incidencia versus que el cliente no entiende cómo usar el producto, como reproducir esa incidencia, acordar entre todos cual es el criterio para poner una prioridad, quien es el responsable de asignar esa prioridad, si esa prioridad puede variar en función del número de tickets que dispongas…

Sino hay un acuerdo entre todos, el proceso puede ser muy doloroso.

Medición y analítica

Implementas procesos con ventas, con facturción…. y ya usas una herramienta específica para atención al cliente y tienes q empezar a medir lo que estás haciendo. Y con herramientas como Zendesk puedes hacer reporting de cualquier cosa. Inés nos recomienda que nos centremos en cosas básicas en su caso por ejemplo, en el tiempo que tardaban en atender a un cliente.

Se dieron cuenta de que atendían antes a los usuarios que no pagaban, ya que preguntaban cosas más sencillas, haciendo esperar más tiempo a los que pagaban por la herramienta.

Darse cuenta de eso hizo que tuvieran que reorganizar el workflow para poner la prioridad en los clientes que más aportan.

El tiempo de resolución de un ticket es otra historia, porque si tienes incidencias que tienes que escalar a otro equipo ya no depende de tu trabajo, y ver cual es el proceso para escalar, cuanto tardan en resolverlas, cada cuanto haces una release, cada cuanto se arreglan los bugs, la proporción de tiempo entre trabajar en roadmap y hacer la plataforma más estable y arreglar bugs… Esas métricas ya no depende sólo de ti.

Satisfacción de tus usuarios

Para conocer si los usuarios estaban contentos, Inés comenta que ella implementó 2 tipos de métricas, una más transaccional que es en base a las interacciones con el equipo de soporte y la otra para conocer la satisfacción general, el NPS.

En la primera mandaba un email después de resolverles la incidencia con una encuesta, donde les preguntaba si están satisfechos o no. Descubrieron que vivían estresados con los tickets pero los usuarios estaban en un 95% sastisfechos con el servicio que tenían en soporte.

Lo segundo que implementaron fue el NPS (Net Promote Score) que no es una métrica de soporte sino que es mucha más amplia, usada en marketing, producto… que consiste en hacerles la pregunta de ¿Cómo de problable es que recomiendes este producto a un compañero de trabajo o un amigo?

Descubrieron que si bien en soporte estaban contentos, había un descontento generalizado de los clientes que no tenía que ver con soporte sino que tenía que ver con funcionalidades que habían quitado en el producto, sobre el proceso de ventas y facturación que era muy engorroso y muy lento para muchos clientes pagar, con el reposicionamiento del producto, de gestiñon de proyectos en comunicación en tiempo real que la gente no entendía porque habíaan hecho ese cambio.

Son métricas muy diferentes que te dan 2 visiones para ver como de contentos están tus usuarios.

Etapa: Todo explota

En 2014 hacen un rebranding y lanzan una visión nueva del producto. Era simplemente un lavado de cara visual, pero a los usuarios no les gustan los cambios. Y eso hace que el equipo de soporte reciba miles de llamadas contestando siempre lo mismo.

¿Qué haces cuando tus clientes no están contentos de ese cambio?

Seguir leyendo «Mejorando la experiencia de usuario gracias a Soporte (II)»

Mejorando la experiencia de usuario gracias a Soporte (I)

Inés Luna (@cuquiesp) da una charla en la Tarugoconf 2016 (a mi modo de ver espectacular) sobre lo aprendido al montar un equipo de soporte desde cero en Teambox, titulada Usuarios, clientes y animales ¿Son todos iguales? con la que me siento muy identificada por las situaciones que comenta.

Nos cuenta que ha tenido suerte de no morir en el intento ya que era la primer empleada no programadora de la compañía, así como que nunca había trabajado en una startup ni en atención al cliente.

Divide la charla en 3 fases para definir la funcion de Customer service en base del crecimiento de la compañía, ya que al ser una startup empiezan con pocos clientes hasta llegar a manejar grandes cifras (3000-4000 clientes).

1 fase: Etapa del enamoramiento

Inés comenta que en esta primera fase, estableces una relación con tus clientes, y esta tiene que ser auténtica. El problema es que no eres la unica persona que habla con tus usuarios, sino que otros equipos ventas, mkt… también lo hacen.

Soporte debe ser la voz del cliente dentro de la empresa

Pero tu eres la unica persona que se preocupa de ayudarles. El de ventas quiere vender el producto y marketing va intentar disfrazar el producto para venderles la moto de algo.

UX y soporte

Si Soporte o Call Center no acaba defendiendo al cliente, siendo su voz dentro de la empresa, se corre el riesgo de que ese servicio se hace así de segundas, como «algo que hay que tener», generando muchos problemas (algo que sucede en muchas empresas).

En Teambox, Inés nos cuenta que realizaba standup semanales donde comparte el feedback del cliente con el quipo de desarrollo y producto lo que les permite:

  • Tener una cultura de empresa de verdad centrada en los clientes
  • Identificar puntos de ficción de los usuarios con el producto
  • Descubrir casos de uso que nadie había pensado antes en la empresa, y los usuarios usan el producto de forma diferente a la que imaginabas.

Es ir más alla de la Atención al cliente y ser la voz cantante de que es lo que les pasa a tus clientes, por qué han venido a tu producto y cuales son los problemas que tienen con él.

Lo que haces con este feedback es todo y es determinante. No es solo escuchar sus preguntas y quejas y ser empático. Lo importanque es qué haces con todo ese feedback que te dan, cómo los sistematizas y lo vuelcas dentro de tu organización para que puedas influir en el producto y en el roadmap de forma q de verdad construyas un producto que resuelve los problems de verdad de tus clientes.

Una cosa que ha implementado Ines es un espacio donde los clientes pueden compartir su feedback, votar funcionalidades, sugerir que necesitan, que expresen por que las quieren… Todo eso crea un sentimiento de comunidad en la base de usuarios donde ellos mismo se ayudan unos a otros.

Seguir leyendo «Mejorando la experiencia de usuario gracias a Soporte (I)»

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.

Waidis

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.

Seguir leyendo «Consultoría UX para empresas»

Charla UX en Demium

El pasado martes di una formación en Demium sobre Experiencia de usuario a los integrantes del último AllStartup.

Formacion UX

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.

 

Scroll hacia arriba