Cómo adoptar un proceso de diseño centrado en el usuario en equipos ágiles

Es bastante común en las empresas de desarrollo tener equipos enteros trabajando mediante metodologías ágiles mucho antes de incorporar ningún rol especializado en Experiencia de Usuario. Incluso cuando cuentan con Diseñadores Gráficos, los referentes clásicos en prácticas como Scrum o Kanban no son muy explícitos en cómo o cuándo deben participar dichos roles durante el proceso. Cuando estos equipos necesitan de una vez por todas tomar una estrategia donde el producto que desarrollan sí tenga en cuenta al usuario para el que está destinado surgen las preguntas: cómo lo hacemos.

Diseñadores de …

Hace unos años cuando preguntaba a los desarrolladores qué esperaban de mí como diseñadora respondían algo así:

Espero que los diseñadores me entreguen un diseño de las pantallas y los flujos donde quede claro cómo debe comportarse la aplicación. Todo esto lo espero antes de empezar a trabajar en una User Story.

Básicamente proponían que el lugar de un diseñador era el de crear especificaciones (las interfaces de usuario vendrían a sustituir los diagramas de casos de uso, de flujo y modelado de negocio) siempre desde el lado del producto (ya que durante el desarrollo ni se nos ve ni se nos espera).

Evidentemente hoy en día no se concibe que un desarrollador sea ajeno al qué debe tener un producto al igual que no es realista que un diseñador no participe en el cómo debe funcionar. Sin embargo, las fórmulas para combinar a estos roles tan especializados dentro del flujo de trabajo ágil no resultan aún claras y, peor aún, generan la sensación de que aún existe más carga de trabajo.

La metodología como producto

Cuando se empieza a poner en práctica algo que hasta entonces no se había hecho o no había dado resultado tenemos que tener en cuenta que pueden llegar fricciones: hay que balancear la cantidad de cosas nuevas que se tienen que adoptar, lo bien o mal que nos las llevamos a la práctica y/o lo útil que resultan para el producto o el equipo.

Si consideramos la metodología de diseño centrado en el usuario como un producto, el equipo serían nuestros usuarios, por lo tanto la ‘percepción’ que tengan es tan importante como la propia eficacia y eficiencia de la metodología.

A continuación expongo algunas ideas sobre cómo enfocar ciertas actividades típicas de metodologías de trabajo como Kanban o Scrum para incorporar prácticas de análisis, diseño y validación para el desarrollo de productos con una mejor Experiencia de Usuario.

User Stories

La idea de las user stories o historias de usuario en desarrollo es muy sencilla, se han usado durante muchos años en la industria, aunque no fue hasta los años 90 que comenzó a recomendarse el uso de una plantilla en la que no sólo se contaba la historia desde la perspectiva del usuario, sino que que se añadía cierto contexto e intencionalidad. La plantilla más sencilla es la siguiente:

As a [type of user]

I want to [do something]

So that I can [get some benefit]

Las historias de usuario son una oportunidad para comenzar la conversación con el equipo de desarrollo y de producto incluyendo la información que hemos obtenido en nuestra investigación.

Type of user (Persona). No hablaremos solamente de tipos de usuarios, sino que podremos ser más específicos y mencionar a la Persona protagonista (la cual lleva consigo una información de valor que podría considerarse parte de los requisitos no funcionales de la plataforma).

Do something (Motivation). Cada historia de usuario debería estar enfocada a resolver un problema concreto, éste problema vendría especificado por la necesidad de un usuario a realizar una actividad.

Get some benefit (Expected outcome). Las actividades y necesidades que los usuarios quieren poder hacer con nuestra solución buscan alcanzar un objetivo concreto, incluirlo como parte de la historia nos ayudará a entender el propósito e incluso a identificar escenarios de test.

Backlog

