Julián es diseñador de producto. con dos años en una empresa de SaaS.
El lunes sale de la reunión de priorización y vuelve a su escritorio.
Abre Figma. Mira los diseños que estuvo trabajando las últimas tres semanas. Flujo completo para que los usuarios puedan recuperar sesiones guardadas sin perder contexto. Cuatro pantallas. Tres variantes testeadas. Todo documentado. Research que muestra que el 40% de los usuarios abandonan porque pierden su progreso.
El roadmap se cerró.
Acaba de enterarse de que eso no va a entrar en el roadmap del trimestre.
Julián vuelve a mirar sus diseños. Se pregunta para qué hizo research si al final las decisiones se toman en una sala donde el research no tiene voz.
No hay drama. No hay gritos. No hay “nosotros contra ellos”. Hay algo más corrosivo: la sensación de haber trabajado en serio para una decisión que ya estaba tomada en otro lado.
Y si esto te suena familiar, no es porque tu equipo sea especialmente caótico. Es porque hay una realidad bastante común que a veces tardamos en aceptar: el conflicto de priorización no ocurre cuando ordenamos tareas; ocurre cuando descubrimos quién tiene derecho a decidir qué se pierde.
En comunidades de Reddit como r/UXDesign aparece repetido el mismo dolor con distintas palabras: diseños terminados que “se quedan sentados” meses porque la ingeniería está backlogeada, o porque el plan cambió, o porque el negocio corrió a otra urgencia.
Y en r/ProductManagement en Reddit, investigadores preguntan por qué la investigación resulta “muy interesante” y aun así termina sidelined o descartada.
No es un caso raro. Es un patrón.
Lo incómodo no es que cambien prioridades. Es que cambien después de que vos ya invertiste tiempo
A veces se habla de “prioridades que cambian” como si fuera el precio inevitable de un mercado competitivo. Y sí: cambian.
Pero el golpe real no lo produce el cambio. Lo produce el timing.
Porque hay trabajos que son baratos de mover (un mock rápido, una idea en borrador) y hay trabajos que son caros de mover: research, entrevistas, pruebas, documentación, alineación con ingeniería, iteraciones.
Lo que le pasa a Julián no es solo “me cambiaron el plan”. Es: me hicieron pagar el costo alto antes de saber si existía el permiso para decidir.
Eso es costo de oportunidad en versión vida real: elegiste una cosa, y lo que dejaste de hacer no vuelve.
No importa si el trabajo fue “bueno”. El costo ya se gastó.
Y acá aparece el conflicto de priorización que rara vez se dice en voz alta:
La organización puede cambiar de prioridad.
El diseñador no puede recuperar el tiempo invertido.
Entonces el conflicto no es (solo) “qué hacemos”. El conflicto es: quién asume el costo cuando la decisión llega tarde al lugar donde se trabaja.
El punto de quiebre: cuando “priorizar” significa proteger una narrativa
La palabra “priorización” suena técnica. Como si fuera una operación neutral: ordenar por impacto y esfuerzo.
Pero cuando Julián sale de esa reunión con su flujo muerto, la pregunta real no es “¿hicimos bien el scoring?”. Es otra:
¿Qué historia necesitaba sostener la organización para cerrar el trimestre?
A veces la historia es “crecemos”.
A veces “no podemos fallar”.
A veces “tenemos que vender”.
A veces “tenemos que demostrar movimiento”.
Y dentro de esas historias, algunas pérdidas son aceptables y otras son inaceptables. No por racionalidad pura. Por supervivencia interna.
Esto se ve incluso en discusiones sobre “por qué no puede mi diseño terminado quedarse sentado un par de meses”: el equipo puede tener la intención de “hacerlo”, pero el sistema está atado a fechas, metas y capacidad real.
Y ahí, lo que se pierde no es solo una feature: se pierde el significado del trabajo que hiciste.
No es ideal. Pero es real.
Lo que el diseñador suele entender tarde: hay dos roadmaps
Uno es el que ves.
- Epics, tickets, milestones, un tablero que intenta parecer control.
Y el otro es el que no ves.
- Compromisos comerciales ya firmados.
- Riesgos que nadie quiere mencionar por escrito.
- Deudas técnicas que se “patean” hasta que explotan.
- Expectativas de liderazgo que se traducen en “temas” más que en problemas.
El diseñador suele trabajar con el roadmap visible. Y luego se sorprende cuando gana el invisible.
No porque sea ingenuo. Porque el invisible no se comparte.
Entonces pasan escenas como la de Julián: vos estás resolviendo un problema real (la gente abandona porque pierde progreso) pero la organización está resolviendo otro problema (cumplir una promesa, calmar un frente, sostener una narrativa).
Y ahí el research “no tiene voz” no porque sea malo, sino porque no está en el idioma de la sala donde se decidió.
“Es más común de lo que creés” (y eso debería cambiar tu forma de invertir esfuerzo)
Decir “es común” no es decir “resignate”. Es decir: si es común, conviene diseñar tu forma de trabajar como si fuera una condición del ambiente, no una anomalía.
Hay diseñadores que, frente a esto, se vuelven cínicos: “para qué investigar si igual no entra”. Esa salida es comprensible… y peligrosa, porque te transforma en operador de pedidos.
La alternativa no es pelear cada decisión. Es más sutil: hacer que tu trabajo sea menos frágil ante prioridades que no controlás.
No te lo planteo como “cómo ganar influencia” (esa promesa suele ser humo). Te lo planteo como preguntas que te devuelven criterio.
Tres preguntas que ayudan a pensar mejor (sin fingir que vos definís la prioridad)
- ¿Qué decisión está esperando este trabajo? (y quién la toma de verdad) No “qué vamos a diseñar”. Qué decisión concreta se destraba si esto sale. Si no hay decisión, lo más probable es que estés produciendo material para “estar avanzando”.
- ¿Qué prioridad invisible podría matar esto en dos semanas? No para ser paranoico. Para mapear fragilidad. Si la respuesta es “cualquier cosa comercial”, “cualquier cosa del CEO”, “cualquier incidente”, entonces quizá lo sensato es ajustar el tamaño del esfuerzo: hacer discovery más liviano, prototipos más rápidos, entregables más reutilizables.
- Si esto no entra, ¿qué queda útil igual? Esta es la pregunta que cambia todo: convertir el trabajo en un activo, no en una apuesta binaria. Porque el costo de oportunidad existe igual. La única defensa real es que el aprendizaje sobreviva incluso si el roadmap cambia.
No es glamoroso. Pero es salud mental profesional.
El conflicto real: no es “priorizar”, es “perder con intención”
Decidir siempre implica perder algo. Eso es verdad.
Lo que vuelve traumático el trabajo de Julián no es la pérdida. Es la pérdida sin intención: haber invertido donde no había permiso, donde no había sponsor, donde la decisión no se iba a tomar mirando evidencia.
Por eso este artículo no es una queja contra “los negocios”. Es un recordatorio incómodo para diseño:
- A veces te van a pedir research cuando ya quieren ejecución.
- A veces el sistema va a preferir decisiones “suficientemente buenas” rápido, aunque no sean las mejores.
- A veces tu diseño va a quedar esperando capacidad, no aprobación.
Eso no te quita valor. Te da contexto.
Y el contexto no arregla el roadmap… pero cambia algo importante: te permite dejar de vivir cada cambio como una invalidación personal, y empezar a leerlo como lo que es: un conflicto estructural donde tu trabajo compite con fuerzas que no siempre se anuncian.
Julián mira su flujo “recuperar sesión”. La pregunta útil no es “¿para qué hice research?”
La pregunta útil es más difícil y más adulta:
¿Qué necesito ver antes de invertir tres semanas otra vez?
No para controlar la sala donde se decide.
Para no seguir pagando caro por decisiones que se toman lejos.
Fuentes (externas)
- Diseños terminados que no se implementan por backlog/capacidad y presión de fechas (experiencias en r/UXDesign).
- Debate sobre por qué la investigación se escucha pero se “sidelined/discarded” (r/ProductManagement).
- Racionalidad acotada y “satisficing” (decisiones suficientemente buenas bajo límites reales).
- Costo de oportunidad como valor/beneficio que se pierde al elegir una alternativa sobre otra.
Interpretación del autor
(Julián) no está aprendiendo a priorizar mejor. Está aprendiendo a sobrevivir en un sistema donde otros priorizan y él tiene que negociar desde una posición sin autoridad formal. El problema no es que diseño “no tenga voz”. El problema es que muchas veces se le pide invertir como si la decisión fuera abierta, cuando en realidad ya está cerrada. El criterio del diseñador empieza cuando aprende a detectar esa diferencia temprano.
