Diagramas de Flujo de tareas: Ejemplo Práctico

Para todos los diseñadores de Experiencia de Usuario, una de las tareas más comunes que realizamos es la de diagramar flujos de tareas o Task Flows. En efecto, ningún diseñador de experiencias de usuario aplicadas a marcos computacionales u organizacionales puede diseñar una experiencia sin una adecuada visualización de los elementos que la componen.

Más aún: la diagramación y visualización de estos flujos de tareas nos van a mostrar posibles problemas y sugerir soluciones que no habíamos predicho.

Teoría y Herramientas

By J.J. at the English language Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=671715

By J.J. at the English language Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=671715

¿Qué sería de un diseñador de Experiencias de Usuario sin una adecuada preparación teórica y sin las herramientas adecuadas para realizar su tarea? La respuesta es el fracaso asegurado.

Es como si dijésemos que un cirujano no haya cursado la materia de cirugía y además en vez de bisturí usase un serrucho. ¿Ustedes confiarían en esa persona o pensarían que es un profesional de su disciplina? ¡Claro que no!

En UX, como en cualquier otra disciplina o ciencia, nuestro grado de profesionalidad va a estar determinado en gran medida por nuestra preparación teórica y por nuestro conocimiento de la herramienta más adecuada para nuestro trabajo.

Una vez dicho esto, para la elaboración de este artículo he usado la conceptualización teórica de visualización de arquitectura de la información sugerida por Jesse James Garrett (¡en español!) que sin ser la única, y quizás ni siquiera la mejor (o peor), probablemente sea la más usada por profesionales UX.

Como herramienta para crear las visualizaciones, elegí usar una herramienta gratuita y muy  buena llamada Draw.io. Aunque no está disponible en español, es sumamente fácil e intuitiva. Nuevamente: quizás no sea la mejor (personalmente, creo que compite codo a codo con cualquier otra), pero es gratis, simple y colaborativa.

Si son nuevos en esta área de visualización y arquitectura de información, recomiendo estudiar en profundidad la página de Garrett, les aseguro que me lo van a agradecer durante toda su carrera.

Desde lo simple a lo complejo

Un diagrama de flujo de tareas puede ser extremadamente simple, pero no por eso INEXISTENTE. Si necesitan una razón mínima para justificar la existencia de dicho diagrama (por simple que sea): DOCUMENTACIÓN.

Como ejemplo de un diagrama simple, tomemos el proceso de entrar a una habitación:

Diagrama de flujo simple

Como puede verse, este diagrama es muy simple. También podríamos agregar más condiciones, como por ejemplo:

si la puerta está cerrada, ¿tengo la llave? Si no es así, ¿cómo la consigo?

y así podríamos seguir con más condiciones. Sin embargo, siempre debemos recordar lo siguiente: una buena experiencia de usuario consiste en lograr que el usuario realice las tareas con el menor número de pasos posibles y con el menor grado de fricción

una buena experiencia de usuario consiste en lograr el menor número de pasos posibles y fricción Click To Tweet

Claro está, estos casos simples no son los más comunes. En la realidad, nuestra arquitectura va a tener grados de dificultad mucho más importantes que el diagrama superior.

Para dar un ejemplo práctico, vamos a usar el flujo de tareas que debe realizar un usuario para hacer un pago telefónico descripto en Mala Experiencia de Usuario: Aprendiendo desde el error/horror (Caso 2), dado que dicho artículo tiene una adecuada descripción del proceso y de sus muchos errores. Por tanto, veremos un ejemplo de cómo mejorar dicho proceso usando principios de UX.

Diagrama de flujo

¿Parece complejo? Pues bien, en realidad es muy simple. Si leyeron la nota donde se describe el task flow actual, verán que el proceso existente tiene una gran cantidad de pasos y debe repetirse para cada pago. En el diagrama propuesto, básicamente son 3 pasos: confirmar identidad, elegir qué pagar, pagar. Eso es todo. Nuevamente: la menor cantidad de pasos posibles para realizar una tarea en forma efectiva.

¿Cómo desarrollamos este task flow?

En primer lugar, para definir el flujo de cualquier tarea debemos reducirla a sus componentes más simples. Para este fin, usamos lo que llamamos un User Case o Caso de Uso. El mismo sería así:

Pregunta:

Como usuario: ¿qué tarea quiero hacer?

Respuesta:

Pagar una o varias facturas con tarjeta de crédito por vía telefónica.

Y termina ahí. Realmente para este caso no hay nada más. Cualquier agregado sobre esto es fricción, y como tal, absolutamente innecesaria si se puede evitar (dato: SÍ, se puede evitar)

Entonces tenemos:

  • identidad del usuario (asociada a número telefónico)
  • identificación de monto/s a pagar
  • procesamiento de tarjeta de crédito

