Pregúntame por qué

¿Cuándo fue la última vez que preguntaste a tu usuario por qué?

Esta simple pregunta puede salvar muchos errores en tu web, mejorar tu conversión, disminuir el rebote de tus páginas o redifinir tu producto para mejor servicio de sus consumidores.

10 momentos en los que deberías plantearte preguntar a tu usuario por qué:

  1. Al abandonar su proceso de compra
  2. Si no finaliza el alta en tu página
  3. Cuándo se da de baja de tu web
  4. Si marca tus emails como spam
  5. Cuándo se da de baja de tus emails o newsletter
  6. Si no te envía esa información que le falta para completar la transacción que inició
  7. Cuándo cancela una reserva o pedido
  8. Si hace demasiado tiempo que no utiliza tu web
  9. Cuándo ha quedado satisfecho con tu servicio
  10. Cuándo le tienes “a mano”

why

 

¿Cómo lo hago? Métodos para tener respuestas de tus usuarios

Son muchos los modos de llegar a tu usuario (seguro que tú lo sabes mejor que nadie), y muchas las herramientas que existen ya en el mercado para recoger su feedback : botones, formularios, preguntas ad hoc… Escoge aquél que mejor se adecue al momento y al perfil de tu cliente. Aquí un abanico de algunos de los métodos más sencillos:

  1. Por email, tras abandonar tu web o proceso de compra. Un mensaje de tú a tú preguntando si tuvo algún problema.
  2. Encuestas masivas: si guardas una base de datos de aquellos que se dieron de baja de tu página. A veces un simple formulario de Google basta para aclarar muchas dudas.
  3. Por teléfono: si el coste de la información que consigas compensa, no dudes en llamarle.
  4. Chat online: son muchas las webs que ya lo usan. Si el volúmen de tu empresa te lo permite, nada mejor que una ayuda online.chat online
  5. Asistentes virtuales. Sí, sí, como nuestra amiga Irene de Renfe.
  6. En persona, invitándole a un pequeño focus group o entrevista.
  7. A través de un formulario: habilita una sección en tu web al clásico “sugerencias y quejas” o pequeños “buzones” donde el usuario pueda responder a preguntas como “¿echas algo en falta?” o “¿no encuentras lo que quieres?”
  8. Comentarios y opiniones en tu blog o página. Admite las críticas, dejan que voten tu servicio.
  9. Redes sociales: ¿acaso no abriste ese perfil para tener información de tus usuarios?
  10. Test de usuarios: si el problema empieza a preocuparte, consulta con un experto UX. Un test de usuarios, por ejemplo, puede marcar un punto de inflexión.

Y tú ¿cuándo y cómo preguntas a tu usuario por qué?

Perder también es un objetivo

Al trabajar un proyecto desde el punto de vista de la experiencia de usuario, a menudo nos planteamos un objetivo en términos de crecimiento: más usuarios, más visitas, más ventas, más reservas… En definitiva, más conversión.

Pero a veces perder también es un objetivo. Restar tiempo, restar burocracia, restar gastos…

No es habitual que pensemos en estos términos sobre nuestro producto pero, al final, esta resta también es una suma.

  • Puedo restar tiempo de atención al cliente haciendo mi web más sencilla, así gano tiempo que podré invertir en otras tareas.
  • Puedo restar páginas vistas a mi web de modo que mi usuario encuentre antes lo que quiere. No siempre muchas páginas vistas por visita es una buena señal…
  • Puedo restar gastos en mi oficina ofreciendo, por ejemplo, servicios online que hasta ahora ofrecía por correo. Así gano en reducción de costes.
  • Puedo restar número de llamadas a mi call center si el usuario encuentra en la web la información que espera.
  • Puedo restar pasos en el formulario que el equipo de edición de contenidos rellena con cada uno de mis anuncios, así crece el ratio de número de anuncios / tiempo.
  • Puedo restar el número de clicks que el teleoperador necesita hacer para atender esa llamada.
  • Puedo reducir tiempo de carga y capacidad de mis sistemas si elimino por fin esa sección tan antigua que nadie consulta.

Estas restas suelen llevar de la mano mejoras en intranet, administradores de páginas, flujos y métodos de trabajo. Y todas estas restas implican a menudo restar frustración a la gente que trabaja de cara al público.

Ahorro energético en el Metro de Madrid

Hace unas semanas hicimos una sencilla operación en un call center muy saturado de una empresa en Madrid: calculamos el tiempo que ganaríamos reduciendo 1 solo click a la hora de registrar una llamada.

