Redefiniendo el Handoff: Mi Way of Work en la Era de los Sistemas Agénticos
Un cambio de paradigma para el workflow de un diseñador de producto implica también avanzar en mecanismos para transferir conocimiento multidisciplinar y generar una base de conocimiento documental del proceso. Así cómo tradicionalmente se entregan flujos de usuario o documentaciones acotadas por paths en la experiencia, los sistemas agenticos también tienen artefactos que agilizan y mejoran la profundidad del handoff.

Por qué seguir haciendo handoff
La premisa fundamental para mantener el handoff es que el núcleo del proceso de diseño no ha cambiado; lo que se ha transformado es la profundidad que nos otorgan las herramientas. Hoy, la línea entre diseño y código se está disolviendo. La orquestación de sistemas agénticos nos permite explorar soluciones técnicas complejas sin abandonar el flujo de diseño, revelando hallazgos clave directamente sobre el código del producto.
Sin embargo, durante mis primeras iteraciones descubrí un problema recurrente: todo ese rico contexto —esencial para el discovery y la definición— se perdía al cerrar la sesión. Decisiones cruciales, que iban desde pequeños ajustes en los tokens del sistema de diseño hasta cambios estructurales en el backend, quedaban atrapadas en mi mente o dispersas en la memoria efímera del agente.
Para resolver esto, diseñé y adopté un Way of Work nativo con inteligencia artificial. Este proceso me permite orquestar y documentar cada decisión, sin delegar tareas críticas ni permitir que los agentes tomen rumbos desalineados con la intención original de diseño.
Brief setup
Sistema de agentes para diseñar
~/.claude/skills/simetrik-ui/
│
├── SKILL.md ← entrada del skill: leyes raíz + routing
│
├── agents/ ← el equipo de diseño
│ ├── UXTEAM-PROTOCOL.md ← cómo trabajan juntos
│ ├── design-product-designer.md ← rol del PD
│ ├── design-ux-research.md ← rol del UXR
│ ├── design-ux-writer.md ← rol del UXW
│ ├── ROSSETA.md ← cómo el LEAD navega el Brain
│ └── templates/
│ └── design-brief.md ← schema canónico del Brief
│
├── component-rules/ ← 60 archivos, uno por componente de sistema de diseño
│
├── subcommands/ ← 24 subcomandos del skill
│ ├── teach.md ← verificación del entorno
│ ├── shape.md, craft.md, ... ← Build
│ ├── critique.md, audit.md ← Evaluate
│ ├── polish.md, bolder.md, ... ← Refine
│ ├── animate.md, colorize.md, ... ← Enhance
│ └── clarify.md, adapt.md, ... ← Fix
│
└── laws/
├── design-laws.md
├── navigation-pattern.md
├── overlay-decision-tree.md
├── ai-integration-patterns.md
├── form-fundamentals.md
└── motion-canon.mdProduct Brain

