Módulo 1: What To Measure
El framework HEART
Descripción
Ya sabes distinguir una métrica accionable de una de vanidad (lección 2) y por qué una tasa comparable es más fuerte que un total (lección 3). Pero eso todavía no contesta una pregunta muy práctica: frente a un feature nuevo como recommendations, ¿por dónde empiezas a buscar métricas candidatas? Sin una estructura, es fácil o bien quedarte corto —medir una sola cosa y perderte el resto de la historia— o irte al otro extremo —medir todo lo que se te ocurra, sin ningún criterio de qué tan importante es cada cosa—.
HEART es un framework que Kerry Rodden, Hilary Hutchinson y Xin Fu publicaron en Google en 2010 para resolver exactamente ese problema en productos de UX a gran escala. El nombre es un acrónimo de cinco dimensiones de la experiencia de usuario: Happiness (felicidad), Engagement (compromiso), Adoption (adopción), Retention (retención) y Task success (éxito de la tarea). No son cinco métricas fijas —son cinco preguntas distintas que puedes hacerte sobre cualquier feature, y para cada una, tú eliges la métrica accionable (tasa, con lo que aprendiste en las lecciones 2 y 3) que mejor la conteste en tu producto.
Conexión con el módulo. Esta lección y la siguiente (AARRR) son las dos herramientas de estructura del módulo: en vez de elegir métricas al azar, HEART te da cinco ángulos distintos desde donde mirar un feature dentro del producto, y AARRR (lección 5) te da cinco etapas del recorrido de un usuario a través del negocio. La lección 6 va a tomar algunas de las métricas que elijas hoy y organizarlas en un árbol con una North Star arriba.
Una analogía: el chequeo médico completo
Cuando vas a un chequeo médico general, el médico no te toma un solo signo vital y te manda a casa. Te mide varias cosas distintas —presión arterial, temperatura, frecuencia cardíaca, oxígeno en sangre, peso— porque ninguna de esas cinco mediciones, por sí sola, te dice si estás sano. Puedes tener una temperatura perfecta y una presión arterial peligrosamente alta. El chequeo completo existe porque la salud tiene varias dimensiones independientes, y hace falta mirar cada una con su propio instrumento.
HEART hace lo mismo con la salud de un producto: en vez de un solo número que "resume todo" —el error clásico de medir un feature con una sola métrica—, te obliga a mirar cinco dimensiones independientes de la experiencia. Un feature puede tener una tasa de adopción excelente (mucha gente lo prueba) y una retención terrible (nadie vuelve a usarlo); si solo miraras adopción, pensarías que todo va bien. El nombre del framework, literalmente "corazón" en inglés, no es casualidad: es un chequeo completo, no un termómetro solo.
Ejemplo trabajado: HEART aplicado a recommendations
Vamos a recorrer las cinco dimensiones de HEART y, para cada una, proponer la métrica accionable —siempre una tasa, siguiendo el criterio de la lección 3— que mejor la contesta para el carrusel de recomendaciones de Mercado:
| Dimensión | Pregunta que contesta | Métrica candidata para recommendations |
|---|---|---|
| Happiness | ¿Los usuarios están contentos con la experiencia? | Encuesta corta post-compra: "¿qué tan útiles fueron las recomendaciones?" (CSAT de 1 a 5, reportado como % de respuestas 4-5). |
| Engagement | De quienes ven el feature, ¿cuánto interactúan con él? | recommendationClickRate — clics en el carrusel ÷ veces que se mostró (impressions), por sesión. |
| Adoption | ¿Cuántos usuarios nuevos empiezan a usar el feature? | % de compradores nuevos (su primera semana en Mercado) que interactúan con el carrusel al menos una vez. |
| Retention | De quienes ya lo usaron, ¿vuelven a usarlo? | % de usuarios que interactuaron con recomendaciones la semana pasada y vuelven a interactuar esta semana. |
| Task success | ¿El feature ayuda a completar la tarea real —comprar—? | checkoutConversionRate de las sesiones que vieron recomendaciones, comparado contra las que no. |
Fíjate en un patrón: cuatro de las cinco métricas de la tabla son tasas con numerador y denominador claros —exactamente el criterio de la lección 3—. La excepción es Happiness, que por naturaleza mide una opinión declarada (una encuesta), no un comportamiento medido directamente. Eso no la vuelve inválida: HEART incluye Happiness a propósito porque hay cosas —como si a un usuario le gusta una experiencia— que el comportamiento solo no siempre revela. Pero sí significa que Happiness necesita leerse con más cuidado que las otras cuatro: una encuesta puede tener sesgo de quién responde, y por eso casi nunca se usa sola para decidir si un feature funcionó.
El proceso completo: metas, señales, métricas
Rodden no propone solo el acrónimo: propone un proceso de tres pasos para llegar de una dimensión abstracta a una métrica concreta, que vale la pena ver aplicado a una dimensión en detalle —tomemos Engagement:
- Goal (meta): en palabras simples, ¿qué queremos lograr? "Que los usuarios interactúen con las recomendaciones cuando las ven."
- Signal (señal): ¿qué comportamiento, si lo viéramos, nos diría que la meta se está cumpliendo? "Usuarios haciendo clic en productos del carrusel, no solo pasando de largo."
- Metric (métrica): ¿cómo convertimos esa señal en un número medible y comparable?
recommendationClickRate = clics en el carrusel ÷ impresiones del carrusel, por sesión.
Repetir este proceso —meta, señal, métrica— para cada una de las cinco dimensiones es lo que evita el error más común de usar HEART mal: saltar directo a "necesitamos una métrica de Engagement" sin haber articulado primero qué comportamiento específico, en este producto, significaría que el engagement mejoró.
Una aclaración importante: no siempre las cinco aplican
La propia Rodden es explícita en esto: no todas las cinco dimensiones de HEART son relevantes para cada feature. Un cambio puramente visual —como un rediseño de color de un botón— probablemente no tiene una historia real que contar en Adoption (nadie "adopta" un color) ni en Retention. Forzar una métrica en cada una de las cinco letras, aunque no tenga sentido para lo que estás midiendo, es exactamente el tipo de sobre-ingeniería que este módulo entero busca evitar. Para recommendations, las cinco dimensiones sí tienen sentido —es un feature nuevo, con una curva de adopción real, una interacción medible, y un vínculo directo con la tarea de comprar—, pero no asumas que siempre será así.
Errores comunes
Medir 50 cosas dentro de HEART y no accionar ninguna. Qué pasa: un equipo, entusiasmado con el framework, le pone tres o cuatro métricas a cada una de las cinco letras —"por si acaso"— y termina con un dashboard de veinte métricas que nadie revisa a fondo cada semana. Por qué pasa: HEART se siente como una checklist que hay que "llenar completa" para hacerlo bien, cuando en realidad el objetivo es elegir una métrica fuerte por dimensión relevante, no acumular todas las posibles. Cómo detectarlo: si le preguntas al equipo "¿qué acción tomarían si esta métrica específica bajara un 10% mañana?" y no tienen una respuesta clara para la mitad de las veinte, sobra la mitad. Cómo corregirlo: por cada dimensión, elige la métrica única y accionable que mejor conteste su pregunta —como en la tabla de hoy—, no una colección. Menos métricas, bien elegidas, se revisan; muchas, no.
Confundir Happiness (opinión declarada) con Engagement (comportamiento real). Qué pasa: un equipo reporta una encuesta de satisfacción alta ("el 90% dice que las recomendaciones le parecen útiles") como si fuera evidencia de que la gente de verdad las está usando, sin mirar el recommendationClickRate real. Por qué pasa: las dos cosas suenan parecidas —"les gusta" y "lo usan"— pero son señales de tipos distintos: una es lo que la gente dice, la otra es lo que la gente hace. Cómo detectarlo: la conclusión sobre un feature se apoya solo en una encuesta, sin ningún dato de comportamiento real que la respalde. Cómo corregirlo: usa Happiness como complemento de Engagement y Task success, nunca como sustituto. Si la encuesta dice que gusta pero el click rate es bajísimo, hay una desconexión real que vale la pena investigar, no ignorar.
Forzar las cinco letras aunque el feature no las necesite todas. Qué pasa: para un cambio chico —como ajustar el orden de los filtros de búsqueda— el equipo insiste en definir una métrica de Adoption y otra de Retention, inventando algo forzado porque "HEART tiene cinco letras". Por qué pasa: el acrónimo se siente como una plantilla que hay que completar entera para "estar usando el framework correctamente". Cómo detectarlo: la métrica propuesta para una dimensión no tiene una pregunta de negocio real detrás —es una respuesta a "necesitamos llenar esta casilla", no a "necesitamos saber esto". Cómo corregirlo: recuerda la aclaración de Rodden misma: no todas las dimensiones aplican siempre. Para un feature grande y nuevo como recommendations, las cinco sí tienen sentido; para un ajuste chico, puede que solo una o dos lo tengan, y eso está bien.
Ejercicios
Ejercicio 1 — Ubica la dimensión. Para cada métrica candidata, di a cuál de las cinco letras de HEART pertenece, y por qué:
- (a) % de vendedores nuevos que suben al menos un producto en su primera semana en el dashboard de vendedores.
- (b) Tiempo promedio que tarda un comprador en encontrar y completar una devolución (medido contra si lo logró sin contactar soporte).
- (c) % de compradores que usaron el filtro de precio la semana pasada y lo vuelven a usar esta semana.
Ver solución
- (a) Adoption. Es exactamente la pregunta de adopción: ¿cuántos usuarios nuevos empiezan a usar el feature (el dashboard de vendedores)?
- (b) Task success. La pregunta es si el feature (el flujo de devolución) ayuda a completar la tarea real —lograr la devolución— sin fricción, no si a la gente "le gusta" ni si vuelve a usarlo.
- (c) Retention. La estructura —"lo usó la semana pasada, ¿vuelve a usarlo esta semana?"— es la definición misma de retención dentro de HEART, aplicada a un feature específico (el filtro), no al producto entero.
Ejercicio 2 — Aplica el proceso de tres pasos. Para la dimensión Task success de recommendations, escribe tú mismo el Goal, el Signal y la Metric, siguiendo el mismo proceso que se aplicó a Engagement en la lección. (La tabla de arriba ya te da la métrica final; el ejercicio es reconstruir el razonamiento completo hacia atrás.)
Ver solución
Una respuesta razonable: Goal — "que las recomendaciones ayuden a los usuarios a completar una compra, no solo a navegar". Signal — "usuarios que ven recomendaciones y terminan completando el checkout, comparado con usuarios que no las ven". Metric — checkoutConversionRate segmentado por si la sesión incluyó una interacción con el carrusel o no. El punto del ejercicio es notar que la métrica final de la tabla (checkoutConversionRate) no aparece de la nada: viene de haber articulado primero, en palabras simples, qué comportamiento contaría como éxito real de la tarea.
Ejercicio 3 — Detecta el forzado. El equipo de un cambio menor —cambiar el ícono del carrito de compras de Mercado— propone esta métrica de Adoption: "% de usuarios que hacen clic en el nuevo ícono al menos una vez". ¿Por qué esta métrica es un ejemplo del error "forzar las cinco letras", y qué mediría en su lugar?
Ver solución
Es forzado porque todos los usuarios que usan el carrito ya "adoptan" automáticamente el ícono nuevo con solo seguir usando el producto normalmente —no hay una decisión real de "empezar a usar" algo nuevo, como sí la hay con un feature genuinamente opcional como recommendations—. La métrica terminaría siendo casi idéntica al total de usuarios activos, disfrazada de "Adoption", sin decir nada específico sobre el cambio de ícono. En su lugar, para un cambio tan chico, probablemente ni Adoption ni Retention tengan sentido: la dimensión relevante es más bien Task success —¿la gente sigue encontrando y usando el carrito igual de rápido que antes, o el nuevo ícono generó confusión?— medida, por ejemplo, con la tasa de usuarios que abren el carrito y completan el checkout sin errores de navegación.
Resumen y siguiente paso
En esta lección conociste HEART —Happiness, Engagement, Adoption, Retention, Task success—, el framework de Google para elegir métricas desde cinco ángulos distintos de la experiencia dentro de un producto. Viste el proceso de tres pasos (Goal → Signal → Metric) aplicado a recommendations, armaste la tabla completa de las cinco dimensiones para el carrusel de Mercado, y aprendiste la aclaración clave: no todas las dimensiones aplican siempre, y forzarlas todas —o multiplicar métricas dentro de cada una— es el error más común al usar el framework.
Antes de avanzar deberías poder: nombrar las cinco dimensiones de HEART y la pregunta que cada una contesta; aplicar el proceso Goal → Signal → Metric a una dimensión nueva; y reconocer cuándo una dimensión de HEART no aplica a un cambio específico.
La lección 5 te da el segundo framework del módulo: AARRR, de Dave McClure. Donde HEART mira la experiencia dentro de un feature, AARRR mira el recorrido completo de un usuario a través del negocio —desde que llega hasta que paga—.
Recursos
- Kerry Rodden, Hilary Hutchinson y Xin Fu, "Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications" (CHI 2010) — research.google/pubs/measuring-the-user-experience-on-a-large-scale-user-centered-metrics-for-web-applications. El paper original donde nace HEART. En inglés.
- Kerry Rodden, página personal sobre HEART — kerryrodden.com/heart. Recursos adicionales de la autora del framework, incluyendo el post original de Google Ventures y un capítulo de su libro sobre investigación de UX cuantitativa. En inglés.
- ProductPlan, "HEART Framework" — productplan.com/glossary/heart-framework. Un resumen práctico del proceso Goals → Signals → Metrics con ejemplos adicionales fuera de Mercado. En inglés.