Si multiplicábamos apenas ese par de segundos que reducíamos al gestionar una llamada, por el número de llamadas que se cogían al día, al cabo del año ahorrábamos el trabajo de un operador de un mes completo. ¡Eso sólo con eliminar un click en su aplicación!

Cambiemos el chip a la hora de pensar en mejoras y permitámonos de vez en cuando perder.

Y tú ¿qué restarías a tu producto?

Menús de navegación ¿en serio?

Navidad. Dando vueltas por distintas páginas buscando regalos o algo que me inspire, llego a la web www.dscuento.com

Decido echar un vistazo a los móviles, ya que estoy pensando en cambiar el mío.

Primera decisión: entiendo que estará en la sección de “Electrónica”.

Cabecera dscuento.com

Hasta aquí todo bien. Clico en el enlace.

Aterrizo en una página donde lo primero que me ofrece son “accesorios de electrónica”; o al menos eso es lo más visible.
Mal empezamos si veo los “accesorios de” antes que los productos de electrónica en sí…

Vuelvo al menú en busca de más ayuda y me encuentro con la siguiente división:

Menú por género en dscuento.com

¿¿¿En serio???

¿De veras esa es la principal división que se nos ocurre para artículos de electrónica? ¿Qué habrá debajo? ¿Depiladoras eléctricas en la sección de mujer y taladradoras para hombres?

Y lo mejor de todo, es que al pinchar en una u otra sólo encuentro fundas para móviles. Eso sí, la primera en la sección de mujeres es rosa, y en la de la sección de hombres azul.

what the fuck?

Rediseñando reclamador.es

Esta semana reclamador.es estrena nueva web, un rediseño por dentro y por fuera en el que he participado del lado de la usabilidad y experiencia de usuario.

El proyecto, que comenzó como lo que parecían unas pinceladas UX ha terminado dándole la vuelta a la página cual calcetín.

Para quien no lo sepa, reclamador.es es hoy una plataforma destinada a defender los derechos de los ciudadanos ante las aerolíneas. Retrasos, pérdidas de equipaje, overbooking o cancelaciones de vuelo son algunos de los casos que reclamador y su equipo de abogados llevará por ti. Lo mejor es que sólo cobran a éxito; es decir, sólo si ganan tu caso se llevan un porcentaje del 25% sobre la indemnización.

reclamador.es¿Qué le faltaba a reclamador.es?

La primera vez que hablé con Pablo, su fundador y CEO, me dio la impresión de que faltaba en su web ese lado humano que estaba en su idea original. La parte de inconformismo, el lado social y humano con el que ellos defienden su proyecto.

Finalmente, creo que el cambio de la web se asentó en 3 patas:

  1. Sencillez: mejora de sus formularios para hacerlos más sencillos al usuario. Un lenguaje más cerca de cómo alguien cuenta su incidencia en un vuelo a un amigo que al lenguaje de un abogado.
  2. Social: darle ese toque humano, dar visibilidad a sus redes, a la parte de derechos del viajero y a un tesoro que entonces estaba bastante escondido en su web, los muchos testimonios de sus clientes.
  3. Conversión: mejorar la conversión de usuarios que incluyen sus reclamaciones en la web facilitándole volver a su reclamación en cualquier momento, hacer un seguimiento de la misma, etc.

Creo que hemos conseguido bastante bien estos 3 objetivos, aunque aún es pronto para sacar conclusiones.

Lo que sí es seguro es que reclamador.es ahora es más fácil de recordar gracias a ese “Robin Hood” que Daniel Solana se ha currado (entre otras muchas cosas) en el nuevo diseño de reclamador.es.

Guía para una buena toma de requisitos

Antes de comenzar un proyecto, sea cual fuere, siempre pido a la persona que lo solicita que se siente conmigo a contarme qué quiere. Para mí, ahí empieza el trabajo principal de lo que después puede ser un rediseño, la creación de una web o simplemente la mejora de un servicio.

Los que han trabajado conmigo (siempre quise poder escribir esto, “los que han trabajado conmigo”, es taaaan de gurú) saben que soy bastante cansina con el detalle de una buena toma de requisitos. Esa charla, esa entrevista o conversación, marcará sin duda el éxito del proyecto.

Cuántas tomas de requisitos comienzan con un “quiero cambiar esto de mi web” y terminan siendo algo totalmente distinto a la idea que el dueño del producto tenía. Mejoras de secciones que terminan en rediseño de web, intuiciones no fundamentadas que terminan siendo una realidad, problemas vistos en el servicio online que se solucionan con la mejora de procesos humanos… Todo parte de la que creo la más importante de las virtudes de nuestro gremio, de los expertos ux: saber escuchar.