Artefactos
/.claude/design-team/
briefs/ → Design Brief
research/ → Research Snapshots
copy/ → Copy Specs
implementation/ → Síntesis pre-implementación
output/ → Código
qa/ → QA Reports
feedback/ → Pendientes de ciclos anterioresEl Proceso: Orquestación e Implementación
1. Setup y Construcción del Objetivo
[Contexto] --> apuntar a una tarea registrada en brain y MS
[Reglas y parámetros]
[Objetivo]
**sin ejecución solo contextualización**Antes de iniciar cualquier sesión de diseño con agentes, establezco un intro-prompting estructurado que define el objetivo del proyecto. A lo largo de varias iteraciones, comprobé que esta estructura inicial me otorga la flexibilidad necesaria para descubrir información complementaria y enriquecer mi visión, sincronizándola con el Product Brain (el conocimiento central generado por el equipo de producto).
Generación de plan de trabajo
[Contexto de FE]
[Contexto de BE]Este plan de trabajo inicial es el ancla que permite estructurar el proyecto, diagnosticar posibles brechas tecnológicas (gaps con el backend) e identificar dónde residen las funcionalidades actuales. Sin este paso, el handoff final carecería de la trazabilidad necesaria para documentar las decisiones clave del proyecto.
2. El Prototipo (HTML antes que código funcional)
Aunque los sistemas agénticos nos permiten generar código funcional directo a producción, caer en esa tentación es un error común en el que solemos tropezar. He comprobado que iterar primero sobre un prototipo en HTML resuelve retos fundamentales del flujo de trabajo:
Enfoque absoluto en UX: Antes de pulir la UI, aseguramos que la experiencia logre el output y outcome esperado, eliminando sesgos prematuros de estética o usabilidad.
Pruebas de Concepto veloces: Permite recolectar feedback temprano de stakeholders, desarrolladores y personas usuarias. Es la forma más segura de iterar y reorientar la solución sin generar deuda técnica ni "código sucio" que ponga en riesgo la funcionalidad.
Velocidad de construcción: Utilizando el contexto del UX Research y los requerimientos de producto, construimos rápidamente una interfaz espejo, integrando comportamientos esperados y contenido dinámico curado por agentes de UX Writing.
Control de Versiones y Trazabilidad (Git): Desplegar mediante un repositorio no solo facilita compartir un enlace funcional, sino que convierte el espacio en una bóveda para todos los artefactos: planes, especificaciones, decisiones e insights de investigación. Esto escala el proceso y hace que los comentarios del equipo sean completamente trazables.
Resolución de Microinteracciones: Tradicionalmente, prototipar pantalla por pantalla y traducir esos comportamientos al lenguaje de desarrollo tomaba demasiado tiempo. El prototipo HTML autodocumenta estas interacciones de forma nativa, garantizando la consistencia completa de la experiencia.
3. Entrega de Specs Drivers
El mayor desafío al diseñar con IA es condensar el gran volumen de decisiones tomadas durante múltiples sesiones y compactaciones de contexto. Para asegurar que el historial de especificaciones quede registrado de manera impecable, implementé dos estrategias:
Autodocumentación en código: El prototipo HTML incluye comentarios estructurados que los agentes generan automáticamente, documentando el "cómo" y el "por qué" se agregó cada elemento.
Árbol de decisiones: El plan inicial evoluciona hasta convertirse en un mapa detallado del proceso, integrando datos de investigación, especificaciones técnicas, objetivos de frontend y brechas de backend.
Finalmente, utilizando subcomandos que invocan skills específicos de handoff, el sistema recolecta toda la información de cada uno de los specs.
# Handoff — <feature-name>
Fecha: <ISO>
Origen: <prototype.html | módulo | descripción | epic ID>
Patrón de presentación: <tabla | cards | kanban | split-pane | ...>
## 1. Contexto y objetivo
<resumen del discovery + decisión de patrón>
## 2. Usuario y registro
<producto vs interno, perfil, modo de uso>
## 3. Historias de usuario
<delegado a ux-user-stories y Experience-Driven User Story>
## 4. Arquitectura de componentes de UI
<lista con imports, props, composición>
## 5. Estados
- Loading
- Empty
- Error
- Partial data
- Success
## 6. Copy completo (glosario aplicado)
<delegado a ux-writer>
## 7. Microinteracciones
<duraciones, curvas, qué animar>
## 8. AI integration
<AI summary, suggestions, AiChat patterns>
## 9. Endpoints esperados
<lista de APIs, formato, ejemplos>
## 10. Edge cases y validaciones
## 11. Test cases sugeridos
## 12. Tokens utilizados
## 13. Checklist pre-PR
- [ ] Componentes UI usados (no custom innecesarios)
- [ ] Glosario aplicado en todos los strings
- [ ] Estados completos
- [ ] Microinteracciones canon
- [ ] Mode consistente
- [ ] A11y: focus, aria-label, contrast
- [ ] Tests del happy path + 2 edge cases

El resultado es un proyecto completamente empaquetado para su implementación, respaldado por documentación técnica profunda que actúa como contexto vital. Esto demuestra que los rituales tradicionales de "entrega" siguen siendo esenciales para la transferencia humana de información, pero ahora están potenciados por un repositorio vivo que contiene todo el ADN y las instrucciones de la experiencia.
