DEV Community: Núria Isart

Documentar sí, pero que sirva para su propósito

Núria Isart — Tue, 23 Mar 2021 17:13:46 +0000

Escrito por @the_turo y Núria Isart

Este post no pretende ser una guía sobre cómo hacer una buena documentación, ya hay miles de posts de este tipo en la red y no queremos repetir lo mismo una y otra vez. Lo que queremos es plasmar nuestra experiencia en relación a la documentación: en qué situaciones nos hemos encontrado y cómo considerando estos escenarios hemos adaptado la documentación para ayudar al entendimiento del equipo y el avance del proyecto.

Muchas personas ven la documentación como una parte del proceso tediosa, repetitiva y cansada; aunque es de las partes más importantes del proyecto. Una buena documentación agilizará el buen funcionamiento y desarrollo del equipo o será un stopper que impedirá la alineación e incluso detendrá el desarrollo.

En primer lugar, hay que tener en cuenta el quién: ¿para quién va dirigida la documentación? Conocer qué es lo que le preocupa y necesita encontrar el usuario, o en nuestro caso el equipo, de esa documentación determinará el contenido.

Partiendo de la base de que la documentación es para todos los perfiles nos encontramos diferentes escenarios que hemos vivido y profundizaremos en el que más nos hemos encontrado como equipo:

Escenario 1: A pesar de invertir esfuerzo en documentación, el equipo no se entiende.
Escenario 2: La comunicación fluye y el equipo se entiende desde un inicio.
Escenario 3: La comunicación no es tan fluida, pero con la documentación se trabaja para llegar a entenderse.

Escenario 1

A pesar de invertir esfuerzo en documentación, el equipo no se entiende.
Este es lamentablemente un escenario muy común. El equipo de diseño invierte mucho tiempo creando especificaciones y sin embargo la comunicación no fluye, no se consultan esos documentos y aunque lo desarrollado tenga buena calidad, no guarda relación con lo diseñado inicialmente.

En nuestra experiencia esto se puede deber a uno o más de estos fallos:

Falta de naturalidad: La comunicación en el equipo es forzada. Esto puede ser porque los miembros vayan a velocidades diferentes, porque no comprendan los tecnicismos de la otra parte, o quizás simplemente porque a pesar de referirse a lo mismo no hablan el mismo lenguaje (por ejemplo lo especificado como “color-red-light” se llame “error-L1” en código).
Falta de transparencia: En equipos multidisciplinares, donde los diferentes miembros trabajan paralelamente en diferentes tareas, cada uno lo hace en un silo y la visibilidad del trabajo del otro es muy pobre, se dificulta la alineación, la retroalimentación y en definitiva se promueven malas prácticas cómo hacer sesiones de alineación después de haber entregado.
Visión de túnel: El enfoque es incorrecto si la tarea se resume en entregar diseños a desarrollo. Este foco excesivo en “crear especificaciones” es muy común en un modelo de trabajo en cascada en el cual se diseña, luego se especifica, luego se desarrolla, etc., y que tiene una serie de desventajas que quedarán más claras por contraste en los siguientes escenarios.

Escenario 2

La comunicación fluye y el equipo se entiende desde un inicio.
Facilitar el entendimiento en el equipo es el mayor objetivo de una buena documentación pero no es suficiente ni viable a largo plazo si requiere de mucho esfuerzo.

Idealmente un diseñador no debería invertir casi tiempo creando especificaciones es por eso que el escenario perfecto es aquel en el cual los miembros del equipo se conocen y se entienden sin necesidad de grandes esfuerzos o documentos y mucho mejor si lo hacen de manera natural desde el inicio del proyecto.

Independientemente de los puntos básicos que todo handoff debe incluir (espaciados, colores, tipografías, escenarios, prototipos, tracking, copy, links relevantes, etc.) una comunicación sin esfuerzo sienta bases en tres pilares compartidos por todo el equipo:

