He estado en ambos lados del handoff durante más de una década. He escrito briefs como diseñador y los he recibido como desarrollador. La brecha entre lo que la mayoría de los diseñadores escriben y lo que los desarrolladores necesitan para construir correctamente no se debe a que los desarrolladores no les importe el diseño. El brief está optimizado para el lector equivocado.
Para Qué Sirve Realmente un Brief
Un brief existe para darle al desarrollador todo lo que necesita para implementar el feature correctamente sin agendar una reunión de seguimiento. Cada sección que no sirve a ese propósito es ruido que reduce la probabilidad de que el desarrollador lea el documento en absoluto. Dejé de asistir a handoffs de revisión de diseño que realmente eran showcases del proceso de diseño. Los que bloqueaba en mi agenda eran aquellos donde el autor había pensado claramente en lo que yo necesitaría para no volver con preguntas.
Las Cinco Secciones Que Importan
- 1. Spec de comportamiento: qué pasa cuando el usuario hace X, no cómo se ve, qué hace. Cubre cada estado interactivo: hover, focus, active, disabled, loading.
- 2. Edge cases y estados de error: estados vacíos, estados de carga, estados de error de API, mensajes de validación. Estas son las partes que los desarrolladores inventarán si no las especificas. Los estados inventados son estados inconsistentes.
- 3. Comportamiento responsive: breakpoints exactos, qué cambia en el layout en cada breakpoint, qué elementos se reordenan o colapsan, no 'mobile-friendly', específico.
- 4. Inventario de componentes: qué componentes existentes se usan, cuáles son nuevos, nombres exactos de componentes en Figma que coincidan con nombres de componentes Angular.
- 5. Fuera de alcance: lista explícitamente lo que NO está en esta implementación. Esto previene scope creep y crea un registro compartido para futuras decisiones.
Los Estados de Error No Son Negociables en Productos Financieros
En un producto financiero, los mensajes de error no son pulido de UX. Un mensaje de fallo de pago demasiado vago se convierte en una llamada al soporte en vez de en un reintento. Una advertencia de sobregiro ambigua genera volumen en el call center. Cuando lideré la UX de la PWA de tarjeta de crédito en Wonderlabs, especifiqué cada estado de error, la copia exacta y la condición de disparo, e hice lo mismo en el rediseño de la plataforma IRIS en Strongest Families, donde lo que estaba en juego era distinto pero la disciplina era idéntica. Si el brief no tiene esta tabla, la implementación tendrá mensajes de error inventados. La tabla de abajo está escrita para este post. Es una ilustración, no una spec de ningún producto en el que haya trabajado.
## Error States: Transfer Form (illustrative)
| State | Trigger | Message | Component |
|-------|---------|---------|----------|
| Required field empty | Submit with empty field | "This field is required" | FormFieldError |
| Amount exceeds balance | amount > accountBalance | "Insufficient funds. Your available balance is $X.XX" | FormFieldError |
| API timeout | Response > 30s | "Something went wrong. Please try again." | InlineAlert (warning) |
| Daily limit exceeded | amount > dailyTransferLimit | "You've reached your daily transfer limit of $X,XXX" | InlineAlert (warning) |
| Invalid recipient account | 422 from API | "We couldn't find an account with that number. Check the details and try again." | FormFieldError |El Comportamiento Responsive Requiere Especificidad
Decir 'mobile-friendly' en un brief no es una especificación. Especifica los breakpoints para los que estás diseñando. Asegúrate de que coincidan con los breakpoints definidos en tus design tokens. Documenta qué cambia en el layout en cada uno y qué interacciones cambian. Una sidebar que colapsa a un bottom sheet a 768px necesita estar por escrito, no visible en los frames de Figma solo si sabes dónde mirar. Un desarrollador trabajando desde un brief no debería necesitar hacer ingeniería inversa del comportamiento responsive comparando frames.
Así se ve para un ejemplo inventado, una card de resumen de estado de cuenta en una app de tarjeta de crédito. Ninguno de los valores de abajo viene de un producto real. A 1280px y más, la card se renderiza en un grid de dos columnas con los detalles de la cuenta a la izquierda y los botones de acción apilados a la derecha. Por debajo de 1280px el layout cambia a una sola columna: los botones de acción se mueven debajo de los detalles, y la card va de borde a borde con 16px de padding horizontal. A 375px y menos la card elimina la acción secundaria por completo. El enlace 'Ver historial' se oculta y es accesible solo a través de la página de detalle de la cuenta. Esa decisión necesita estar en el brief. Un desarrollador que no la vea renderizará el enlace de todas formas y romperá el layout, o lo eliminará globalmente y romperá desktop.
## Responsive Behavior: Statement Summary Card (illustrative)
| Breakpoint | Layout | Changes |
|------------|--------|---------|
| >= 1280px | 2-column grid | Account details left, actions right |
| 376px to 1279px | 1-column stack | Actions move below details, edge-to-edge card, 16px horizontal padding |
| <= 375px | 1-column, reduced | Hide 'View history' link |Nomenclatura de Componentes Que Conecta Ambos Mundos
Impulso la alineación de nombres de componentes de Figma con nombres de componentes Angular antes de escribir cualquier brief. Si el componente de Figma se llama 'Pill/Status/Success' y el componente Angular es StatusBadge, cada brief que referencia ese componente crea un problema de traducción. La nomenclatura inconsistente se compone a lo largo de un equipo hasta que los handoffs requieren un glosario.
La convención que uso: PascalCase, sustantivo primero, específico sobre genérico. No 'Card' cuando 'StatementSummaryCard' es lo que quieres decir. No 'Dialog' cuando 'ConfirmTransferDialog' es lo que quieres decir. Los nombres genéricos en Figma se convierten en referencias ambiguas en briefs que se convierten en elecciones de componentes equivocadas en Angular. La sesión de alineación de nomenclatura es una sola reunión. Se paga sola la primera vez que un brief nombra un componente y nadie tiene que preguntar cuál es.
Un brief no está terminado cuando todos los happy paths están documentados. Está terminado cuando cada estado que un usuario podría encontrar tiene un comportamiento especificado.
El Formato Importa Más de Lo Que Piensas
Mantén el brief corto. Usa tablas para estados. Usa links de Figma anotados que vayan directamente al frame relevante, no a la raíz del archivo. Si el documento es más largo de cuatro páginas, probablemente has incluido cosas que deberían estar en el ticket de Jira o en el archivo de diseño. Los desarrolladores tienen contexto del planning y refinamiento de historias. El brief llena las brechas de implementación en ese contexto. No reemplaza todos los demás documentos.
Un link de Figma que apunta a la raíz del archivo fuerza al desarrollador a navegar al frame correcto por su cuenta. En un archivo grande eso es un desvío, y ocurre cada vez que consultan el brief. Enlaza directamente al frame. Usa el 'Copy link to selection' de Figma (clic derecho en el frame, después Copy/Paste as) en cada frame que refieras. Si estás referenciando una variante específica de componente, selecciona esa variante y copia su link. Esto te cuesta unos pocos segundos por link. Le ahorra al desarrollador minutos por sesión y elimina la fricción ambiental que hace que la gente deje de abrir el brief.
Los briefs que se leen son los que tratan el tiempo del desarrollador como valioso. Cortos, estructurados, completos en estados y comportamiento, con links directos de Figma. Los que no se leen son los que documentan el proceso de pensamiento de diseño para una audiencia que no estuvo en el design review. Conoce a tu lector.
Aquí está la diferencia en una sola vista. Los nombres de componentes y endpoints de abajo son inventados para este post.
Referencias
- Figma developer handoff guide. https://www.figma.com/best-practices/guide-to-developer-handoff/
- WCAG 2.2 Understanding SC 3.3.1 Error Identification. https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html
- WCAG 2.2 Understanding SC 3.3.3 Error Suggestion. https://www.w3.org/WAI/WCAG22/Understanding/error-suggestion.html