Cuando hablamos de UX, EU o Experiencia de Usuario, siempre hablamos del Usuario como un ser humano. Después de todo, estamos hablando de HCI o Interfaz Computadora-Humano. A la vez, nunca nos queda del todo delimitado qué sería un usuario, cuándo un usuario es un usuario y cuáles son los alcances de la relación entre las interfaces de sistemas y usuarios.

Bienvenidos Actores

En su libro sobre casos de uso Writing Effective Use Cases,  Alistair Cokburn profundiza sobre los roles en Lenguaje Unificado de Modelos (UML), definiendo a las distintas partes intervinientes en los casos de uso como Actores.  Es de fundamental importancia notar que la definición de actor no contempla sólo a seres humanos, sino a (literalmente) cualquier entidad biológica o cibernética.

Ahora bien, estos actores no se definen por lo que son, sino por sus roles en el proceso a analizar. Por ejemplo, un cliente de un restaurant puede tener innumerables características (que ciertamente no vamos a ignorar) pero para el modelo propuesto por Cockburn, este usuario va a ser identificado por su rol. De la misma manera, habrá otros actores, como el chef, mozos, adicionistas, etc. Supongamos: un cliente masculino de 50 años y etnia caucásica y una mujer de 25 años y etnia africana van a ser lo mismo en este modelo, ya que son definidos por sus roles (en este caso, clientes). Lo mismo sucede en el caso de un crítico de comidas y un chef, lo importante serán los roles que cumplan en el proceso a analizar.

El sistema propuesto por Cockburn es muy usado en UX, pero su clara concepción sistémica hace que nos sea muy complicado explicar en forma dialéctica los diferentes usuarios y sus roles. Además, en UML los roles nunca se asocian, aunque esta regla se viola a menudo por el proceso de overlapping o solapamiento. Queda claro que un sistema donde la violación de las reglas es la norma no es muy consistente ni preciso.

Más allá de Hollywood

Entonces vimos que uno de los métodos más comunes tiene algunos problemas referidos a la imprecisión de las denominaciones, lo cual nos puede suponer gravísimos problemas a la hora de definir sistemas, personas, flujos de usuario, etc.

Tomemos un ejemplo simple:

Yo creo un sitio web para un cliente (usuario). El cliente dedicará recursos humanos para manejarlo (usuarios). Estos recursos se dividirán en administración (usuarios) y creación de contenido (usuarios). Y por supuesto, el sitio web resultante de esta sinergia será experienciado por… usuarios

Mi papel entonces será procurar que todos los usuarios participantes del proceso en sus diferentes etapas y con sus diferentes roles puedan tener la mejor experiencia posible. Este ejemplo tan simple, traducido a UML es de una complejidad extrema, y casi todos los roles pueden recaer en un mismo actor. Por ejemplo, el cliente decide crear contenido, y por supuesto visualizar el contenido en el sitio web para verificar como luce. O sea: 3 roles en un sólo actor en el proceso más común que se nos pueda ocurrir (tener un sitio web)

En la imagen superior vemos como el modelo de Cockburn EXIGE violar las reglas mismas de UML mediante el overlapping. Y aún así, seguimos sin tener en claro quiénes son los usuarios y en qué parte del proceso intervienen, al menos de manera dialéctica. Esto es: el modelo de UML puede funcionar muy bien siempre y cuando tengamos la ayuda visual de sus diagramas (porque al fin de cuentas, de eso se trata precisamente). Pero de esta manera, todo es parte de un sistema y un usuario existe sólo como participante del mismo. Vale decir un engranaje de una máquina.

Hacia una identificación más precisa

Lo que sigue no es la forma “correcta” (¡espero que no sea “incorrecta”!) de identificar a nuestros usuarios, sino una propuesta que a mi entender simplifica la identificación de usuarios basados no en su rol, sino en su lugar de participación en el proceso. Básicamente, tomamos las partes interesadas o stakeholders, y le sumamos la sinergia con los sistemas y entidades artificiales. O sea: la misma propuesta de Cockburn, sólo que en vez de diferenciar por roles, diferenciamos por grupos de pertenencia dentro del proceso. Veamos el siguiente diagrama:

Roles, Metas, procesos y post-procesos de una rutina UX. Clic para agrandar

Explicación: como vimos, los roles de un usuario pueden ser complementarios, suplementarios, solapados o totalmente diferentes. De la misma manera, cada usuario puede tener metas diferentes o similares, y la forma de llegar a esa meta puede ser igual o diferente también.

