El diseñador de producto no debería limitarse a resolver tickets
Un ticket suele describir una solución ya decidida. Por qué conviene que diseño participe en entender el problema y qué necesita el equipo para que sea posible.
“Añadir un filtro por fecha al listado de pedidos.” Un ticket así llega con la solución dentro. Quien lo recibe puede ejecutarlo bien, en poco tiempo, y cerrar la tarea sin saber qué problema había detrás.
Eso no es una crítica a quien lo escribió, que muy posiblemente tenía una idea razonable y poco tiempo. Es una descripción de cómo funcionan muchas colas de trabajo. La petición llega formulada como cambio, y el cambio se atiende.
Ejecutar una petición no es resolver una necesidad
La diferencia es fácil de pasar por alto porque en muchos casos coinciden. Pero cuando no coinciden, el coste es alto, porque se entrega con calidad algo que no resolvía el problema, o se resuelve el problema aparente y se deja el real intacto. Quizá quien pidió el filtro necesitaba localizar un pedido concreto y un buscador lo resolvía mejor. O quizá el listado era tan largo que lo que de verdad hacía falta era organizar la información de otra manera.
Es la misma lógica que aparece con la frase “el usuario quiere”: lo que se pide suele ser una solución, y el problema que hay detrás hay que averiguarlo.
Quien diseña suele tener una perspectiva valiosa para detectarlo. Ve patrones entre pantallas, nota incoherencias, conoce cómo reaccionan las personas ante determinadas soluciones y puede imaginar alternativas que quien formuló la petición no consideró. Reducir ese papel a ejecutar es desaprovechar justo lo que mejor sabe hacer.
Qué puede aportar antes de diseñar
Participar en la comprensión del problema no significa hacer el trabajo de otros. Significa contribuir en momentos concretos.
Puede ayudar a reformular el problema a partir de la petición, de modo que sea posible discutir si la solución propuesta es la mejor. Puede aportar o pedir evidencia, sea de uso, de conversaciones con usuarios o de soporte, y convertir la idea en una hipótesis que se pueda contrastar. Puede proponer alternativas, incluidas algunas que no pasan por diseñar nada nuevo. Y puede participar en la priorización con lo que sabe del coste de la experiencia, por ejemplo qué deuda de interfaz se está acumulando, sin pretender decidir por sí solo.
También puede ayudar a decidir cómo se sabrá si ha funcionado, algo que casi nunca viene en el ticket.
Sin convertir a todos en Product Managers
Conviene no exagerar. Que un diseñador contribuya a definir problemas no implica que asuma las mismas responsabilidades que un Product Manager. La priorización, la relación con el negocio y la responsabilidad sobre los resultados siguen teniendo un dueño, y diluirlo perjudica a todos. Lo que se pide es que exista una zona compartida en la que se piense junto, y que quede claro quién decide cuando hay que elegir. La tensión entre diseño y producto suele nacer justo de que esa zona no existe o de que nadie sabe dónde acaba.
Tampoco todos los diseñadores querrán, o necesitarán, ampliar así su rol. Hay oficio profundo en la ejecución, y un buen equipo necesita gente excelente en ella. El punto es que la ejecución mejora cuando se conoce el porqué.
Qué necesita el equipo para que ocurra
Depende menos de la voluntad individual que de cómo se trabaja. Lo que llega a diseño debería incluir el problema, la evidencia y lo que se espera conseguir, algo parecido a lo que describe la guía sobre qué debe tener una buena historia de usuario. Y hace falta que se invite a diseño a la conversación cuando todavía se puede cambiar el rumbo, no cuando el alcance ya está cerrado.
Si el ticket llega con la solución y sin contexto, el resultado dependerá en buena parte de la suerte. Si llega con el problema, quien diseña puede hacer lo que mejor sabe: ayudar a encontrar la forma adecuada de resolverlo.
Nota retrospectiva: reflexión escrita en 2026 sobre el contexto de febrero de 2023.
Las opiniones expresadas son personales y no representan la posición de ninguna organización.