Respuesta breve
Una entrega de diseño no deja nada a la suposición cuando, además de las pantallas, fija siete cosas: qué marcos son definitivos y en qué versión, todos los estados de cada componente, con errores y pantallas vacías, los tokens de diseño que hay detrás de los valores, cómo se comportan las composiciones entre tamaños, las reglas para el contenido real, los recursos con sus licencias y los criterios de aceptación de cada pantalla. Las preguntas pasan por un único canal y cada respuesta vuelve al archivo.
Cada hueco de la entrega acaba en una decisión de quien no debía tomarla
Un archivo de diseño responde a las preguntas que se le ocurrieron a su autor. Producción hace las demás: cómo se ve este botón mientras se procesa el pago, qué le pasa a la tarjeta cuando el nombre tiene cuarenta caracteres, qué gris es este. Si el archivo calla, decide el desarrollador, solo y con un plazo encima, y esa decisión se publica.
No hay descuido por ninguna de las dos partes. Una maqueta muestra un momento de la interfaz con contenido ideal, y una interfaz son cientos de momentos con contenido real. La distancia entre ambas es la entrega, y se cubre con una regla escrita o con una suposición. Suponer es barato y encontrar después la suposición es caro.
Una entrega de diseño a desarrollo que no deja nada a la suposición contiene, además de las pantallas, siete cosas: un estatus para cada marco, todos los estados y casos límite, los tokens, las reglas adaptables, las reglas de contenido, los recursos con sus licencias y los criterios de aceptación. Una octava las mantiene unidas: un único lugar donde se pregunta y se responde.
Marque qué está terminado y qué versión es
Lo primero que un desarrollador tiene que suponer es si un marco es definitivo. Los archivos guardan exploraciones, variantes descartadas e ideas a medias junto al trabajo aprobado, y todo parece igual de real. Indique el alcance con palabras: una lista de las pantallas y los componentes de esta versión y un estatus visible en cada uno.
Las herramientas de diseño ya lo permiten directamente. La documentación de Figma describe Dev Mode como un espacio de trabajo para inspeccionar diseños, comparar cambios y gestionar la entrega; los marcos, componentes y secciones pueden marcarse como «Ready for dev», y la versión actual de un marco puede compararse con las anteriores. Sea cual sea la herramienta, el principio es el mismo.
Un estatus es una promesa, así que lo que cambie después se trata como un cambio. Si se edita un marco aprobado, deje al lado una nota breve y fechada con lo que ha cambiado y por qué, y avise a quienes lo están construyendo. Una corrección silenciosa en una pantalla «lista» es la vía por la que llegan a producción dos versiones del mismo componente.
Dibuje cada estado y después los casos incómodos
Un componente no es una sola imagen. Las especificaciones de Material Design agrupan los tokens de un componente primero por estado, «enabled, disabled, hover, etc», es decir, habilitado, deshabilitado, cursor encima y demás, y solo después por elemento; es un buen modelo para una entrega. De cada componente interactivo muestre el estado normal, el cursor encima, el foco de teclado, el pulsado y el deshabilitado, y de todo lo que espera datos, también la carga, el éxito y el error.
Después diseñe los casos que nadie pone en una presentación. La lista vacía antes de que exista el primer elemento. La búsqueda sin resultados. El nombre tres veces más largo que el de la muestra, la foto que no ha cargado, la tabla con una fila y con mil. El usuario que no tiene permiso y el que navega con una conexión lenta.
Una tabla de estados lo hace manejable: los componentes en vertical, los estados en horizontal y un enlace o una nota en cada celda. Una celda vacía es una pregunta que alguien hará en mitad de un sprint. «Igual que el estado normal» es una respuesta legítima; simplemente tiene que escribirla el diseñador y no darla por supuesta el desarrollador.
Los tokens convierten valores copiados en decisiones con nombre
Material Design define los tokens de diseño como decisiones de diseño pequeñas y reutilizables que componen el estilo visual de un sistema y sustituyen los valores estáticos por nombres que se explican solos. Su documentación incluye el argumento a favor de la entrega: cuando la maqueta del diseñador y la implementación del ingeniero remiten al mismo token, ambos pueden confiar en que se usa el mismo color, aunque su valor hexadecimal se actualice más tarde.
Ahora existe un formato de archivo común para ellos. El Design Tokens Community Group publicó en octubre de 2025 el Design Tokens Format Module 2025.10 como informe estable; el propio documento advierte de que no es un estándar del W3C. Los tokens se guardan en JSON, cada uno con un valor y un tipo y, de forma opcional, una descripción de su finalidad, y un token puede ser un alias que apunta a otro token.
Para una entrega, el mínimo práctico es una tabla o un archivo de tokens de color, tipografía, espaciado, radios, sombras y movimiento, con nombres que digan para qué sirve un valor y no qué aspecto tiene. Las tres clases de Material son un buen patrón: tokens de referencia para los valores en bruto disponibles, de sistema para los roles y de componente para las partes de un componente. Todo lo que en el archivo no use un token debería marcarse como una excepción deliberada.
El comportamiento adaptable es un conjunto de reglas, no tres capturas
Tres mesas de trabajo, para móvil, tableta y escritorio, describen tres anchos de entre miles. Lo que producción necesita es el comportamiento entre ellos: qué elementos se estiran, cuáles mantienen un tamaño fijo, cuáles saltan a una línea nueva, cuáles se apilan, cuáles desaparecen y en qué orden. Escríbalo como reglas ligadas a la composición, con anchos mínimos y máximos donde existan.
Indique dónde cambia la composición y por qué. Un punto de ruptura es útil cuando está ligado al contenido, por ejemplo al ancho en el que la navegación deja de caber en una línea, y arbitrario cuando se copia de una lista de dispositivos. Diga también qué permanece constante: el ancho de lectura del texto, el tamaño de las zonas táctiles, la escala de espaciado.
El ancho es solo una condición. La documentación de tokens de Material Design enumera otras con el nombre de contextos: factores de forma de los dispositivos, tema oscuro, composiciones densas y sistemas de escritura de derecha a izquierda. Una entrega debería decir cuáles admite el producto en esta versión y mostrar al menos una pantalla clave en cada uno, para que el resto pueda deducirse de los tokens y las reglas.
Reglas de contenido: texto real, límites y lo que ocurre al superarlos
El texto de relleno esconde la mayoría de los problemas de composición. Entregue textos reales para cada pantalla, incluidos los rótulos de los botones, los mensajes de error, los estados vacíos y los correos de confirmación, escritos o aprobados por quien sea responsable de las palabras. Un desarrollador que tiene que inventar un mensaje de error lo escribirá, y llegará a los usuarios.
Para cada elemento de texto que se rellena con datos, dé la regla: la longitud prevista, la máxima y lo que ocurre al superarla, si el texto salta de línea, se trunca con una forma de ver el resto o se reduce. Haga lo mismo con las imágenes: la proporción, cómo se recortan y qué se muestra cuando no hay ninguna.
Añada los formatos que cambian según el idioma y la región: fechas, horas, números, moneda y plurales. Si el producto se va a traducir, pruebe la composición con el idioma más largo que piense admitir y con uno de derecha a izquierda si procede. Y dé a cada imagen con significado su alternativa textual ya en la entrega, porque también es contenido que alguien tiene que escribir.
Los recursos y las licencias viajan con el archivo
Tampoco le corresponde al desarrollador adivinar cómo se exportan los recursos. Enumere lo que hace falta y en qué formato: archivos vectoriales para iconos y logotipos, imágenes de mapa de bits en los tamaños y densidades que usa el producto, y vídeos y animaciones con sus ajustes. Dev Mode de Figma, por ejemplo, permite descargar recursos y exportar capas en PNG, JPG, SVG o PDF; aun así, alguien tiene que decir cuáles.
Los nombres importan más de lo que parece. Un patrón de nombres coherente, que coincida con los nombres del código, ahorra a todos una tabla de equivalencias, y una única carpeta o biblioteca acordada ahorra la pregunta de qué logotipo es el vigente. Conserve con la entrega los originales a resolución completa y no solo las exportaciones comprimidas.
Después, las licencias. De cada tipografía indique qué licencia cubre su uso en la web o en una aplicación y a nombre de quién está. Haga lo mismo con las fotografías de banco de imágenes, las ilustraciones, los conjuntos de iconos y la música. Una maqueta puede montarse con una tipografía de prueba o con una vista previa con marca de agua; el producto publicado necesita la licencia real, y el desarrollador no puede saber cuál es cuál si la entrega no lo dice.
Criterios de aceptación y un único canal para las preguntas
El Service Manual del Gobierno británico describe los criterios de aceptación como una lista de resultados que se usa a modo de lista de comprobación para confirmar que un servicio ha hecho su trabajo y responde a la necesidad del usuario, a menudo redactada como una lista que empieza por «it’s done when…», «está hecho cuando…». El mismo recurso sirve para una pantalla: está hecha cuando se han construido todos los estados de la tabla, los tokens coinciden, las reglas de composición se cumplen con cualquier ancho y el contenido real cabe.
Escriba los criterios antes de que empiece el desarrollo y revise la compilación con ellos, en dispositivos reales y con el diseñador presente. Así la revisión de diseño deja de ser una cuestión de gusto y pasa a ser una comparación con una lista, y el desarrollador tiene algo que comprobar antes de pedir la revisión.
Por último, elija un único canal para las preguntas e indíquelo en la entrega. Una pregunta hecha en un chat, resuelta en una llamada y recordada por dos personas está perdida para todos los demás. Mantenga las preguntas junto al diseño, como comentarios o anotaciones sobre el marco, nombre a la persona que responde y en qué plazo, y escriba cada respuesta de nuevo en el archivo como una regla. El siguiente proyecto empezará así con menos huecos.
Lista práctica
- Marque con un estatus cada marco incluido en el alcance y anote cada cambio hecho después de darlo por listo.
- Rellene una tabla de estados para cada componente, con la carga, el error, el vacío y la falta de permisos.
- Entregue los tokens como archivo o tabla con nombres según su finalidad y señale cada valor que no use ninguno.
- Escriba con palabras las reglas adaptables, de contenido y de imagen y pruebe la composición con el texto real más largo.
- Enumere los recursos con sus formatos y licencias, redacte criterios de aceptación por pantalla y nombre un único canal para las preguntas.
Preguntas frecuentes
¿Qué debe incluir una entrega de diseño a desarrollo?
Además de las pantallas: un estatus que indique qué marcos son definitivos, todos los estados de cada componente, los casos límite, los tokens de diseño, las reglas del comportamiento adaptable, el contenido real con sus límites, los recursos con sus licencias y los criterios de aceptación de cada pantalla. Añada un canal de preguntas con nombre. Si un desarrollador puede construir una pantalla sin preguntar qué ocurre cuando faltan los datos o son demasiado largos, la entrega está completa.
¿Qué son los tokens de diseño y los necesita un proyecto pequeño?
Los tokens de diseño son decisiones de diseño con nombre, como un color, un paso de espaciado o un tamaño de letra, que se guardan una vez y se referencian en todas partes. La documentación de Material Design dice que son más útiles cuando el producto se va a actualizar, abarca varias plataformas o cuenta con un sistema de diseño, y menos útiles en una aplicación existente con valores fijos que difícilmente cambiará. Un proyecto pequeño puede empezar con una tabla breve de colores, tamaños y espaciados con nombre.
¿Es el formato de tokens de diseño un estándar oficial del W3C?
No. El Design Tokens Format Module 2025.10 lo publicó el Design Tokens Community Group, que trabaja bajo el proceso de grupos comunitarios del W3C, y el documento indica que no es un estándar del W3C ni está en la vía de estandarización del W3C. El grupo describe la especificación como estable y pensada para implementarse. Consulte la versión vigente en el sitio del grupo antes de construir herramientas sobre ella.
¿Qué estados debe tener cada componente de una interfaz?
Depende del componente, pero el conjunto habitual para un elemento interactivo es normal, cursor encima, foco de teclado, pulsado y deshabilitado. Los elementos que dependen de datos necesitan además los estados de carga, éxito, error y vacío. Las especificaciones de Material Design organizan los valores de los componentes por estado por la misma razón. Enumere los estados en una tabla y escriba «igual que el normal» donde esa sea la respuesta, para que nada quede a la suposición.
¿Cómo se redactan los criterios de aceptación de un diseño?
Escriba para cada pantalla una lista corta de resultados observables, con la fórmula que propone el Service Manual del Gobierno británico: «está hecho cuando…». Por ejemplo: está hecho cuando se han construido todos los estados enumerados, cuando la composición aguanta cualquier ancho entre el mínimo y el máximo indicados, cuando cabe el contenido real de longitud máxima y cuando los tokens del código coinciden con los del archivo. Acuerde la lista antes del desarrollo y revise la compilación con ella.