El patrón era siempre el mismo en Foris: el equipo diseñaba, desarrollaba, y cuando la feature estaba casi lista, negocio detectaba un caso de uso que nadie había considerado. Vuelta atrás. Rediseño. Más tiempo, más costo, más fricción.
El problema no era falta de intención, era falta de proceso. Nadie tenía tiempo de documentar todos los casos de uso antes de empezar, y hacerlo manualmente tomaba horas. La solución tenía que ser rápida o nadie la iba a adoptar.
Los designers del equipo sabían que documentar casos de uso era importante. Pero entre el backlog, las reuniones y los deadlines, documentar tres horas antes de codificar no era una opción real. El proceso que diseñamos tenía que encajar en el tiempo que el equipo ya tenía.
El flujo que diseñamos funciona así: el designer alimenta a Claude con el contexto del producto, qué hace, quién lo usa, qué restricciones existen, y con la descripción del feature o historia de usuario. Claude genera el mapa de casos de uso con edge cases, estados de error y preguntas de validación.
El total del proceso: menos de 20 minutos para un caso de uso que antes tomaba entre dos y tres horas, cuando se documentaba.
El output no es texto libre. Es una estructura estándar que todos los actores del proceso entienden sin explicación: flujo principal, flujos alternativos, edge cases, preguntas abiertas para validación y criterios de aceptación.
El documento estándar, flujo principal, alternativas, edge cases y preguntas de validación
El flujo se activa en un momento específico: cuando una historia de usuario entra al refinamiento. No antes, el contexto no está listo. No después, el costo de iterar es mayor.
El designer es el owner del proceso. Producto valida antes de que el caso entre al sprint. Negocio tiene una ventana de revisión antes del desarrollo. Si negocio detecta un gap, lo detecta en el documento, no en el producto terminado.
Desde que el flujo está activo en Foris, los llamados de negocio por gaps en producción cayeron significativamente. El equipo de diseño documenta más porque el proceso no se siente como carga. Y el tiempo ahorrado en iteraciones tardías se reinvierte en investigación y calidad de diseño.