Por qué el escepticismo es la herramienta más productiva de un equipo de producto.
A veces me da la sensación de que en nuestra industria se premia demasiado la certeza rápida. Llega un requerimiento, alguien dice «necesitamos un dashboard para esto» y, a los diez minutos, ya hay tres personas discutiendo si el gráfico debe ser de barras o de líneas. Nos lanzamos a la solución porque la duda nos incomoda, porque parece que si no tienes una respuesta inmediata, es que no eres lo suficientemente senior.
¿Y si fuese justo al revés? Diseñar desde la duda es lo único que nos salva de construir basura estética.
Cuando hablo de duda no me refiero a esa parálisis que te impide avanzar, sino a una especie de escepticismo preventivo. Es esa voz que te dice: «El cliente dice que quiere esto, pero ¿realmente sabe lo que necesita?». Cuestionar no es molestar por deporte, es una forma de respeto hacia el producto. Si me limito a ejecutar lo que me piden sin analizar su impacto real, dejo de ser un diseñador para convertirme en un operario que simplemente maquilla ideas ajenas. Para eso ya está la IA.
Cuestionar significa entender que el requerimiento inicial puede ser solo un síntoma, no el diagnóstico. Lo peor de todo es que podríamos acabar optimizando procesos que ni siquiera deberían existir.
La duda como metodología técnica: Del «Qué» al «Para qué»
Para que esta duda no se quede en algo abstracto, deberíamos plantearnos antes de construir:
- La auditoría de la necesidad: Antes de tocar cualquier programa de diseño, deberíamos evaluar cómo es el proceso actual (si lo hubiese). Si el usuario pide un reporte semanal, la duda técnica nos obliga a preguntar: ¿qué decisión va a tomar con esos datos? Si la respuesta es «solo para control», quizás no necesite un reporte, sino una alerta automatizada cuando algo se sale de rango. Dudar de la solución pedida nos permite diseñar la solución necesaria.
- La abstracción: Aquí es donde la duda se vuelve eficiente. Hoy en día es peligrosamente fácil crear prototipos de alta fidelidad en minutos, pero eso es una trampa: el brillo de una interfaz terminada puede camuflar una lógica interna rota. Diseñar desde la duda implica obligarnos a validar el esqueleto del sistema. Si el sistema no se puede representar en un simple diagrama de cajas y flechas, no funcionará por muy bonito que lo pintes. Este ejercicio de abstracción ahorra miles de iteraciones innecesarias y nos permite detectar errores estructurales en los flujos.
- El sesgo del feedback: Cuando testeamos lo que hemos diseñado, inconscientemente esperamos que el usuario nos diga que «está bien». Diseñar desde la duda significa ir a buscar el fallo. Significa plantear escenarios donde el sistema se rompe o donde la información es confusa. En productos B2B críticos, no buscamos el «wow», buscamos el «entiendo perfectamente qué ha pasado y qué tengo que hacer ahora». La duda nos empuja a diseñar para el error, no para el flujo perfecto.
Conclusión: La humildad de no saberlo todo
Al final, la duda es una forma de humildad técnica. Es reconocer que un producto digital es algo vivo y que nuestras primeras ideas la mayoría de las veces son mediocres porque están basadas en supuestos, no en hechos, lo que no quita que estén bien como punto de partida.
Diseñar desde la duda nos obliga a ser mejores investigadores y mejores estrategas. Nos saca de nuestra zona de confort visual y nos obliga a entender el negocio del cliente como ellos mismos. Quizás solo cuando dudamos de todo, podemos estar seguros de que lo que finalmente construimos tiene una razón de ser. Menos certezas de manual y más preguntas incómodas.