Diseño centrado en el usuario: research y prototipado
El diseño que funciona no empieza con una idea brillante. Empieza observando a alguien frustrado intentando resolver un problema que vos todavía no entendés.
Qué es diseño centrado en el usuario
El diseño centrado en el usuario (DCU) es una filosofía de desarrollo que subordina toda decisión de producto a evidencia empírica de cómo las personas reales usan, perciben y valoran lo que construís. Don Norman formalizó los principios en The Design of Everyday Things (1988, rev. 2013, cap. 1-2): los productos bien diseñados son los que comunican su función a través de affordances (qué se puede hacer) y signifiers (cómo se hace) — y que los usuarios no deberían necesitar un manual para entender.
La implicancia para marketing es directa: un producto diseñado sin el usuario en el centro genera fricciones que ninguna campaña de adquisición puede compensar. El churn es la métrica que delata al producto que no fue diseñado con el usuario — cada abandono es un voto de desconfianza sobre la experiencia. Steve Krug lo resume en Don't Make Me Think (cap. 1) con un principio que debería gobernar toda interfaz: si el usuario tiene que pensar para usar tu producto, el diseño falló.
Pero el DCU no se limita a UX digital. Un proceso de onboarding que confunde, un formulario de soporte que frustra, un deck de ventas que no responde las preguntas del comprador — todos son fallos de diseño centrado en el usuario. La filosofía aplica a cada touchpoint donde un humano interactúa con tu oferta.
02El proceso: Double Diamond
El British Design Council formalizó en 2005 el modelo Double Diamond como la estructura canónica del proceso de diseño. Tiene cuatro fases organizadas en dos diamantes: el primero explora el problema (Discover → Define), el segundo explora la solución (Develop → Deliver). Cada diamante tiene una fase divergente (ampliar opciones) y una convergente (elegir y focalizar).
Investigar. Entrevistas, observación, datos. Entender el problema sin filtrar.
Sintetizar. Patrones, insights, definición del problema real a resolver.
Idear y prototipar. Múltiples soluciones posibles. Testear rápido.
Construir, lanzar, medir. Entregar la solución validada al mercado.
Tim Brown, en Change by Design (cap. 3), advierte que el error más frecuente es saltar directamente al segundo diamante: idear soluciones sin haber definido el problema. Los equipos que empiezan dibujando wireframes antes de haber hablado con un usuario están resolviendo un problema que imaginaron — no uno que observaron. El primer diamante es el que conecta con la investigación de mercado y con el framework JTBD: descubrir qué necesita resolver el cliente antes de diseñar cómo resolverlo.
Cagan, en Inspired (cap. 20), agrega un matiz operativo: en la práctica, los dos diamantes no son secuenciales sino iterativos. Descubrís, definís, prototipás, testeás, y los resultados del test te llevan de vuelta a redefinir. El proceso no es lineal sino un loop de aprendizaje continuo que conecta directamente con la lógica de Lean Startup: construir-medir-aprender aplicado al diseño, no solo al producto.
03Research: descubrir antes de diseñar
El research de usuario es la base de todo el proceso — y es donde la mayoría de los equipos acortan camino con consecuencias caras. Hay tres modalidades que responden preguntas diferentes y que no se reemplazan entre sí.
Investigación generativa (descubrir)
¿Qué problemas tiene el usuario? ¿Cómo vive su día? ¿Qué lo frustra? Las entrevistas en profundidad, la observación contextual y los diarios de uso revelan el territorio del problema antes de que el equipo defina la solución. Esta es la fase que alimenta las buyer personas con datos reales en lugar de suposiciones. Si saltás esta fase, todo lo que sigue está construido sobre arena.
Investigación evaluativa (validar)
¿Esta solución funciona? ¿El usuario la entiende? ¿Resuelve lo que prometimos? Los tests de usabilidad, los prototipos interactivos y las sesiones de co-diseño validan antes de construir. Nielsen demostró en su investigación de 1993 (publicada en Usability Engineering) que 5 usuarios encuentran el 85% de los problemas de usabilidad — una de las relaciones costo-beneficio más poderosas del desarrollo de producto.
Investigación cuantitativa (medir)
¿Cuántos usuarios hacen X? ¿En qué momento abandonan? ¿Qué variante convierte más? Los A/B tests, la analítica de producto y los mapas de calor complementan el research cualitativo con escala. Pero medir sin entender es peligroso — Croll y Yoskovitz advierten en Lean Analytics (cap. 4) que las métricas sin contexto cualitativo producen optimizaciones locales que ignoran problemas sistémicos. La visualización de datos ayuda a detectar patrones, pero la interpretación siempre requiere contexto humano.
04Prototipado y testing: la regla de los 5 usuarios
El prototipo es la herramienta que convierte una idea abstracta en algo que un usuario puede usar, criticar y mejorar. No es un entregable estético — es un instrumento de aprendizaje. Cuanto menos invertís en el prototipo, menos cuesta descartarlo cuando el test muestra que no funciona.
Hay un continuo de fidelidad que conecta con la lógica del MVP: un sketch en papel testea la estructura conceptual, un wireframe interactivo testea el flujo, un prototipo de alta fidelidad testea la experiencia completa. Cada nivel responde una pregunta más precisa con un costo mayor. La regla: usá la fidelidad más baja que responda tu pregunta actual.
Nielsen y Landauer formalizaron la "discount usability engineering" en 1993: tests baratos, frecuentes y con pocos usuarios producen más aprendizaje que un estudio grande y caro. La curva es clara — 5 usuarios al 85%, 15 usuarios al 100%. Pero cada ronda de 5 con ajustes intermedios supera ampliamente a una ronda de 15 sin ajustes. La iteración es la mecánica que hace al DCU efectivo: test → aprendizaje → ajuste → test.
Trabajé con un equipo que invirtió 8 meses en un rediseño completo de su plataforma — nueva interfaz, nueva navegación, nueva arquitectura de información. Nunca testearon un prototipo con usuarios reales. El día del lanzamiento, las llamadas a soporte se triplicaron. Los usuarios no encontraban las funciones que usaban todos los días. No era un problema de diseño visual — era un problema de diseño sin usuario. Un test con 5 personas habría detectado el 85% de esos problemas en una semana.
Lisandro IserteNorman vs. Christensen: usabilidad necesaria, no suficiente
Acá está la tensión que la mayoría de los artículos sobre DCU evitan: ¿alcanza con diseñar para el usuario?
Norman dice que sí — que la usabilidad es la base de todo buen diseño y que los productos que comunican su función intuitivamente ganan. Tiene razón dentro de su marco: dado un problema que vale la pena resolver, el producto más usable gana. Krug lo confirma desde la práctica web: cada clic innecesario, cada etiqueta confusa, cada formulario que requiere instrucciones es fricción que aleja al usuario del valor.
Christensen dice que no alcanza. En Competing Against Luck (cap. 3), argumenta que un producto perfectamente usable que resuelve un problema que no importa lo suficiente sigue siendo un fracaso. La usabilidad sin relevancia produce productos elegantes para problemas inexistentes. El DCU como filosofía necesita un ancla que Norman no provee: el job to be done. Diseñar centrado en el usuario sin saber qué job intentás resolver es pulir una herramienta sin saber para qué se usa.
Sharp, desde How Brands Grow, aporta otro matiz: el DCU puede producir productos tan optimizados para el usuario existente que pierden la capacidad de atraer usuarios nuevos. Las mejoras incrementales basadas en feedback del usuario actual convergen hacia un óptimo local que no genera awareness ni diferenciación de marca. A veces el producto necesita features que los usuarios actuales no piden pero que los usuarios futuros necesitan para considerar la marca. La estrategia de posicionamiento y la identidad de marca operan como contrapeso al DCU puro: te dicen qué construir no solo para el usuario sino para el mercado.
Mi postura: el DCU es condición necesaria pero no suficiente. El orden correcto es: primero validá que el job existe y es importante (Christensen), después diseñá la solución centrada en el usuario (Norman), después validá que genera product-market fit (Ellis). El DCU sin JTBD es diseño sin brújula. JTBD sin DCU es comprensión sin ejecución.
06Errores frecuentes
Research como validación en lugar de descubrimiento
"¿Te gusta nuestro nuevo diseño?" no es research — es buscar aprobación. El research genuino empieza sin solución: "Contame cómo resolvés este problema hoy." La investigación cualitativa que descubre es más valiosa que la que confirma. Si solo investigás para validar lo que ya decidiste, el DCU es teatro corporativo.
Diseñar para el usuario promedio
No existe el usuario promedio. Cada segmento tiene contextos, habilidades y necesidades diferentes. Un dashboard diseñado para "cualquier gerente" no sirve para ninguno. La segmentación por ICP aplica tanto al diseño como al marketing: diseñá para un usuario específico y expandí después.
Testear al final en lugar de durante
Equipos que construyen durante meses y testean una semana antes del lanzamiento. El test final no es para descubrir sino para confirmar — y cuando lo que descubrís es que el producto no funciona, ya invertiste todo. La experimentación integrada al proceso de diseño es la que reduce riesgo: testeá prototipos de baja fidelidad temprano, no productos terminados tarde.
Confundir DCU con "hacerle caso al usuario en todo"
Ford: "Si le hubiera preguntado a la gente qué quería, habrían dicho un caballo más rápido." El usuario no diseña — el diseñador diseña informado por el usuario. La priorización de qué construir es responsabilidad del equipo de producto, no del usuario. El research te dice qué problemas resolver; la estrategia te dice cuáles priorizar.
Cómo usar el DCU para diagnosticar tu producto
Si tu producto ya está en el mercado y las métricas no cierran, el DCU funciona como herramienta de diagnóstico. La iteración informada por datos reales es lo que convierte un producto estancado en uno que mejora.
Si el onboarding tiene abandono alto: el primer diamante está fallando — el producto no comunica su valor inicial. Hacé 5 tests de usabilidad del flujo de activación. Observá dónde se detienen, qué preguntan, qué ignoran. Cada fricción del onboarding es un impuesto invisible sobre la conversión.
Si la retención baja después de la semana 2: el producto no genera valor recurrente. El usuario completó el primer ciclo pero no encontró razón para volver. Entrevistá a los que se fueron: ¿qué esperaban que no encontraron? ¿Qué los haría volver? Estas respuestas alimentan el roadmap con prioridades del usuario, no del equipo.
Si el NPS es medio (30-50): el producto funciona pero no entusiasma. No hay fricción obvia ni valor sorprendente. Acá el diagnóstico no es de usabilidad sino de diferenciación: ¿qué haría que tu producto fuera "must have" en lugar de "nice to have"? La respuesta suele estar en gains inesperados que el research generativo descubre — cosas que el usuario no sabía que necesitaba hasta que las experimentó. La estrategia de contenido puede funcionar como instrumento de descubrimiento: qué preguntan los usuarios en soporte, en foros, en búsquedas de Google — esos patrones revelan jobs no atendidos.
Preguntas frecuentes sobre diseño centrado en el usuario
¿DCU es lo mismo que design thinking?
Son conceptos relacionados pero no idénticos. El DCU es una filosofía: toda decisión se basa en evidencia del usuario. Design thinking es una metodología que operacionaliza esa filosofía. Podés practicar DCU con otras herramientas y podés aplicar design thinking sin ser genuinamente centrado en el usuario.
¿Cuántos usuarios necesito para un test de usabilidad?
5 usuarios encuentran el 85% de los problemas (Nielsen, 1993). Pero esto aplica a tests cualitativos. Si necesitás significancia estadística, necesitás cientos. Elegí el método según la pregunta: ¿descubrir problemas? 5 usuarios. ¿Medir impacto? Tráfico a escala.
¿El DCU aplica a servicios?
A todo lo que un humano usa o experimenta. Un servicio se puede diseñar con DCU: investigar, prototipar con pilotos, testear en vivo y ajustar. La diferencia es que en servicios el prototipo es un piloto real y el testing ocurre con el cliente presente.