Si empiezas proyectos listando entregables, lo más probable es que termines diseñando para entregar, no para transformar.
Cuando me preguntan cómo empezar un proyecto de diseño no hablo de briefs, ni siquiera de user personas, ni de journeys. Hablo de proyectar. Porque diseñar no es cumplir requerimientos, es provocar cambios.
El diseño siempre tiene un pie en el presente y el otro en el futuro. Proyectamos nuevos contextos que cambian comportamientos, percepciones, relaciones. No solo resolvemos ‘problemas de diseño’, transformamos realidades. Con cada decisión que tomamos estamos definiendo un futuro posible.
Y un gran poder conlleva una gran responsabilidad, diría el tío Ben. Diseñar sin pensar en las consecuencias es una negligencia estratégica.
Por eso, antes que llenar un brief extenso, prefiero hacer solo cuatro preguntas. Trato de entender qué queremos cambiar y para qué en lugar de dejarme arrastrar por deadlines y entregables.
Las 4 preguntas que hago para diseñar con sentido
Divido cualquier proyecto en dos grandes momentos:
- La situación actual: qué está pasando hoy y por qué.
- La situación futura: qué cambio queremos provocar.
Estas preguntas están inspiradas en Lean UX que, más allá de las críticas, tiene un aporte clave: nos pide proyectar un futuro concreto, no solo mejorar el presente.
No es un checklist, es una forma pensar.
La situación actual
1. ¿Qué problema real del negocio estamos resolviendo? ¿Qué datos lo evidencian?
No la suposición del product owner, no la suposición del el equipo de diseño: el problema de negocio.
Muchas veces el proyecto nace de intuiciones vagas: «necesitamos una app», «esto se ve viejo», «la competencia ya lo tiene». Y aunque la intuición puede ser valiosa, si no la respaldamos con evidencia terminamos resolviendo síntomas, no causas. Puede ser data dura (conversiones, NPS, ventas, LTV) o venir de entrevistas, chats de soporte o incluso conversaciones internas.
Lo que busco aquí es una mirada sistémica del problema: ¿por qué está pasando?, ¿cómo o a quiénes nos afecta?, ¿qué pasa si no se resuelve?
¿Qué pasaría si este proyecto no se hiciera? Si la respuesta es «no mucho», entonces no es un problema, es una solo una ocurrencia.
Caso real:
Un banco creía que su cuenta de ahorro no se usaba para ahorrar porque *«*le faltaban features» y quería agregarle funcionalidades de otros productos. Pero al mirar los datos y el contexto, descubrimos que el problema no era funcional: era de relevancia. Antes de agregarle operativas, necesitábamos darle un nuevo sentido.
2. ¿Qué necesidad o frustración tienen las personas? ¿Cómo la están resolviendo ahora?
No qué piden, no qué están haciendo hoy, no qué dicen en la encuesta NPS. Qué están intentando lograr realmente.
Las personas ya están resolviendo sus problemas con o sin nosotros. Diseñamos para sumar valor, no para sobreescribir su realidad. Y ese valor tiene que partir de comprender por qué hacen lo que hacen: cuál su necesidad. La necesidad suele ser estable en el tiempo, lo que cambia es cómo se manifiesta.
Intervenimos en lo que ya ocurre. Si no sabemos cómo se comportan antes de diseñar, no estamos proponiendo una solución sino imponiendo una idea.
Caso real:
Descubrimos que los clientes usaban la cuenta de ahorro para gastos diarios. No era que no supieran ahorrar, era que el producto les hablaba desde un paradigma que ya no encajaba con su vida.
La situación futura
3. ¿Qué resultado espera obtener el negocio? ¿Cómo lo vamos a medir?
«Más usuarios» o «más contrataciones» no es suficiente. Queremos saber cuál es el impacto observable que hará que este proyecto haya valido la pena.
Ese resultado clave tiene que ser tangible, medible y, sobre todo, relevante. A veces establecemos métricas que brillan en los dashboards pero que no cambian nada en la realidad.
¿De qué sirve tener más usuarios con la app descargada si luego no contratan el plan premium?, ¿de qué sirve tener más contrataciones si luego nadie usa el producto y lo cancelan al mes?
Caso real:
En lugar de medir únicamente ‘cuentas abiertas’, nos enfocamos también en ‘uso sostenido para ahorrar’. Esa sería la verdadera señal de que el producto estaba cumpliendo su rol y resolviendo el problema inicial.
4. ¿Qué beneficios obtendrán las personas? ¿qué cambios de comportamiento podríamos observar?
Si el diseño funciona, algo cambia. No solo la interfaz, sino el comportamiento.
Aquí es donde muchos se quedan en lo abstracto: «una mejor experiencia». Hay que traducir esa experiencia en beneficios reales: más control, menos fricción, mejor comprensión, menos ansiedad. Qué cambia para esa persona y por qué eso le importa.
Caso real:
Redefinimos el beneficio: no se trataba de más funcionalidades, sino de facilitar el ahorro sin fricción y con metas realistas. Una cuenta que se adapte a su contexto real, que hablara su idioma. El cambio esperado era visible: más personas usándola para guardar dinero mes a mes.
Diseñar cambios, no solo entregables
Estas preguntas no te garantizan el éxito, te evitan uno de los peores errores: diseñar sin saber lo que quieres transformar. Es un marco para empezar a diseñar un camino claro entre lo que el negocio necesita y lo que las personas realmente valoran.
No siempre hace falta un discovery de tres semanas. A veces una buena conversación con atención al cliente y una sesión de análisis de datos pueden darte un punto de partida potente.
Porque si el diseño va a transformar la realidad, es mejor que sepamos cuál es la que queremos cambiar y no solo qué pantalla hay que rediseñar.