El día que documentamos el proceso y dejamos de hacer las mismas preguntas
Recuerdo exactamente el momento en que le pregunté a un equipo de diseño con el que estaba trabajando cuál era su proceso de diseño. Eran 6 diseñadores, llevaban juntos más de un año.
La respuesta fue interesante. No porque dijeran algo malo. Sino porque cada persona del equipo describió un proceso diferente.
El más junior decía que hacía research, luego wireframes, luego el diseño final. El Senior decía que primero entendía el problema con producto y luego diseñaba. El Lead decía que dependía del proyecto. Y el manager asumía que tenían un proceso estándar porque nunca había habido un problema visible.
No era caos. Era cada persona trabajando bien, a su manera, sin que nadie hubiera acordado nunca qué significaba trabajar bien en ese equipo.
¿Sabes lo que pasaba? Que los nuevos que llegaban al equipo tardaban dos meses en entender cómo se trabajaba realmente. Que las handoffs a desarrollo tenían calidades muy distintas según quién las hacía. Y que en la retrospectiva de cada proyecto, siempre salían los mismos problemas.
Documentar el proceso no es burocracia, es memoria colectiva
La resistencia más frecuente que escucho cuando propongo documentar el proceso de diseño es "eso nos va a encorsetar, vamos a perder flexibilidad".
La realidad es que sin proceso documentado no hay flexibilidad. Hay improvisación. Y la improvisación tiene un coste alto que nunca aparece en ningún dashboard: el coste de tener que reconstruir el contexto desde cero en cada proyecto, de resolver cada vez los mismos conflictos sobre quién decide qué, de no poder onboardear a nadie sin que alguien del equipo pierda tiempo explicando lo que debería estar escrito.
Documentar el proceso no limita cómo trabaja el equipo. Define la base desde la que el equipo puede tomar decisiones conscientes sobre cómo quiere trabajar.
Cuando el proceso está escrito, las desviaciones dejan de ser ruido y se convierten en señales: "no seguimos el proceso de validación porque había una razón concreta". Eso es mucho más valioso que no saber nunca si se siguió o no.
Las cinco etapas que todo proceso de diseño tiene
El proceso de diseño de producto puede describirse en cinco etapas. Los nombres cambian según el equipo, pero las etapas son siempre las mismas:
Discovery: entender el problema antes de diseñar. Entrevistas con usuarios, revisión de analítica, benchmarking. El output es un problem statement que el equipo puede compartir con producto.
Define: acotar el alcance y alinear con los stakeholders. Qué entra en este proyecto y qué no. Cuáles son las métricas de éxito. El output es un brief de diseño acordado.
Design: generar y refinar la solución. Exploración de conceptos, design reviews internas, prototipo de alta fidelidad con todos los estados. No solo el happy path.
Validar: confirmar que la solución funciona antes de desarrollar. Tests con usuarios, revisión de accesibilidad, iteración si es necesario. El output es un diseño aprobado.
Handoff: entregar a desarrollo con toda la información necesaria. Walkthrough del diseño, documentación de edge cases, design QA durante la implementación.
Cada etapa tiene actividades, herramientas y entregables. Y cada etapa tiene un responsable claro.
El Process Map Builder
Para documentar ese proceso sin tener que construirlo desde cero, el Process Map Builder te da las cinco etapas preconfiguradas con actividades, herramientas y outputs de referencia. Puedes editar cada campo, añadir o eliminar actividades, cambiar los responsables y las herramientas que usa tu equipo.
Cuando lo hayas adaptado a tu contexto, exportas como Markdown con la versión y el nombre del equipo. Ese archivo va al Notion del equipo, al Confluence o donde quiera que tengáis la documentación interna.
La primera vez que lo documentéis va a tardar una hora. A partir de ahí, actualizar una etapa cuando el proceso cambia tarda diez minutos.
Y los nuevos que lleguen al equipo van a dejar de preguntar las mismas cosas. Porque las respuestas van a estar escritas.
Pues eso.