El diseño que nadie ve es el que decide si un sistema sobrevive

El sistema que llegó "terminado" y no funcionaba

Un equipo entrega el sistema. Pasa las pruebas técnicas. El código compila. La demo funciona. Y tres meses después, nadie lo usa — o peor, todos lo usan a regañadientes mientras siguen resolviendo las cosas importantes en WhatsApp y Excel.

Eso no es un problema de programación. Es un problema de diseño. Alguien tomó decisiones — sobre qué construir, para quién, con qué prioridad — sin tener suficiente información, o sin hacerse las preguntas correctas. Y el resultado es un sistema técnicamente correcto que no resuelve nada real.

La diferencia entre un sistema que se adopta y uno que se abandona casi nunca está en la calidad del código. Está en el trabajo que ocurrió antes de escribirlo.

---

Por qué el diseño previo es el paso que más se saltea

Hay una presión constante en los proyectos de software por "empezar a construir". Los plazos aprietan, el presupuesto está aprobado, el equipo está disponible. Sentarse a definir el problema antes de tocar el teclado se siente como perder tiempo.

El resultado predecible: el equipo construye lo que el cliente pidió, no lo que el cliente necesitaba. Y esa distinción, que parece filosófica, tiene consecuencias muy concretas.

Un sistema de gestión de reclamos que nadie usa porque el flujo no refleja cómo trabaja realmente el equipo de soporte. Un módulo de reportes que genera veinte vistas distintas pero no responde la única pregunta que el gerente hace cada lunes. Una integración con el ERP que funciona perfectamente en staging y explota en producción porque nadie preguntó cómo estaban estructurados los datos reales.

Estos no son casos de mala programación. Son casos de diseño apresurado — o directamente ausente.

---

Qué significa diseñar bien (y qué no significa)

Diseñar una solución no es hacer un wireframe bonito ni escribir un documento de requerimientos de cincuenta páginas que nadie va a leer. Es tomar decisiones informadas sobre tres cosas:

Qué problema se está resolviendo realmente. No el síntoma que el cliente describió en la primera reunión, sino el problema de fondo. Un cliente que pide "un dashboard con métricas" puede estar resolviendo un problema de visibilidad, o uno de confianza entre áreas, o uno de proceso que ningún dashboard va a solucionar. Si no distinguís eso antes de empezar, construís la respuesta equivocada con mucha precisión.

Para quién se construye y en qué contexto lo usa. Un sistema que van a operar despachadores en un galpón con guantes tiene requerimientos de UX completamente distintos a uno que usa un analista financiero en su escritorio. Eso no es obvio si nadie lo pregunta. Y si nadie lo pregunta, el diseño lo asume — generalmente mal.

Qué se prioriza cuando no se puede tener todo. Todo proyecto tiene restricciones reales: tiempo, presupuesto, capacidad del equipo. La pregunta no es "qué queremos" sino "qué necesitamos que funcione primero para que esto tenga valor". Un sistema que resuelve el 20% del problema de forma excelente es más útil que uno que intenta resolver el 100% y no termina de funcionar ninguna parte.

Diseñar bien es tomar esas tres decisiones con información real, no con supuestos. Y eso requiere conversaciones incómodas antes de que el equipo empiece a construir.

---

Cómo se ve esto en la práctica

El trabajo de diseño previo no tiene que ser largo ni burocrático. Puede ocurrir en una o dos semanas de trabajo enfocado. Lo que no puede saltarse son ciertas preguntas.

Antes de definir cualquier funcionalidad, vale responder:

• ¿Qué está pasando hoy sin este sistema? ¿Cómo lo resuelve la gente ahora?
• ¿Qué tiene que ser verdad para que este sistema se considere exitoso en seis meses?
• ¿Quién lo va a usar, con qué frecuencia, y en qué condiciones?
• ¿Qué parte del problema, si la resolvemos bien, hace que todo lo demás sea secundario?
• ¿Qué datos existen hoy y en qué estado están?

Esa última pregunta es especialmente importante y casi siempre se subestima. Un sistema nuevo que depende de datos que viven en planillas inconsistentes, o en un ERP con una API sin documentar, va a tener problemas que ningún diseño de interfaz puede resolver.

Las respuestas a estas preguntas no las tiene el equipo técnico solo. Las tiene el cliente, los usuarios finales, y a veces alguien en operaciones que nunca fue invitado a la reunión de kick-off. El diseño previo es, en buena medida, un ejercicio de escucha estructurada.

---

El costo de saltear este paso

No es abstracto. Se puede medir.

Un requerimiento mal entendido que se descubre en la mitad del desarrollo cuesta entre cinco y diez veces más corregirlo que si se hubiera detectado antes de empezar — esto es consistente con décadas de datos en ingeniería de software, desde los estudios de Barry Boehm en los años 80 hasta análisis más recientes del Standish Group sobre proyectos fallidos.

Pero más allá del costo de reproceso, hay un costo que no aparece en ninguna factura: el tiempo que el equipo del cliente pierde adaptándose a un sistema que no encaja con su forma de trabajar. Ese costo es silencioso y se paga todos los días.

Cuando el diseño previo está bien hecho, el desarrollo no es más lento — es más directo. Las decisiones técnicas tienen contexto. Los trade-offs son explícitos. Y cuando aparece algo inesperado (siempre aparece algo inesperado), el equipo sabe qué priorizar porque entiende el problema real.

---

Qué hacer ahora

Si estás a punto de aprobar un proyecto nuevo: pedí ver el documento que responde "qué problema resuelve esto y cómo vamos a saber si funcionó". Si no existe, es la primera cosa que tiene que existir antes de que el equipo empiece a construir.

Si tenés un sistema en producción que nadie usa: antes de rediseñarlo o reemplazarlo, hacé una ronda de entrevistas cortas con los usuarios reales. Preguntá cómo resuelven hoy lo que el sistema debería resolver. Las respuestas van a decirte si el problema es de diseño, de adopción, o de algo más profundo.

Si estás evaluando a un proveedor técnico: fijate si te hacen preguntas incómodas sobre el problema antes de hablar de soluciones. Un equipo que va directo a proponer tecnología sin entender el contexto te va a entregar exactamente lo que pediste — que puede no ser lo que necesitás.