Requisitos, arquetipos y escenarios

Fotografía de primer plano de Iker Sesma Martínez

Iker Sesma Martínez

Licencia de este artículo ↓
EN CONSTRUCCIÓN  Ante la oportunidad de iniciar un nuevo proceso de investigación, me vi obligado a redefinir una serie de conceptos que me resultaban confusos, contradictorios, imprecisos... Para mi y también para el resto de personas involucradas en el proyecto.
Esquema realizado a mano donde se resume la fase de investigación del DCU
I. Esquema teórico de la fase de investigación del Diseño Centrado en el Usuario. ¿Cómo funcionará en la práctica? / Iker 'giveevig'
 

Voy a resumir el proceso teórico tal y como he considerado que tiene más sentido. Después, lo pondré en práctica y en unas semanas volveré para ajustarlo y mejorarlo.

Tras la investigación, los datos obtenidos se trabajan junto con el equipo multidisciplinar para actualizar el listado de requisitos y definir personas y escenarios. A partir de estos tres pilares que se crean en esta subfase llamada mapeado, surgirán artefactos (documentos) esenciales para los siguientes pasos y que irán evolucionando según vayamos avanzando en el proceso.

 

▌ 1. Requisitos

 

Los requisitos son el listado completo de funcionalidades y características que deberá tener el producto o servicio final. Nace en las primeras reuniones con el cliente y el resto de los stakeholders (si es que se trata de un encargo), y según se vaya investigando, los requisitos irán concretándose, juntándose con nuevas hipótesis, sospechas, insights... que habrá que confirmar o desechar.

Al final de este artículo, en la sección 'Más', listo referencias para profundizar en este tema.

 

▌ 2. Arquetipos

 

Existen distintos términos al respecto: proto-personas, personaes, personas, arquetipos, buyer-persona, user-persona... Al final del artículo listo referencias con sus respectivas definiciones y distinciones, pero por mi parte he decidido utilizar el término arquetipo, para evitar posibles confusiones con la palabra en castellano persona.

Los arquetipos son representaciones de pequeños segmentos de la audiencia de nuestro producto que comparten ciertas características como pueden ser comportamientos u objetivos. Son una herramienta que nos ayuda a comprender profundamente a cada tipo de nuestros usuarios, para lograr soluciones que estén basadas en sus necesidades. Cada perfil identificado se pretende convertir en un documento (idealmente no más de 6) para que así se pueda visualizar, interiorizar y distinguir cada caso. Propongo que este documento tenga la siguiente información y estructura.

- Nombre y apellidos fictícios
- Fotografía fictícia
- Información básica (hábitos, datos demográficos, aficiones...)
- Motivaciones para usar el producto o servicio
- Recelos / prejuicios
- Otros

Cada arquetipo busca recoger la información compleja de cada perfil y humanizarla al volcarla en un documento que permitirá hacerla más fácil de recordar y utilizar.

Ahora bien, ¿cómo determinar cuáles arquetipos? Una buena pregunta en la que profundizaré. Dejo referencias en 'Más'.

 

▌ 3. Escenarios

 

En paralelo con la definición de los arquetipos se crean los escenarios, donde se le da a cada perfil una serie de tareas que llevar a cabo, en un contexto determinado.
Estas son las tres partes clave, y el contenido de cada una:

- 1 actor (respondiendo a la pregunta ¿quién?)
Uno de nuestros arquetipos definidos.

- 1-n objetivos (respondiendo a la pregunta ¿para qué?)
Se describirá el fin principal, con indicaciones de qué y cómo se pretende llevar a cabo.
Después se listarán las tareas detectadas para llevar a cabo dicho fin.
También se reflexionará e indicará la información que el usuario necesitará para llevar a cabo con éxito sus tareas.
Por último, se especificarán las frustraciones de las que habrá que librarle al usuario (generales, muy relacionadas con recomendaciones de usabilidad).

- 1-m características del entorno (respondiendo a la pregunta ¿en qué contexto?)
El entorno es todo lo que rodea al usuario en el transcurso de llevar a cabo sus tareas.
Se indicarán las características de los dispositivos que se emplean (interfaces).
También los detalles del entorno físico (ruido, espacio disponible...) y el entorno social (otros trabajadores, distracciones...).
Por último, se detallará, si corresponde, el estado mental / anímico del actor.

