Redlines y anotaciones: especificar sin ambigüedad
Los redlines anotan un diseño con medidas, espaciados, colores y comportamiento para que se construya tal como se diseñó. Qué incluir y cómo organizarlos.
¿Qué es y para qué sirve?
En diseño de producto, el término describe las anotaciones que acompañan a un diseño cuando pasa a desarrollo. Figma las llama anotaciones y medidas; Zeplin habla de instrucciones siempre visibles que se fijan directamente sobre la pantalla; y un artículo de Adobe de 2017 describe «Design Specs», una función de Adobe XD que publicaba medidas, colores y tipografía en un enlace para que el equipo de desarrollo los consultara sin pedírselos al diseñador.
Sirve para cerrar la brecha entre dos personas que miran el mismo diseño con información distinta. El diseñador sabe por qué el espaciado es de 24 píxeles. El desarrollador solo ve un rectángulo. Sin anotaciones, el desarrollador decide, y su decisión rara vez coincide con la del diseñador.
¿Qué debe incluir?
Zeplin plantea que el handoff va más allá de colores, espaciado, tipografía y medidas: incluye la intención de diseño, el contexto de los flujos y el comportamiento. Figma recomienda destacar las propiedades importantes para que los desarrolladores no las pasen por alto, y ofrece categorías predefinidas para las anotaciones: desarrollo, interacción, accesibilidad y contenido. Según su documentación, añadir medidas y anotaciones requiere un plan de pago (Professional, Education, Organization, Government o Enterprise), un asiento completo y acceso de edición al archivo.
Una lista práctica para revisar antes de entregar:
- Medidas y espaciados entre elementos, con los valores que usará el código.
- Colores y tipografía con su nombre de token, no solo el valor en hexadecimal.
- Estados: vacío, cargando, error, deshabilitado, hover y foco. Un redline que solo muestra el estado por defecto deja al desarrollador a ciegas en los demás.
- Comportamiento: qué pasa al hacer clic, al escribir, al perder el foco, en qué orden se mueve el foco con el teclado.
- Reglas responsivas: cómo se comporta el diseño en cada tamaño, qué se oculta, qué se apila.
- Accesibilidad: orden de lectura, texto alternativo, nombres de componentes, relación con la guía de estados de error cuando aplique.
- Contenido: textos reales, longitudes máximas, qué pasa si el texto no cabe.
Y lo que no debe incluir: decisiones que aún no están cerradas. Un redline sobre un diseño en revisión es un costo de mantenimiento que nadie quiere pagar.
¿Cómo se organiza?
Los redlines funcionan mejor cuando cada pantalla tiene su propia capa de anotaciones y las anotaciones se refieren a componentes, no a píxeles sueltos. Si el botón primario aparece en cuarenta pantallas, su especificación vive en el componente y las pantallas solo la referencian.
La regla práctica es anotar la intención, no solo la apariencia. “Espaciado de 16 píxeles” es una medida. “Espaciado entre la etiqueta y el campo, para que la lectura agrupe ambos” es una intención, y ayuda al desarrollador a decidir qué hacer si el texto de la etiqueta se hace dos líneas.
En su artículo sobre especificaciones de diseño de 2017, Nick Babich recomienda en el blog de Adobe mantener las especificaciones al día, dar a cada pantalla un nombre que indique su función e involucrar al equipo de desarrollo desde el principio. Figma añade que los desarrolladores ven las anotaciones actualizarse en tiempo real en Dev Mode. Esa sincronización es valiosa, pero solo si alguien mantiene las anotaciones vivas.
Tokens, no valores sueltos
Si quieres ver cómo se entrega el paquete completo, revisa el proceso de design handoff y las especificaciones de diseño. Un redline es solo una parte.
Un redline con valores fijos (#2563eb, 16px) se vuelve obsoleto en cuanto cambia la paleta. Un redline con tokens (color.action.default, space.md) se mantiene verdadero aunque cambien los valores, porque el token apunta al lugar correcto. Por eso conviene que las anotaciones usen los mismos nombres que el sistema de tokens. Si tu equipo aún no tiene tokens, al menos documenta las equivalencias entre valores y nombres.
¿Cuándo NO conviene hacer redlines?
- Cuando el equipo de desarrollo trabaja en la misma sala y la conversación es constante. Un redline pesado puede ser un trámite inútil.
- Cuando el diseño cambia cada día. Anotar un prototipo en exploración es perder tiempo.
- Cuando el componente ya está en el sistema de diseño. Basta con referenciar el componente y anotar solo lo que es nuevo.
- Cuando se usan como sustituto de la conversación. Un redline no reemplaza a la persona que puede responder una pregunta.
Ejemplo
Ejemplo ilustrativo: un equipo diseña una tarjeta de pago con tres estados: normal, error de saldo y cargando. El redline tiene el espaciado entre componentes con nombre de token, el color de error con su token semántico y el comportamiento del botón en cada estado. Además, indica qué pasa si el nombre del comercio supera dos líneas: se trunca con puntos suspensivos y el texto completo aparece al mantener pulsado. Al revisar la implementación, el equipo descubre que el estado de carga no tenía especificación. Lo añade antes del lanzamiento, no después.
Para tu próximo handoff: revisa una pantalla y cuenta cuántos estados tiene. Si el redline solo muestra uno, agrega los que faltan y pregúntale a un desarrollador qué le falta.
Errores comunes
- Anotar solo el estado por defecto.
- Usar valores fijos en lugar de tokens.
- Anotar decisiones que aún no están cerradas.
- Dejar el handoff para el final, cuando el desarrollo ya empezó.
- Anotar píxeles en vez de componentes y su comportamiento.
- No mantener las anotaciones cuando cambia el diseño.
- Llenar la pantalla de notas que nadie lee. Como regla práctica, no como norma: si un bloque lleva más de cinco o seis anotaciones, probablemente falte un componente en el sistema.