Naturalidad: Todos hablan el mismo lenguaje de producto, están en la misma página, hablan de lo mismo cuando es relevante y comunican si no entienden algo.
Transparencia: Todos conocen el estado actual de lo que están haciendo, saben cómo revisarlo, cómo dar feedback y cómo resolver conflictos en caso de desacuerdo.
Visión 360º: Gestionan bien no solo la entrega sino todo lo que viene antes, durante y después. Las especificaciones no se crean al terminar el diseño sino que forman parte del diseño, todos los miembros del equipo tienen acceso a los diferentes archivos y documentos del proyecto desde el principio y conversan sobre lo que se espera del trabajo mucho antes de comenzar a desarrollar, inclusive en fases tempranas de investigación e ideación, y si algo se deja fuera del output final se documenta y almacena de manera clara y accionable para poder recuperarlo después.

Escenario 3

La comunicación no es tan fluida, pero con la documentación se trabaja para llegar a entenderse.
Este es un caso bastante común sobretodo en equipos de nueva creación y es el que usaremos para explicaros nuestra experiencia. Nos encontramos frente a un equipo donde hay un cierto distanciamiento entre la definición de la funcionalidad y el desarrollo de esta.

Esta fricción causa que la funcionalidad se desarrolle sin tener en cuenta la definición o considerándola parcialmente y, por tanto, esta difiere de lo estipulado de inicio. Para corregir esta situación y crear puentes entre todos los miembros del equipo la documentación es clave.

En este escenario todos los miembros del equipo deben realizar un gran trabajo de empatía y entendimiento donde tienen que esforzarse para entenderse.

Si nos centramos en los tres pilares comentados, podemos ver que en este escenario se debe realizar un esfuerzo para el entendimiento del equipo trabajando conjuntamente en la definición de la funcionalidad y forzando esos momentos de diálogo para poder llegar a un escenario de fluidez.

Trabajar la naturalidad: Es crucial entender las diferenciaciones en el lenguaje para poder llegar a entenderse a pesar de hablar en distintos términos. Aquí es muy recomendable disponer de un glosario del equipo con las definiciones de los distintos términos que entran en conflicto. Al verbalizar su significado se llega a la conclusión que había otros términos sinónimos para referirse a la misma palabra o tenía matices diferentes. Este ejercicio de glosario conjunto permitirá una mejor comprensión y será la base para llegar a usar el mismo lenguaje.
Visibilizar el trabajo para generar transparencia: Las funciones no pueden ir por libre centrándose cada una en su nicho, deben ser conscientes de qué se está trabajando en todas las áreas del equipo aunque no participen activamente y deben tener visibilidad de las distintas acciones y documentos.
Construir conjuntamente la visión 360º: Los equipos que se encuentran en este escenario es muy recomendable que realicen mucho trabajo conjunto de definición no solo pensando en el corto plazo, sino también en el medio-largo plazo. El incluir a todas las áreas en los diferentes momentos de ideación y creación hará que interioricen mucho más la solución, se la hagan suya e incluso puede que esto modifique el enfoque de la documentación.

Un ejemplo práctico

Al inicio de trabajar con el equipo nos encontramos en esta situación. Todos queríamos entregar muy rápido valor y, por esa necesidad de entrega inmediata, no se validaba bien que la funcionalidad entregada fuera la documentada.

Otro punto que se sumó a la rapidez, fue la falta de visibilidad. Cada función hacía su parte, había menos transparencia y, por tanto, esto condujo a que ciertas funcionalidades se tuvieran que definir de nuevo o ajustar la documentación.

Aquí hubo un gran trabajo de coordinación con reuniones previas de explicación de las funcionalidades previo a la documentación y reuniones post de validación. Después de varias semanas con la misma dinámica, empezamos a trabajar mucho mejor en equipo y cada vez eran menos necesarias las validaciones posteriores o debatir el significado de los términos porque todos ya sabíamos a qué nos referíamos y cuáles eran los estándares de calidad de entrega.