Estos son elementos propios del user case. Pero nuestra tarea consiste en mejorar la experiencia haciendo uso de las posibilidades que nos brindan los sistemas existentes. En este caso: recuperación de datos almacenados, automatización y reutilización de procesos.

Para que se entienda: el 99,99% de las transacciones van a ser transacciones de usuarios ya existentes en el sistema. Por tanto, es innecesario pedirle la información cada vez (ni hablemos de cada vez dentro de la misma sesión, como en la nota que describe el proceso actual).

La información sólo debe ser pedida una vez, y la volveremos a pedir si el sistema identifica que esta información ha cambiado o hay razones válidas de seguridad.

Aunque no está presente en el gráfico, el sistema debe identificar automáticamente que si el usuario tiene en su haber una fecha de vencimiento en su tarjeta de crédito datada en diciembre de 2016, en enero de 2017 solicitará los datos nuevamente y no la pediremos nuevamente hasta enero de 2019.

Así y todo, para que nadie se queje por “razones de seguridad” se incluyen dos pasos (totalmente innecesarios) para la identificación del usuario: código de seguridad de tarjeta de crédito y documento.

Una vez que identificamos al usuario, extraemos la información de sus deudas. En caso de existir más de un período adeudado, ofrecemos consolidar los pagos (automáticamente en el sistema). Caso contrario, ofrecemos pagar sólo la factura más antigua.

Nota: este proceso podría mejorarse aún más. Por ejemplo, si hay 4 montos adeudados, podríamos indicar:

  • si desea pagar el monto consolidado de $nnn, marque 1.
  • si sólo desea pagar el monto adeudado del período dd/mm/aaaa de $nnn, marque 2.
  • si sólo desea pagar los montos adeudados por los períodos dd/mm/aaaadd/mm/aaaa por valor de $nnnn, marque 3.

Y así sucesivamente. Pero para los efectos del ejemplo y los ejercicios posteriores, vamos a tomar sólo 2 variables.

Una vez definido el monto a pagar, tomamos la información desde el sistema referente a la tarjeta de crédito del usuario y le preguntamos si quiere usar esos datos o ingresar nuevos. Posteriormente a la decisión del usuario, se realiza el proceso de autorización de la tarjeta de crédito en forma automática (sin interacción del usuario, NO ES NECESARIA) y finalizamos la tarea en forma condicional, ofreciendo la posibilidad de hacer otro pago en caso que el usuario desee hacerlo, pero esta vez sin necesidad de agregar absolutamente nada, sólo elegir el monto a pagar.

¿Existen consideraciones de seguridad?

Podría ser una explicación para el proceso existente. Por ejemplo, que el usuario pague la primera vez con una tarjeta robada. Esta consideración queda negada automáticamente toda vez que el usuario puede hacer lo mismo si ingresa la información manualmente. De todas maneras el objetivo (pagar el teléfono para que no corten la línea) no sería alcanzado ya que al ser denunciada la tarjeta la empresa recibiría dicha información.

La otra consideración posible ya entraría en el terreno de lo delirante: que una persona ingrese a la cuenta de un usuario para pagarle su factura telefónica, razón por la cual el sistema pide una serie de datos identificatorios para verificar que esta especie de Robin Hood telefónico no cometa tales tropelías.

Vale decir que las consideraciones de seguridad siempre existen, pero en este caso no sólo no funcionan, sino que no tienen sentido y sólo agregan fricción.

En resumen

Mediante un simple proceso y usando técnicas probadas, reducimos la cantidad de pasos a menos de la mitad, porcentaje que crece en forma exponencial para cada tarea que el usuario quiera hacer. Para tal fin, usamos diagramas de flujo para identificar los problemas, extrajimos información guardada en el servidor de la empresa y automatizamos el proceso de autorización de tarjetas de crédito.  Por supuesto, este diagrama no está probado en la vida real, y el credo de un Diseñador de Experiencias de Usuario es “¡test, test, test!”, pero indudablemente hay menos pasos y acciones más efectivas, con o sin medición.

Ejercicios

Para quienes deseen profundizar más, he aquí una serie de preguntas que pueden contestar en los comentarios. Además, pueden descargar el archivo XML con el diagrama de flujo aquí presentado, el cual pueden usar en draw.io y modificar a gusto

Preguntas

  1. ¿qué consideras que falta en este diagrama? (pista: hay al menos 2 sub-tasks que dejé fuera en forma deliberada)
  2. ¿qué modificarías en caso que el usuario tuviese más de un número telefónico?
  3. ¿qué modificarías en caso que la empresa ofreciese otras formas de pago telefónico (débito, créditos pre-cargados, trasnferencias online)?
  4. Hay un pequeño detalle agregado adrede que no es recomendable en UX ¿puedes identificarlo? (pista: es texto)
  5. En términos generales ¿cómo mejorarías este diagrama?