Diseño, negocio y desarrollo deberían hablar antes
Las restricciones que aparecen tarde y los objetivos que nadie compartió salen caros. Qué cambia cuando diseño, negocio y desarrollo entienden juntos el problema.
Piensa en una funcionalidad para que los clientes descarguen sus informes. Desde diseño se resuelve con un botón en cada tabla. Desarrollo, al verla, descubre que esos informes se generan con un proceso pesado y que descargar uno en el momento puede tardar minutos. Negocio, que no estaba en la conversación, esperaba en realidad que los clientes pudieran programar envíos periódicos.
Nadie ha hecho mal su trabajo. Cada perspectiva ha resuelto bien su parte de un problema que nadie definió en común.
El coste de enterarse tarde
Un cambio suele costar más cuanto más avanzado está el trabajo. Una restricción técnica conocida el primer día es un dato de partida. La misma restricción, descubierta cuando el diseño está cerrado, obliga a rehacerlo o a aceptar una versión recortada que ya nadie reconoce. Un objetivo de negocio que se aclara tarde produce el mismo efecto con otro origen.
Pasa algo menos visible: cada vez que alguien rehace su trabajo porque otra área aportó información tarde, se refuerza la idea de que las demás áreas son un obstáculo. El retrabajo se come tiempo, y también la confianza.
Lo que aporta cada perspectiva
Ninguna basta por sí sola, y ayuda ser concreto sobre lo que cada una sabe.
Negocio sabe por qué importa el problema ahora, qué objetivo hay detrás, qué compromisos existen con clientes o con la normativa y qué margen hay para equivocarse. Desarrollo sabe qué es sencillo y qué es caro, qué riesgos técnicos hay y, con frecuencia, qué alternativa más simple resolvería lo esencial. Diseño sabe en qué contexto se usará, qué necesita realmente la persona y qué formas distintas de plantear la experiencia existen.
Cuando solo una de las tres decide, las otras dos actúan como filtros posteriores en lugar de como fuentes de información.
Una conversación corta y temprana
No hace falta una gran ceremonia. Puede bastar una reunión de media hora, antes de que nadie abra una herramienta de diseño o escriba una línea de código. Debe reunir a quienes de otro modo se enterarían tarde y centrarse en pocas cosas. Qué queremos conseguir y para quién. Qué límites técnicos y de negocio hay que respetar. Qué señal nos diría que hemos acertado.
El resultado es una definición compartida del problema, escrita en pocas líneas, a la que se puede volver. Esa definición suele ahorrar más discusiones que una especificación larga, porque cuando surge una duda hay algo anterior a las soluciones a lo que referirse. Para ordenar quién aporta qué, la guía sobre cómo conectar UX, negocio y tecnología propone un buen punto de partida.
Más allá de la entrega
Se suele hablar de este asunto como un problema de traspaso entre disciplinas, y es cierto que los handoffs acumulan coste. Pero aquí el foco es anterior. Antes de preguntar cómo se pasa un diseño a desarrollo, conviene preguntar si desarrollo y negocio participaron en decidir qué diseño hacía falta.
Eso no significa que todos decidan todo. La responsabilidad sobre cada decisión puede seguir siendo clara y de una sola persona. Lo que cambia es que decide con información de las tres miradas, y en el momento en que cambiar de rumbo todavía es barato.
Nota retrospectiva: reflexión escrita en 2026 sobre el contexto de noviembre de 2021.
Las opiniones expresadas son personales y no representan la posición de ninguna organización.