Podrá haber tantos escenarios como consideremos necesario. Además, como cada escenario cuenta con una serie de tareas, si una de ellas se considerara demasiado compleja, creo que bien se podría convertir en escenario para tratarla de forma independiente y asimilar mejor todo lo que implique.
Relacionado con las tareas y el objetivo, estas se obtendrán del listado de requisitos existentes. De esta manera vemos cómo se relacionan requisitos, arquetipos y escenarios entre sí. De hecho, bien podríamos considerarel escenario el centro o fin de los anteriores, puesto que en él se vuelca y ordena la información existente hasta este momento para elaborar documentos que nos ayuden a visualizar mejor una realidad que pretendemos mejorar.

Suele usarse mucho de ejemplo el caso del cajero automático. No es un mal ejemplo para ver cómo los escenarios representan situaciones reales y concretas; distintos tipos de usuarios (arquetipos) realizarán distintas acciones como retirar dinero o comprar entradas (tareas), todos ellos en unas ciertas condiciones de frío, lluvia, cerca de otras personas... (entorno).
En los escenarios se vuelcan, por tanto, combinaciones de elementos que nos permitirán identificar, en cada caso, distintas oportunidades y limitaciones. ¿Qué más se puede pedir?

 

▌ 4. Siguientes pasos

 

Pues hay bastante más.
De las tareas de un escenario extraeremos flujos de usuario (en inglés user flows y/o sus respectivas variantes como task flow, etc.). Cada flujo representará el camino que recorre el usuario en el sistema para la realización de una o varias de dichas tareas. Su diagramación nos dará pistas (cotejables con la info necesaria y el listado de frustraciones a evitar) para detectar pasos innecesarios, callejones sin salida... y otras consideraciones como, por ejemplo, cuándo informar al usuario de los estados del sistema (hola, principios de usabilidad).
Los flujos más complejos serán los que requieran de nuestra atención, y serán los candidatos principales a prototipar.

-------

II. Ejemplo de un diagrama de flujo según Jesse James Garrett. / jjg.net
 

El entorno del escenario, como ya dije, es todo aquello que pasa y cómo pasa mientras el usuario pretende alcanzar su fin. Este recorrido y su historia, nos lleva a crear un Mapa de experiencias o lo que se conoce en inglés como User Journey Map.
Según lo veo yo, a diferencia de los flujos de tareas que suceden mientras el usuario interactúa con la interfaz, en el mapa de experiencias también se incluyen los momentos previos y posteriores a esta interacción. Es decir, que el entorno y lo descrito en él (que afecta sobremanera al usuario) pueden ser representados aquí y lograr que podamos identificar todo aquello que perturbe al usuario, para solucionarlo.

Para llevar a cabo un mapa de experiencias necesitamos uno de los escenarios definidos, para ir conformando el mapa con su información. Definiremos distintas fases o pasos de la trayectoria que recorre el usuario. Para cada fase se listarán acciones que realiza el usuario, pensamientos que tiene y sus emociones

-------

III. Ejemplo de un mapa de experiencias o user journey map. / X
 

Como comentario final, recordar que estos y otros artefactos que creemos, además de la propia información de cada escenario, retroalimentará el listado total de requisitos, que a su vez lo hará con los escenarios. Los artefactos, además, evolucionarán y se crearán nuevas versiones de cada uno que recojerán soluciones que respondan a lo detectado, que se prototiparán y evaluarán de forma iterativa a lo largo de la vida del proceso.

 
* * *

Licencia:

Este artículo ha sido escrito por Iker Sesma Martínez bajo una licencia CC BY-NC-ND 4.0.

 

Créditos:

I: Parte del esquema realizado por Iker.

II: Flujo de muestra por Jesse James Garrett en 'A visual vocabulary for describing information architecture and interaction design'.

 

Relacionado en giveevig:

· Sección Design!

· Temas:

 

Más:

Sobre requisitos:

· Capítulo 10 '' del libro Interaction Design, beyind Human Computer Interaction, de XXXX.

· 'El animador más importante de la historia de Dragon Ball: Tadayoshi Yamamuro' - Vídeo en YouTube

 

Sobre arquetipos:

· 'El animador más importante de la historia de Dragon Ball: Tadayoshi Yamamuro' - Vídeo en YouTube

 

Sobre escenarios:

· 'El animador más importante de la historia de Dragon Ball: Tadayoshi Yamamuro' - Vídeo en YouTube

 

Sobre diagramas de flujo:

· 'El animador más importante de la historia de Dragon Ball: Tadayoshi Yamamuro' - Vídeo en YouTube

 

Sobre mapas de experiencia (journey maps):

· 'El animador más importante de la historia de Dragon Ball: Tadayoshi Yamamuro' - Vídeo en YouTube