El backlog es la herramienta que se utilizar para gestionar las User Stories que definen el producto digital, aunque también se incluyen otros conceptos como Epics (User Story de gran tamaño) y Themes (conjunto de epics). Organizar un y priorizarlo no es una tarea menor, aunque se simplifica si mantenemos claro los objetivos y creamos ciertas convenciones.

  1. Epics y Themes deben servir para crear una visión de producto a alto nivel
  2. Las User Sotries deben facilitar la ejecución y entrega del producto

A mí me gusta trabajar con prototipos de baja fidelidad para el primer objetivo y refinar con prototipos de alta fidelidad para el segundo. Es importante considerar para este segundo caso la velocidad a la que se tienen que tomar ciertas decisiones, la cual es posible alcanzar si se han creado recursos como guías de estilo y componentes de la Interfaz de Usuario (UI en sus siglas en inglés).

Desde el aspecto de la validación también se puede trabajar a diferentes niveles de acuerdo con estos objetivos.

Para el objetivo primero definiremos los escenarios que pueden ser más interesantes testear y los KPIs que nos indicarán el resultado y para el segundo la métrica que ayudará a calcular dichos KPIs.

Hay equipos que trabajan con dos backlogs (product backlog y sprint backlog) diferentes para cada uno de los objetivos. Esto tiene como ventaja la libertad para estructurar ambos pipelines como resulten más cómodos, pero carga de mayor trabajo a la hora de priorizar y planificar. Trabajar en un solo backlog requiere sin embargo de más consenso en la convención que quiera tomarse y cuando se trata de incorporar nuevas actividades se generará aún más fricción.

Qué podemos esperar

Cuando las cosas van bien…

  • el equipo entiende el problema y forma parte de la definición de la solución óptima
  • el equipo tiene claro los requerimientos de la solución
  • el equipo sabe lo que tiene que hacer en cada momento

Cuando las cosas van mal…

  • el equipo deja cosas sin terminar
  • el equipo deja de comunicar cosas importantes
  • el equipo hace tareas sin entender de dónde viene la necesidad
  • el equipo no va alineado

Una mánager me dijo hace tiempo algo que me encantó

No hace falta estar de acuerdo sino estar alineados.

Cuando se trata de definir procesos, podemos estar más o menos convencidos de que van a funcionar, pero si el equipo decide conjuntamente seguirlo cualquier persona que se desalinee hará que el resto no funcione de forma óptima.

La mejor estrategia es ir incorporando nuevas técnicas poco a poco, que el equipo se acostumbre a usar ciertos términos e identificar la necesidad de hacer una mejor investigación, mejor diseño y mejor testing y por lo tanto de seguir incluyendo más y mejores técnicas de diseño centrado en el usuario.

Conclusiones

Las técnicas de diseño centrado en el usuario no deben ser incompatibles con las metodologías ágiles, la forma en la que definimos el problema y describimos la solución pueden ayudar a mantener un enfoque más dirigido hacia las personas que usan el software y a conducirnos hacia soluciones que las tengan más en cuenta. Tanto lo que hacemos en diseño como la forma en lo que lo hacemos es parte de la comunicación y el proceso de entrega, así como de la creación e identificación de necesidades del producto.

La siguiente pregunta que me formulo es ¿estamos dispuestos a asumir el esfuerzo?

Design Studio – más que una herramienta

La técnica de Design Studio ha sido introducida por primera vez en el contexto de desarrollo ágil como una herramienta de colaboración para ideación de soluciones mediante sketching. Con el paso del tiempo, he tenido la ocasión de poner esta técnica en práctica en múltiples ocasiones con equipos de diferente naturaleza: programadores y diseñadores, analistas y expertos de dominio, sólo diseñadores, etc.

Durante cada una de las sesiones, he ido experimentando cómo los participantes no sólo aportaban sus ideas, criticaban o recogían nuevo conocimiento sobre el problema, sino también, cómo se destapaban las ambigüedades, incertidumbres y las conjeturas erróneas acerca de qué es lo que necesitan los usuarios y de si las propuestas iban en algún momento encaminadas a resolverlas.