Documentamos para entendernos

Con este ejemplo, queremos recalcar que no siempre los equipos empiezan trabajando en el escenario 2 que se supone que es el ideal donde todos se entienden a la perfección. En muchos casos, y sobretodo equipos de nueva creación donde los miembros no han trabajado previamente juntos, se debe realizar un trabajo previo de alineación para que todo el equipo tenga claro cómo trabaja el resto, y vaya más coordinado en entender las funcionalidades a desarrollar y los estándares de calidad exigidos de cada funcionalidad entregada.

Documentamos para que el equipo llegue a acuerdos y se realice el producto de forma más ágil, pero también documentamos para dejar constancia de lo que se ha hecho y si en un supuesto hay un cambio de equipo o entran nuevos miembros, estos puedan realizar un onboarding con facilidad sumergiéndose en lo escrito para ponerse al día de forma más rápida y eficaz.

Documentar sí, pero no hace falta documentarlo todo. Debemos hacer documentación que sirva, y en función de en qué escenario nos encontremos deberemos detallar más las funcionalidades o menos. Al final, documentamos para entendernos.

Design Sprint adaptado a la metodología PEAK

Núria Isart — Wed, 24 Feb 2021 08:12:26 +0000

Todo parte de una necesidad: los desarrolladores no se sentían partícipes de la solución que implementaban, no sentían que habían colaborado en su creación.

Dentro del equipo de desarrollo hay diferentes caminos (tracks) que se deben trabajar en paralelo. El track de delivery o business as usual es dónde el equipo piensa en el hoy, en lo que solucionarán y desarrollarán a corto plazo. En el track de discovery se investigan y detectan necesidades que deben servir para el largo plazo, el futuro. Es habitual que el equipo esté enfocado en desarrollar la solución y no tanto en pensar e investigar qué construir a medio y largo plazo. Pero hay un nexo que une ambos caminos: la definición y creación de la solución recogiendo los aprendizajes detectados en la investigación para maximizar el valor entregado.

Este nexo en función del equipo se plasma como el “final” del discovery track o como el “principio” del delivery track. Pero, independientemente del camino al que pertenezca, hacer que los desarrolladores participen en el proceso de definición y diseño es muy enriquecedor. No solo porque la solución ofrecida dispone de más puntos de vista, sino también aumenta su implicación en el desarrollo de la misma, dado que la solución es compartida e ideada por todo el equipo.

Es por eso que durante Noviembre 2020 estuvimos trabajando en incorporar la metodología Design Sprint a nuestro ritmo de trabajo habitual implicando a los desarrolladores en el proceso de diseño desde el primer minuto. ¡Y además en remoto! ¿Quieres saber cómo lo hicimos?

¿Qué es el Design Sprint?

El Design Sprint es una metodología desarrollada en Google por Jake Knapp que permite crear soluciones y validarlas con usuarios reales en solo 5 días. Más que el límite temporal, lo interesante de la metodología es el proceso que se sigue para idear y testear la solución empezando con la detección del problema o necesidad, explorando posibles ideas, seleccionando las que mejor se ajustan, prototipándolas y testeándolas.

Imagen de The Sprint Book

Con esta metodología vimos una gran oportunidad para implicar a todo el equipo definiendo conjuntamente la solución desde 0, hecho que nos resolvía la problemática de hacer a los desarrolladores más partícipes de la solución final.

Dentro de nuestra forma de trabajo PEAK y nuestras rutinas de equipo enfocadas a la entrega continua de valor, no podíamos hacer que todo el equipo se centrara 5 días seguidos (como define la metodología) para obtener el resultado de diseño, pero sí podíamos realizar sesiones con partes del método encajándolas en nuestras dinámicas de equipo y procesos.

Trabajo previo: Set the Stage

