El punto donde más dinero se pierde en un proyecto digital no es el diseño ni el desarrollo: es el traspaso entre los dos. Cada duda que el equipo técnico tiene que resolver adivinando es una decisión de diseño tomada sin diseñador.
El síntoma: «el desarrollo no quedó igual al diseño»
Casi nunca es culpa del desarrollador. Suele ser que el archivo no respondía las preguntas que aparecen al implementar: qué pasa con este texto si es el doble de largo, cómo se comporta esta tarjeta a 375px, cuál es el estado de foco de este campo, qué se ve mientras carga.
Un archivo listo para desarrollo responde esas preguntas antes de que se hagan.
Checklist de entrega
Esto es lo que reviso antes de dar por cerrado un proyecto de interfaz:
- Nomenclatura consistente: páginas, frames y capas nombrados con la misma lógica que usará el código. Nada de «Frame 214».
- Tokens conectados: colores, tipografías y espaciados aplicados como variables, no como valores manuales.
- Auto layout en todo lo que sea responsive, con constraints correctos y comportamiento de crecimiento definido.
- Breakpoints reales diseñados: móvil, tablet y escritorio, no solo el desktop con la promesa de que «se adapta».
- Todos los estados por componente, incluidos foco visible, error con mensaje, deshabilitado, cargando y vacío.
- Assets exportados en los formatos y densidades correctos, con SVG para todo lo vectorial.
- Prototipo navegable de los flujos críticos, para que el equipo entienda la intención, no solo la pantalla.
- Notas de accesibilidad: contraste WCAG AA verificado, orden de tabulación, textos alternativos y tamaños mínimos táctiles.
Habla el idioma del código
Si el equipo trabaja con una librería de componentes, el diseño debe reflejar esa estructura: mismos nombres, mismas variantes, misma escala de espaciado. Cuando la escala de diseño es 4/8/12/16 y la del código es 5/10/15, cada pantalla se negocia dos veces.
Lo mismo aplica a la tipografía: definir una escala corta y nombrada (display, título, cuerpo, apoyo, mono) evita que aparezcan catorce tamaños distintos en producción.
La sesión de handoff vale más que el documento
Una reunión de 45 minutos recorriendo el archivo con el equipo técnico resuelve más dudas que veinte páginas de documentación. Ahí se detectan los casos límite que ni diseño ni desarrollo habían visto, y se acuerda qué se simplifica para llegar a tiempo.
Después de esa sesión mantengo el canal abierto durante la implementación: revisar la construcción en curso y ajustar detalles a tiempo cuesta mucho menos que corregirlos al final.
Cuando el prototipo va en código
En varios proyectos entrego además el prototipo funcional construido, no solo el diseño. Eso elimina de raíz la ambigüedad: el equipo ve el comportamiento real de animaciones, transiciones y estados, y puede tomar el código como referencia directa.
Diseñador UI e interfaces en Medellín
Preguntas frecuentes
¿Entregas los archivos editables?
Sí. Figma ordenado y nombrado, con tokens, componentes, specs de espaciado y responsive, assets exportados y prototipo navegable. Los archivos son tuyos.
¿Acompañas la implementación?
Sí, con una sesión de handoff y revisiones durante la construcción. También puede quedar cubierto de forma continua con el plan de mejoras y actualización.
¿Trabajas con equipos de desarrollo externos?
Habitualmente. El proceso está pensado justo para eso: que cualquier equipo pueda implementar sin depender de conversaciones constantes.
Casos relacionados
Proyecto propio
Sitio tipo portafolio construido sobre un sistema de diseño propio, con énfasis en composición editorial y carruseles controlables.
Eregion Forge
E-commerce de miniaturas y modelos 3D en resina para deluxificar juegos de mesa: catálogo con carruseles de fotos, ficha de producto detallada y checkout simple.
Sigue leyendo
¿Tu equipo pierde tiempo interpretando diseños?
Puedo revisar tus archivos actuales y dejarlos listos para desarrollo.