Antes de construir, hay que convertir incertidumbre en dirección de producto
La interfaz es solo la parte visible de una decisión de producto. Antes de diseñar, hace falta entender procesos, usuarios, negocio y tecnología para que cada pantalla responda a una dirección clara y no a una suma de suposiciones.
UX Strategy · Product Design · Definición · Roadmap · Delivery · Business & Tech Alignment
El trabajo invisible antes del diseño
La calidad de un producto no depende solo de cómo se ve, sino de lo bien que entiende el sistema que intenta resolver.
En proyectos digitales complejos, el verdadero valor no está en empezar rápido a diseñar pantallas, sino en entender qué hay que construir, para quién, con qué restricciones y con qué impacto esperado. Antes de abrir Figma, antes de definir componentes, antes incluso de cerrar un backlog, hay una fase crítica que muchas veces se infravalora: convertir una necesidad ambigua en una dirección de producto accionable.
Esa fase no siempre tiene un nombre evidente. A veces se llama discovery, otras conceptualización, definición funcional, fase cero o aterrizaje de producto. Para mí, más allá del nombre, su función es clara: reducir incertidumbre antes de comprometer decisiones de diseño, desarrollo o inversión.
En contextos sencillos, puede bastar con entender un flujo, validar una hipótesis y diseñar una solución directa. Pero en productos donde conviven múltiples usuarios, procesos, sistemas, equipos, objetivos de negocio y restricciones técnicas, empezar por la interfaz suele ser una forma elegante de construir en falso. Una pantalla puede parecer correcta y, aun así, responder a un proceso mal entendido. Un flujo puede resultar limpio en prototipo y, aun así, no encajar con la operación real. Una funcionalidad puede sonar lógica en una reunión y, aun así, no resolver el problema que existe en el día a día.
Por eso, antes de diseñar, hay que entender.
El riesgo de diseñar desde la solución imaginada
Product Discovery & Definión
Uno de los errores más habituales en proyectos complejos es confundir lo que el cliente pide con lo que el usuario necesita. No porque el cliente no conozca su negocio, sino porque muchas veces expresa el problema desde la solución que imagina, no desde la raíz de lo que ocurre.
“Necesitamos un dashboard”. “Queremos automatizar este proceso”. “Hay que rediseñar esta pantalla”. “Queremos incorporar inteligencia artificial”. Todas esas peticiones pueden ser legítimas, pero por sí solas no explican el problema. ¿Qué decisión debe facilitar ese dashboard? ¿Qué parte del proceso realmente consume tiempo? ¿Qué información falta? ¿Qué usuario se bloquea? ¿Qué dato no es fiable? ¿Qué tarea se repite sin aportar valor? ¿Qué riesgo aparece si automatizamos demasiado?
Otra trampa frecuente es convertir un workshop en una lista infinita de deseos. En sesiones con stakeholders y usuarios reales aparecen muchas ideas, necesidades y frustraciones. Eso es valioso, pero no todo lo que aparece debe convertirse en funcionalidad. El trabajo estratégico consiste precisamente en ordenar, interpretar, priorizar y traducir. No se trata de documentar todo lo que alguien pide, sino de entender qué patrón hay detrás, qué problema se repite, qué impacto tiene y qué solución puede sostenerse técnica y operativamente.
Cuando esto no se hace bien, el producto empieza a acumular funcionalidades sin dirección. Cada perfil pide una cosa, cada área defiende su prioridad y cada nueva pantalla intenta resolver un caso particular. El resultado suele ser una herramienta más pesada, más difícil de mantener y, paradójicamente, menos útil para quienes la usan.
Diseñar es entender el sistema
Antes de diseñar una interfaz, hay que entender el sistema que la sostiene: personas, procesos, decisiones, restricciones, datos, herramientas y expectativas de negocio. En proyectos complejos, la UX estratégica no empieza en Figma, sino en la capacidad de leer esa realidad, detectar dónde se rompe la experiencia y traducir la complejidad en decisiones de producto claras, viables y accionables.
Leer antes que diseñar
Diseñar no consiste solo en decidir cómo se ve una pantalla, sino en comprender cómo trabajan las personas, qué información necesitan, qué decisiones toman y qué tareas les generan fricción. Cuando el contexto es complejo, una interfaz bien resuelta visualmente puede fallar si no responde al proceso real que hay detrás.
Entender la complejidad real
En plataformas con múltiples perfiles, entidades, procesos y niveles de coordinación, el valor no está en producir pantallas rápido, sino en ordenar el ecosistema completo. Hay que comprender dependencias, flujos, datos, reporting, interoperabilidad y oportunidades de mejora antes de convertir todo eso en una propuesta de producto coherente.
Conectar negocio, usuario y tecnología
Los problemas complejos rara vez pertenecen solo a UX, solo a negocio o solo a tecnología. Suelen estar en la intersección. Por eso es clave escuchar a usuarios y stakeholders, detectar fricciones, hablar con equipos técnicos, valorar viabilidad, anticipar delivery y traducir todo ese aprendizaje en decisiones que puedan construirse.
Diseñar con dirección de producto
Empatizar con el usuario no basta si después no se aterriza en alcance, prioridades y viabilidad. Definir requisitos tampoco sirve si no se entienden los flujos reales. Una buena fase previa convierte investigación, negocio y restricciones técnicas en una dirección de producto clara: qué construir, por qué, para quién y en qué orden.
Del contexto a la dirección
Trabajo para transformar información dispersa en una dirección de producto clara, priorizada y construible.
Cuando abordo una fase de definición o aterrizaje de producto, intento no pensar en ella como una secuencia rígida de pasos, sino como un proceso de reducción progresiva de incertidumbre. Primero se abre el problema; después se ordena; finalmente se convierte en dirección.
La primera parte es entender el contexto. Esto implica talleres de discovery, entrevistas, revisión de procesos, sesiones con stakeholders y, cuando tiene sentido, cuestionarios que permitan recoger información más estructurada. Aquí no busco solo “requisitos”, sino entender cómo funciona realmente el trabajo. Qué tareas se hacen, en qué orden, con qué herramientas, qué información se pierde, qué decisiones dependen de otras personas, qué se duplica y qué genera frustración.
Después viene la síntesis. User personas, mapas de empatía y journeys no son entregables decorativos: son herramientas para ordenar una realidad compleja y hacerla discutible. Ayudan a poner sobre la mesa que no todos los usuarios tienen los mismos objetivos, capacidades digitales, presiones o criterios de éxito. También permiten detectar puntos de fricción que no siempre aparecen cuando alguien enumera funcionalidades.
A partir de ahí, el trabajo empieza a transformarse en producto. El mapa de historias de usuario es especialmente útil porque obliga a pasar de “necesitamos algo para gestionar esto” a “como este perfil, necesito realizar esta acción para conseguir este objetivo”. Ese cambio parece pequeño, pero es enorme: centra la definición en la acción, el usuario y el valor esperado. También permite ordenar alcance, detectar dependencias y empezar a distinguir qué forma parte de un MVP y qué puede evolucionar en fases posteriores.
Los wireframes de baja fidelidad entran en ese momento como una herramienta de pensamiento, no como diseño final. Sirven para validar navegación, jerarquía, estructura y lógica funcional antes de invertir esfuerzo en una interfaz más pulida. Un wireframe permite discutir si una tarea está bien ubicada, si un flujo tiene sentido, si falta información, si una acción es comprensible o si el usuario necesita más contexto para tomar una decisión.
La validación con stakeholders y usuarios es clave para evitar que la solución se quede en una hipótesis interna. Validar no significa preguntar “¿te gusta?”, sino comprobar si lo propuesto encaja con la realidad operativa, si resuelve el problema, si genera dudas, si simplifica o añade fricción. Y, sobre todo, significa estar dispuesto a refinar: ajustar el mapa de historias, revisar el prototipo, reordenar prioridades y volver a alinear expectativas.
En proyectos donde aparece inteligencia artificial, esta fase es todavía más importante. Antes de decidir si hace falta un asistente, un modelo predictivo, un recomendador o una automatización, hay que entender el proceso, el dato disponible, el nivel de riesgo, el criterio profesional implicado y el grado de control humano necesario. La IA no debería entrar como respuesta genérica, sino como una capacidad vinculada a un problema concreto.
Finalmente, todo ese trabajo necesita convertirse en hoja de ruta. No basta con descubrir y diseñar; hay que priorizar, identificar valor, esfuerzo, dependencias, riesgos y fases de evolución. Un buen roadmap no es una lista de funcionalidades ordenadas por deseo, sino una propuesta de dirección: qué construir primero, por qué, qué valida, qué desbloquea y cómo prepara al producto para crecer.
Diseñar menos en falso
Antes de construir producto, hay que construir dirección
Una buena fase de aterrizaje no ralentiza el proyecto; evita construir en falso. Ayuda a que el diseño no sea solo una representación visual de deseos, sino una respuesta estructurada a problemas reales. Ayuda a que el backlog no sea una lista infinita, sino una herramienta de decisión. Ayuda a que la tecnología no se incorpore por moda, sino por valor. Y ayuda a que negocio, UX y desarrollo trabajen desde una comprensión compartida.
En proyectos complejos, la incertidumbre no desaparece del todo. Pero se puede ordenar. Se puede convertir en hipótesis, criterios, prioridades, flujos, pantallas, arquitectura, roadmap y decisiones accionables. Ese es, para mí, el verdadero trabajo previo al diseño: transformar ambigüedad en dirección. Porque antes de construir, hay que saber qué problema merece ser construido.
Hablemos de producto, UX y dirección
Si estás trabajando en una solución compleja y necesitas ordenar procesos, usuarios, negocio y tecnología antes de construir, podemos conversar sobre cómo convertir esa incertidumbre inicial en una dirección de producto clara, viable y accionable.