La Design Studio es, más que una herramienta de colaboración, una técnica necesaria en una metodología de Diseño Centrado en el Usuario. En este artículo me gustaría recoger algunas de las claves para llevarla a la práctica y sacarle partido. Si quieres saber más sobre cómo planificarla te recomiendo el artículo The Design of a Design Studio y el siguiente recurso.

Diseño dirigido por necesidades de usuario

Como es conocido, en la metodología de Diseño Centrado en el Usuario se parte de la base de que los usuarios que van a utilizar la solución saben mejor que nadie cuáles son sus necesidades.

Independientemente de la capacidad de cada uno de saber expresar verbalmente lo que necesitan o no, las entrevistas a usuarios bien ejecutadas son una fuente directa y rica de información que debe dirigir el resto del proceso de diseño. Obviamente, no es la única fuente, la observación de campo, la comparación de productos, el análisis estadístico de comportamiento previo, o el user testing también proporcionan mucho conocimiento sobre cómo se comportan nuestros usuarios.

Las entrevistas requieren de un ejercicio de análisis posterior donde buscar cómo se expresan los objetivos, las expectativas, las restricciones, el contexto, las preocupaciones, las ideas y los problemas a los que se enfrentan los usuarios. De todos esos aspectos, se busca identificar también patrones de comportamiento para armar lo que se conoce como modelo mental del usuario.

Esta es una información de partida útil para alimentar la sesión de diseño durante una Design Studio.

Personas y escenarios

Las personas y los escenarios suelen ser los grandes olvidados a pesar de que toda solución debe partir de un problema bien formulado como una historia real que ocurre en un contexto real con un usuario real. O digamos, al menos, realista.  Sin embargo, en el momento de idear soluciones y, sobre todo, de defenderlas, tendemos a olvidar para quién se estaba solucionando. La persona y el escenario deben también dirigir la historia que se cuenta, puesto que no estamos en una fase de diseño final, detallado, o de alta fidelidad, sino, todo lo contrario, estamos conceptualizando posibles soluciones y planteando nuevas hipótesis a explorar.

Crítica y valoración de propuestas

Existen múltiples formas de valorar las propuestas de los participantes, aunque lo que es una constante es que, después de una larga jornada de diseño y creatividad las “mentes pensantes” estén poco motivadas a recibir críticas. Puntuar según criterios puede parecer a priori una forma objetiva de valorar el conjunto de las ideas pero se corre el riesgo de descartar demasiado pronto ideas que son geniales por el mero hecho de no haber convencido a la audiencia. Por otra parte, expresar críticas sin el propósito de buscar debilidades para mejorarlas suele minar la actitud de los participantes.

La mejor opción en mi opinión es buscar la validación de las propuestas según los supuestos que se han analizado anteriormente ¿satisface o no los requerimientos que se habían asumido? Posteriormente se puede hacer un planteamiento de en qué punto está la propuesta, es decir, qué haría falta para llevarla a cabo más que asociarle una nota o una ‘prioridad’. Las prioridades son de hecho la forma más macabra de acabar con las grandes ideas después de una Design Studio. Lo ideal, en este caso, es ser capaz de identificar qué supuestos siguen siendo válidos, qué aspectos hay que volver a investigar con o sin usuarios, y cuál es el beneficio que de ejecutar esa idea podría obtenerse al respecto.

Como decía, la técnica de Design Studio es más que una simple herramienta de colaboración e ideación, resulta convertirse en una representación de una parte del proceso de Diseño Centrado en el Usuario y de la formas de cooperación y estrategias de producto que va a diseñarse. Más allá de las complejidades de entrevistar usuarios, sketchear y criticar, lo que se persigue con esta técnica es mostrar las fortalezas y flaquezas de las que se parte.

Con un poco de suerte, puede convertirse en una práctica que cambie la forma de desarrollar productos digitales, no por lo ágil, sino por su orientación a desarrollar soluciones que apasionen a sus usuarios.