Definir el problema: POV, HMW y User Persona
Tienes notas de entrevistas, datos de analytics y un mapa de observaciones. Ahora viene la parte más exigente del proceso: convertir todo ese material bruto en una sola afirmación de problema que todo el equipo comparta.
Si saltaste la investigación y llegaste aquí con intuiciones, este paso te va a resultar difícil. No porque las herramientas sean complicadas, sino porque sin datos reales las herramientas se convierten en ficción bien formateada.
¿Por qué importa definir bien el problema?
Resolver mal el problema correcto es caro. Resolver bien el problema equivocado es inútil.
Un equipo que no ha acordado explícitamente qué problema está resolviendo acaba:
- Diseñando para distintos usuarios imaginarios sin saberlo.
- Priorizando features por intuición o por quien grita más fuerte.
- Iterando sobre síntomas en lugar de causas.
- Celebrando lanzamientos que no mueven ninguna métrica relevante.
La fase de definición existe para evitar exactamente eso.
Affinity Mapping: del caos al patrón
Antes de usar POV o HMW, necesitas agrupar los hallazgos.
El Affinity Mapping es una técnica de síntesis donde cada observación ocupa una nota independiente y el equipo las agrupa por tema emergente, sin categorías predefinidas.
Proceso:
- Cada persona del equipo escribe sus observaciones (una por nota, en presente y en tercera persona: “El usuario no encuentra el botón de exportar”).
- Se colocan todas las notas en un espacio visual (FigJam, Miro, pared física).
- Se agrupan en silencio por afinidad temática, sin debatir todavía.
- Se nombra cada grupo con una afirmación, no con un sustantivo: “Los usuarios no saben que la función X existe” en lugar de “Descubribilidad”.
- Se identifican los grupos con más notas y los que se repiten en más perfiles de usuario distintos.
Los grupos con mayor densidad y diversidad de perfiles marcan los problemas que más merecen atención.
POV: Point of View
El POV es una afirmación de problema centrada en el usuario que actúa como brújula del proceso de diseño.
Estructura:
[Usuario] necesita [necesidad real] porque [insight inesperado].
La clave está en la distinción entre necesidad y solución:
- ❌ “El usuario necesita un botón más grande.”
- ✅ “El usuario necesita saber en qué punto del proceso está porque no sabe cuánto tiempo le queda y abandona antes de terminar.”
El primer ejemplo ya dice cómo resolver el problema. El segundo describe la necesidad real y deja abierta la forma de resolverla.
Ejemplo completo:
Ana, coordinadora de proyectos, necesita tener visibilidad del estado de las tareas de su equipo en tiempo real porque cuando tiene que informar a dirección no sabe si la información que tiene está actualizada.
HMW: How Might We
El HMW convierte el POV en una pregunta de diseño abierta. Es el puente entre el problema y la fase de ideación.
Estructura:
¿Cómo podríamos [verbo accionable] para [resultado esperado]?
La pregunta debe ser lo suficientemente abierta para admitir múltiples respuestas, pero lo suficientemente acotada para no quedarse en el vacío.
Demasiado cerrado (ya implica la solución):
¿Cómo podríamos añadir un indicador de progreso en el paso 3?
Demasiado abierto (imposible de atacar):
¿Cómo podríamos hacer que los usuarios sean más felices?
En su punto:
¿Cómo podríamos ayudar a las coordinadoras a tener siempre una visión actualizada del estado de su equipo?
Un mismo POV puede generar varios HMW. Eso es bueno: significa que el problema es rico y admite distintas aproximaciones.
User Persona
La User Persona es una representación semificticia del usuario basada en patrones reales extraídos de la investigación. No es un personaje inventado con nombre y foto de stock: es un destilado de los comportamientos, motivaciones y fricciones que aparecen de forma recurrente en los datos.
Para qué sirve:
- Mantener al equipo alineado sobre quién es el usuario prioritario.
- Tomar decisiones de diseño con un referente concreto (“¿esto le ayudaría a Carmen?”).
- Comunicar a stakeholders quién es el usuario sin necesidad de leer todas las entrevistas.
Qué debe incluir:
- Nombre y contexto: cargo, sector, situación de uso típica.
- Objetivo principal: qué intenta conseguir con el producto.
- Frustraciones: qué le bloquea o le genera fricciones hoy.
- Comportamientos relevantes: cómo trabaja, qué herramientas usa, en qué contexto.
- Cita representativa: una frase real extraída de las entrevistas que capture su actitud.
Lo que no debe ser:
- Una demografía sin comportamiento (“mujer, 35 años, licenciada en Económicas”).
- Un personaje que justifica decisiones ya tomadas.
- Una foto bonita sin datos detrás.
Ejemplo de una Persona bien construida:
Carmen, Coordinadora de proyectos Trabaja en una consultora de 50 personas. Gestiona 4 proyectos simultáneos desde Jira y hojas de cálculo. Necesita enviar un informe semanal a dirección pero dedica 2 horas a recopilar datos dispersos en distintas herramientas.
Objetivo: tener visibilidad del avance real sin necesidad de preguntar a cada persona del equipo. Frustración principal: “Cuando pregunto al equipo el estado de algo, siempre me dicen que va bien, pero cuando miro los datos no cuadra.” Comportamiento: No usa las vistas de reporting de Jira porque no sabe que existen. Confía más en el chat de Slack que en el sistema.
El error más común: la Persona de fantasía
Crear una Persona sin datos detrás es peor que no tenerla, porque da una falsa sensación de rigor mientras el equipo sigue tomando decisiones basadas en suposiciones.
Si alguien en el equipo dice “nuestro usuario es millennials tech-savvy con alto poder adquisitivo”, esa no es una Persona. Es un deseo.
¿Qué hemos aprendido?
- El Affinity Mapping convierte observaciones dispersas en patrones con nombre.
- El POV define el problema desde la necesidad real del usuario, no desde la solución.
- El HMW convierte ese problema en una pregunta accionable para idear.
- La User Persona es un destilado de datos reales, no un personaje inventado.
Siguiente paso
En la próxima lección veremos Arquitectura de información y flujos de usuario, donde aprenderás a organizar el contenido y los pasos del producto antes de dibujar ninguna pantalla.