Por ello, en su momento, intenté sintetizar esta pequeña guía que siempre me ayuda a conducir esa toma de requisitos. Y fan como soy de la metodología de las 5 W, en ella la baso.


Guía para una buena toma de requisitos

5W: what, why, who, where, when = HOW

Las 5W

WHAT – ¿Qué es lo que necesitan? ¿Cuál es el objetivo?

Hay que saber cuál es el objetivo del proyecto, no cuál es el proyecto en sí. Éste lo decidiremos en función de las necesidades.

Por ejemplo, no es lo mismo decir
“Quiero dejar de gestionar mis pagos por teléfono”
que
“Quiero que el cliente pueda meter su cuenta bancaria en la web para domiciliarle el pago”

La primera premisa puede llevarnos a externalizar el servicio por falta de tiempo, a revisar el proceso por temas legales o a la segunda opción, el pago online.

Pero es posible que lo que parece obvio, no siempre lo sea. Tal vez tu usuario no sea del que está dispuesto a pagar online o que tu producto se esté vendiendo más por teléfono que vía web. Tenlo en cuenta.

WHY – motivos. ¿Por qué necesitan este desarrollo?

No se trata de que intenten justificar el proyecto ante nosotros, se trata de que nos expliquen de dónde surge esa necesidad.

A menudo me he encontrado que intentan justificarme ciertos desarrollos como si tuvieran que excusarse ante algo que ahora se está haciendo mal o de manera ineficaz.

No se trata de juzgar, si no de saber los motivos que empujan al cambio.

WHO – ¿Qué usuario va a ser nuestro objetivo?

No es lo mismo saber para quién es el proyecto o desarrollo (el cliente) que saber quién va a usarlo.

En una empresa un nuevo desarrollo puede ser para el equipo de atención al cliente, por ejemplo, con el fin de ahorrarle tiempo de gestión. Pero tal vez el usuario final sea el cliente de tu producto en sí, ya que tal vez intentes que sea él quien haga una acción por si mismo en vez de gestionarlo a través de alguien de tu equipo telefónicamente.

Por ejemplo, que un usuario pueda incluir y modificar sus datos de facturación a través de un panel de usuario, reducirá el tiempo de gestión y llamadas telefónicas de las personas que se encargan del seguimiento de tu cliente desde la oficina.

Hemos de distinguir a menudo, pues, entre el usuario interno y el usuario externo.

WHERE & WHEN – ¿Cuándo y dónde se va a usar?

Analizar siempre los distintos casos de uso que se pueden dar nos ayudará a preveer escenarios y momentos muy útiles. Esto nos puede ahorrar caer en ciertos errores a los que solemos llegar a través de presuposiciones.

Ejemplo: Si vas a desarrollar un servicio relacionado con el transporte público, ten en cuenta que muchos de tus usuarios acudirán a él mientras están en trayecto. Eso decidirá que tu web sea visible en un móvil o tableta.

Además de estas 5 W, que marcarán el “HOW”, trato siempre de responder a estas 5 preguntas:

  1. ¿Qué querrás medir de este desarrollo?
    La medición del objetivo te dirá el éxito del cambio.
  2. ¿Has tenido en cuenta a todos los agentes que intervienen en el cambio?
    Si hablamos de algo que estará online, ten en cuenta siempre, siempre, el SEO. Si se trata de un desarrollo técnico, habla con los desarrolladores. Si hablamos de e-commerce, no empieces sin hablar con el comercial. Ten siempre en cuenta a todos los agentes que intervienen. Como fuente de sabiduría y como “usuarios que sufrirán tus novedades”.
  3. ¿Realmente es necesario?
    A veces nos empeñamos en desarrollar funcionalidades porque “intuimos” que mejorará nuestro producto o servicio. Un test previo (test de usuarios, encuesta, entrevista o lo que corresponda) tal vez nos diga que esa intuición no era tan acertada.
  4. ¿No hay nada que ya esté resolviendo/cubriendo esta necesidad?
    Ten cuidado, a menudo no se trata de innovar, si no de resolver o mejorar.
  5. ¿Es posible que se amplíe, reduzca o elimine el proyecto? ¿que se hagan modificaciones en él?
    Si algo aprendí de las metodologías ágiles y del scrum, es que todo proyecto hay que hacerlo desde un punto de vista escalable. Si mañana hay que ampliar una sección, incluir nuevos productos o dar acceso a más usuarios, no me obligues a rehacer lo hecho. Intenta desde el principio que lo que haces tenga un modo fácil de crecer.

Y tú ¿qué cosas tienes en cuenta al comienzo de un nuevo proyecto?