Antes de empezar las sesiones de ideación recopilamos toda la información existente sobre el tema y revisamos el mercado en busca de buenas prácticas de la competencia directa o indirecta que nos pudieran ayudar a detectar oportunidades o necesidades no verbalizadas.

A nivel interno recogimos todas las quejas que los usuarios nos habían trasladado en el CSAT y NPS, analizamos las llamadas recibidas a través de Atención al cliente, revisamos los vídeos de interacción grabados en Hotjar para detectar posibles patrones de conducta erróneos e incluso analizamos a nivel cuantitativo el uso.

Y al ser en remoto, toda esta información obtenida de problemas y necesidades la preparamos para que pudiera ser consumida en Miro (herramienta de colaboración online) creando un lienzo para cada una de las sesiones.

Sesión 1: Mapeo de las funcionalidades

Esta fue la primera sesión con todo el equipo y era imprescindible alinearnos. Para ello, no solo debíamos compartir toda la información recopilada, sino que planteamos un ejercicio introductorio para estar todos en la misma página. La idea era definir entre todos cuál era el objetivo del proyecto, qué queríamos conseguir.

Una vez definido el objetivo y revisados todos los insights del discovery, les pedimos a todos los participantes que tradujeran los problemas y necesidades detectadas en How Might We Questions (HMW).

La técnica de preguntas HMW plantea los problemas como oportunidades de diseño y abre la mente para que encontremos diferentes soluciones a ese problema. El hecho de transformar el problema en pregunta estimula al participante a encontrar diferentes vías de resolución ejercitando el pensamiento creativo. ¡Y así fue!

Con los HMW creados realizamos un ejercicio de brainstorming individual de ideas y gracias al intentar extraer soluciones a esas preguntas se pudo llegar a una propuesta mucho más amplia y diversa.

Posteriormente compartimos las ideas y las organizamos por temáticas que se tendrían que solucionar dentro del proyecto. Esta sesión nos sirvió para sentar las bases de lo que sería la solución y lo que pedimos fue buscar ejemplos de cómo la competencia u otros sectores solucionaban las ideas propuestas para llevarlo trabajado para la próxima sesión.

"Una vez introducidos en este tipo de dinámicas y acostumbrados a la herramienta se hace tan ágil y útil como estar todos en la misma sala con post its"

– Alfredo Valenzuela, PO del equipo

Sesión 2: Sketch & Decide

Esta segunda sesión no se realizó el día siguiente como indica la metodología, sino que dimos un tiempo de margen para poder realizar el pre-work planteado. Otro cambio respecto a la metodología de Design Sprint, es que en ella los temas de Sketch y Decide se realizan en dos sesiones separadas y, en nuestro caso, decidimos acortarlo y juntar las dos dinámicas para no dilatar tanto los tiempos dado la complejidad de incorporarlo en el track de delivery.

Así, decidimos realizar un sketch day con el equipo empezando con el pre-work realizado. Para ello, realizamos un ejercicio llamado lightning demos dónde el equipo debía compartir las funcionalidades definidas en la sesión anterior con ejemplos de otras webs del sector o que no tuvieran nada que ver pero que ayudaran a ilustrar la idea. Si no encontraban el ejemplo haciendo benchmark también podían ejemplificar su idea a través de dibujos.

Una vez explicados todos los ejemplos, marcamos aquellas ideas que no habían sido ejemplificadas y decidimos seleccionar las funcionalidades más interesantes. Cada participante disponía de 3 votos y debíamos marcar aquellos 3 ejemplos que nos gustaría incorporar a nuestra solución. Sí, eso os recordará al libro Steal like an artist de Austin Kleon. Sé que no tiene mucho que ver con Design Sprint pero la explicación de este libro nos ayudó a incentivar los buenos criterios de elección de las funcionalidades.