Así, en esta abstracción de un user case modelo, amarillo y violeta tienen el mismo (o similar) rol, pero diferentes metas. Y violeta y naranja tienen distintos roles, pero similares metas. Los roles y las metas de cada uno de los usuarios definirán la forma de los procesos, y las entidades intervinientes en el mismo, las cuales podrán ser humanas o cibernéticas. Una vez que el proceso se define por la suma de las partes intervinientes, se llega a la acción efectiva para la meta del usuario. Pero esto puede no terminar aquí: existe una instancia de post-proceso que realimenta tanto a las entidades como a los usuarios.

Ejemplo concreto

• Rol: Consumidor
• Meta: Necesito comprar un teléfono.
• Proceso: Compra online
• Entidades: Sistema e-commerce, algoritmo de recomendación de productos, vendedor (hay muchas más, esto es una simplificación)
• Acción Efectiva: Compra
• Post-Proceso: Mi acción efectiva es referida a un servicio de post-venta y al algoritmo de recomendación, que aprende de mi comportamiento y puede sugerirme productos basados en mis intereses, realimentando (o incluso creando) mi necesidad de adquirir un producto relacionado, generando un loop en que todo el proceso vuelve a realizarse desde el principio

Como puede verse, un caso cotidiano que involucra muchos procesos y entidades. ¿Y usuarios? Claro, también usuarios. El vendedor, el agente de atención al cliente, incluso usuarios como yo son todos usuarios del sistema que lo afectan y lo realimentan, y que percibirán una experiencia de usuario que puede coincidir o no con la mía, complementarla, negarla, etc.

Lo importante de este diagrama y esta larga introducción (mis disculpas) es reconocer no sólo las interacciones, sino el plano desde donde nacen las interacciones, y quiénes son las entidades que interactúan para generarlas, modificarlas, enriquecerlas o perturbarlas.

OK, pasemos a los robots

Seamos sinceros, si llegaron hasta aquí es porque quieren saber cómo termina la película y si los robots finalmente ganan.

El spoiler es que sí, en la misma manera que los humanos.

En una era en que robótica, machine learning o IoT son tan comunes, es un gran desafío para los diseñadores UX considerar a las entidades cibernéticas y su lugar en los procesos. Un desafío que ofrece muchísima resistencia. Para mi gran sorpresa, en distintas charlas, conferencias, libros, etc, encuentro que abandonar el lugar seguro de Factores Humanos y HCI es algo muy resistido por profesionales UX. A veces, sólo en términos dialécticos. Otras veces, lamentablemente, ignorando completamente a estas entidades.

Yo podría simplemente exponer el Test de Turing y terminar con cualquier controversia (bueno, en algunos casos de gente muy testaruda, exacerbarla). Pero la realidad es que en muchos casos, estas entidades no pasarían el Test de Turing, y aún así estamos obligados a considerarlas como usuarios.

Ejemplo práctico:

Vehículo de exploración marciana (Rover) Sojourner, Dominio público, https://commons.wikimedia.org/w/index.php?curid=226140

La exploración extra-planetaria se hace con robots, debido a imposibilidades técnicas y fácticas para la exploración por seres humanos. Lo que vemos a la izquierda es uno de esos robots, el Sojourner, usado para exploración en Marte.

Creo que no hace falta que me extienda mucho en las consideraciones de diseño para nuestro usuario robótico (por ejemplo: ¿por qué no es antropomórfico?). Pero es más que evidente que nuestro usuario tuvo más inversión en UX que cualquier usuario humano.

¿Les queda lejos Marte? Pues bien, pregunten a cualquier SEO si no trabaja constantemente para agradar a una máquina o spider. O pregúntense a ustedes mismos, qué publicidades y servicios van a ver luego de leer esta nota, y quién (o QUÉ) manipula todos sus gustos, preferencias, modas, etc.

Flash de noticias: el futuro ya es viejo.

Resumiendo: las entidades cibernéticas son parte de la consideración de usuarios para una experiencia XCI compleja.

Bibliografía Adicional

Why Robots Must Learn to Tell Us “No” por Gordon Briggs y Matthias Scheutz

Esta nota continúa en Hacia una nueva categorización de Usuarios

Fabio Devin

Administrador UXpañol.com
Diseñador Gráfico y UX Evangelist
Experto en Experiencia de Usuario, habiendo trabajado para distintas empresas Fortune 500, gobiernos, personalidades, etc