Posteriormente escogimos las ideas que estaban más verdes para darles un poco más de forma y trabajarlas conjuntamente. Para ello, realizamos varios Crazy 8”. En este ejercicio cada participante disponía de un folio Din A-4 que debía doblar en 8 trozos. Debían escoger 1 de las ideas a trabajar y pensar en 8 minutos, 8 posibles soluciones. Una vez finalizado el tiempo debían introducir sus dibujos e ideas en el lienzo del tablero de Miro destinado para ello. Este ejercicio sirvió para ejercitar su mente y exprimir la imaginación con 8 posibles soluciones.

A parte de compartir, en este punto debíamos seleccionar varias ideas de las propuestas (las más viables) para diseñarlas un poco más en profundidad con la metodología de solution sketches. Aquí, no solo era importante el diseño sino que fuera lo más explicativa posible.

“La sesión fue bastante dinámica por lo que se me hizo entretenida, además surgieron muy buenas ideas.”

– Jesús Salas, Backend del equipo

Todo el material generado de la sesión, nos sirvió para plantear dos prototipos del proyecto.

Sesión 3: Prototipado

Aunque en la metodología de Design Sprint los prototipos los realizan todos los miembros conjuntamente, para optimizar el tiempo, decidimos que UX se encargaría de transformar todas las ideas surgidas en dos prototipos navegables. Una vez disponíamos de las dos propuestas las presentamos al equipo.

Esta sesión sirvió para iterar y mejorar en vivo las propuestas con todo el feedback recibido y probar varias ideas que surgieron de la visualización de los prototipos.

Sesión 4.1: Test con stakeholders internos

Antes de testearlo con usuarios reales, decidimos realizar el test con personas de otros departamentos de la empresa como Atención al cliente, comercial,... ya que nos podrían detectar posibles problemas o necesidades de nuestros usuarios dado su estrecha relación con ellos y podríamos llegar al test con los usuarios con un prototipo más consolidado.

Estas validaciones previas nos sirvieron para levantar dudas que les podían surgir también a los usuarios y solucionarlas antes de testearlo con ellos.

Sesión 4.2: Test con usuarios

Finalmente, y como último paso de la metodología testeamos los prototipos navegables en alta fidelidad con usuarios reales. El equipo podía asistir a todas las sesiones y, en caso de no poder, las sesiones se grababan para su posterior visualización. En este punto realizamos test de tareas para intentar que la experiencia fuera lo más real posible y lo combinamos también con entrevista para entender el uso real de las funcionalidades existentes.

Una vez realizadas las entrevistas se presentaron las conclusiones al equipo con visionado de clips de videos de los momentos más relevantes.

Retos y aprendizajes

Después de llevar a cabo todo el proceso del Design Sprint adaptando los ejercicios a nuestras rutinas de trabajo podemos decir que el feedback del equipo fue muy positivo y se sintieron partícipes de la solución realizada.

“De las dinámicas me ha gustado el hecho de aportar en el diseño y escuchar los puntos de vista de todos"

– Antonio Asenjo, Backend del equipo

Además, también destacan la gran cantidad y calidad de las ideas surgidas dado los diferentes puntos de vista.

“Me pareció muy interesante ya que salieron muchas buenas ideas, y me permitió enfocarlo desde otro punto de vista, más allá del punto de vista técnico”

– Emilio Villuendas, Frontend del equipo

Eso sí, si nos centramos en los retos, podemos decir que no pudimos hacer un Design Sprint al uso en 5 días consecutivos ya que debíamos combinar esta preparación de lo próximo con el día a día y la entrega de valor continúa.

A modo de recomendación, si queréis realizar una sesión de este tipo es necesario analizar el objetivo: ¿se quiere un cambio radical o únicamente queremos cambiar una funcionalidad? Si el objetivo es realizar un proyecto o una construcción de un bloque con varias funcionalidades, esta dinámica te será muy útil. Por lo contrario, si lo que queremos es mover métricas rápidamente o iterar una funcionalidad en específico hay otro tipo de dinámicas más adecuadas para ello.