Una plataforma educativa que traduce métricas UX en patrones visuales aplicables, diseñada para que diseñadores y estudiantes en LATAM tomen decisiones informadas y las defiendan con datos.
| ROL Lead UX/UI Designer | DURACIÓN 12 semanas | CONTEXTO Proyecto académico | ENTREGABLES Web responsive · MVP |
| MÉTODO Design Thinking | FRAMEWORK HEART (Google) | HERRAMIENTAS Figma · FigJam · Notion | AÑO 2024 |
RESUMEN EJECUTIVO
Datasigners es una plataforma web educativa que cataloga métricas UX y las organiza bajo el framework HEART de Google. Está pensada para diseñadores de producto y estudiantes que necesitan tomar decisiones de diseño respaldadas por datos, en un contexto donde la información sobre métricas UX está dispersa, en inglés y desconectada de casos reales.
El problema
El diseñador en LATAM aprende métricas UX a partir de fragmentos: hilos de Twitter, papers académicos, blogs traducidos sin contexto. Cuando llega el momento de decidir qué medir frente a un brief real, el conocimiento no se traduce en criterio. La consecuencia es una presentación al cliente en la que las decisiones de diseño se sostienen en intuición, no en evidencia.
La solución
Una plataforma con tres puertas de entrada — Métricas, Framework y Roles — que permite al usuario llegar al concepto desde donde le resulta más natural. Cada métrica tiene una ficha consistente que responde siempre las mismas preguntas: por qué importa, cómo se calcula, dónde aplicarla, qué empresas la usan y qué tip UX sostiene su uso. La taxonomía HEART funciona como hilo conductor que une las cinco dimensiones del comportamiento del usuario — Happiness, Engagement, Adoption, Retention, Task Success — con cada métrica del catálogo.
El impacto esperado
- Comprensión: el usuario localiza la métrica que necesita en menos de 60 segundos.
- Confianza: presenta sus decisiones con un argumento técnico replicable, no improvisado.
- Comunidad: consolidar un vocabulario común sobre métricas en español, anclado en HEART.
PROCESO - Cómo trabajé este proyecto
Apliqué Design Thinking en cinco fases (Empatizar, Definir, Idear, Prototipar, Testear) tratándolas como ciclos iterativos, no como pasos lineales. Cada fase produjo un deliverable concreto que alimentó la siguiente, y los hallazgos del testing me devolvieron a la empatía cuando lo aprendido lo exigía.
Figura 1. Vista general del proceso Design Thinking aplicado a Datasigners.
El criterio para volver a una fase anterior fue siempre el mismo: si una decisión de diseño no podía sustentarse en algo que el research había revelado, el research era insuficiente. Este principio, que funciona como guía operativa del proyecto, terminó siendo también la tesis del producto: las decisiones se sostienen en evidencia, no en preferencia.
FASE 01 · EMPATIZAR. Escuchar antes de diseñar
Comencé sin asumir qué necesita un diseñador para tomar decisiones data-informed. Quería entender la fricción real, no la que yo imaginaba. Para eso combiné tres métodos: entrevistas en profundidad, una encuesta cuantitativa y un análisis competitivo de las fuentes que el público objetivo ya consume.
Métodos de research
Entrevistas semi-estructuradas (n = 6)
Conversaciones de 45 minutos con tres diseñadores mid-level en empresas digitales de Lima y Bogotá, dos juniors en agencias y una estudiante de séptimo ciclo de Diseño Gráfico. La guía giraba en torno a tres preguntas: cómo decides qué medir cuando recibes un brief, dónde encuentras información cuando te enfrentas a una métrica nueva, y cómo presentas tus decisiones a un PM o cliente.
Encuesta cuantitativa (n = 42)
Distribuida en comunidades UX de LinkedIn y Discord. Validé hipótesis sobre frecuencia de uso de métricas, herramientas habituales y nivel de seguridad al defender decisiones. Tres datos confirmaron la dirección del proyecto:
- 78% reconoce el HEART framework por nombre, pero solo 23% lo aplica de forma estructurada.
- 64% busca información sobre métricas en Google primero, no en cursos formales.
- 81% considera “moderado” o “alto” su nivel de inseguridad al traducir hallazgos UX a métricas de negocio.
Análisis competitivo
Estudié 12 fuentes que el público objetivo ya consume: Nielsen Norman Group, Smashing Magazine, Mobbin, UX Collective, Coursera, Coderhouse, además de cuatro hilos de Twitter y dos newsletters. La mayoría tiene contenido de calidad, pero ninguna ofrece una taxonomía consistente que permita comparar métricas entre sí. Esa fue la grieta que Datasigners decidió ocupar.
Empathy Map
Sintetizar las entrevistas en un Empathy Map me obligó a separar lo que el usuario dice de lo que el usuario hace y siente. La distancia entre esas cuatro dimensiones es donde vive el insight: Carolina dice que sabe medir, pero piensa que le falta criterio; hace pruebas A/B, pero siente inseguridad al defender resultados.
Figura 2. Empathy Map de Carolina, persona principal del proyecto.
INSIGHT DE LA FASE
El conocimiento del usuario no es el problema; lo es la confianza al traducir ese conocimiento en argumentos defendibles frente a stakeholders.
Personas
El research convergió en dos arquetipos. No los construí como ficciones decorativas: cada atributo demográfico está sustentado en datos públicos sobre el ecosistema digital peruano y latinoamericano (DataReportal 2024, Glassdoor, AméricaEconomía, Vertiv). Los puse uno al lado del otro porque comparten una fricción central, pero la viven en intensidades distintas.
Figura 3. Síntesis comparada de las dos User Personas: Carolina (mid-level) y Mariana (estudiante).
Carolina López — La diseñadora que necesita defender lo que ya sabe
29 años, mid-level en una startup fintech limeña. Conoce las herramientas, ha hecho cursos en Coursera y Coderhouse, y trabaja en flujos mobile-first con Figma y Amplitude. La fricción para Carolina no es aprender — es sintetizar y argumentar. Cuando un PM le pide “fundamentos teóricos” detrás de su decisión de mover un botón, la conversación se convierte en un esfuerzo de retraducción que no estaba en su brief inicial.
Mariana Torres — La estudiante que busca aplicar lo que está aprendiendo
21 años, séptimo ciclo de Diseño Gráfico. Asiste a talleres extracurriculares de UX/UI y se entera del estado del arte por TikTok y YouTube más que por la malla curricular. Su fricción es opuesta a la de Carolina: tiene tiempo y motivación para aprender, pero carece de proyectos reales donde aplicar el aprendizaje. Necesita un recurso que la puentee entre teoría académica y casos de industria.
DECISIÓN DE DISEÑO
Una sola plataforma para los dos perfiles. La profundidad la elige el usuario al navegar: Mariana entra por la puerta del Framework para aprender la teoría; Carolina entra por la puerta de Métricas para resolver un caso puntual.
Customer Journey Map
Mapeé el journey de Carolina en el escenario más representativo: un brief de rediseño donde tiene que defender una métrica frente a su PM. Trabajé cinco fases — Descubrir, Investigar, Filtrar, Aplicar, Defender — y para cada una documenté acciones, pensamientos, emociones, pain points y oportunidades. La curva emocional fue el dato más revelador: la frustración no aparece al inicio, aparece en el centro del journey, justo donde el usuario tiene que filtrar información sin un criterio claro.
Figura 4. Journey Map del escenario “Antes de Datasigners”. La curva emocional cae en la fase Filtrar.
FASE 02 · DEFINIR - Sintetizar para encontrar el problema real
El research generó casi 200 notas: citas de entrevistas, observaciones de la encuesta y hallazgos competitivos. La fase de definición consistió en agrupar ese material, encontrar los temas dominantes y traducirlos en un problema accionable.
Affinity Diagram
Trabajé el clustering en FigJam, moviendo notas hasta que emergieron cuatro temas que se sostienen entre sí. No fueron etiquetas que yo eligiera; fueron grupos que el material formó con poca intervención mía. Cuando las notas se agruparon naturalmente alrededor de “fragmentación del conocimiento”, “teoría sin aplicación”, “distancia con negocio” y “necesidad de referentes”, supe que el research había alcanzado saturación.
Figura 5. Affinity Diagram. Los cuatro clusters convergen en un único insight clave.
De los cuatro clusters destilé tres POV statements en formato “Usuario + Necesidad + Insight”. Funcionan como brújula: cualquier feature que diseñe debe poder defenderse frente a uno de ellos.
| POV | Statement |
| POV-1 | Carolina, diseñadora mid-level, necesita una taxonomía clara de métricas UX porque la información dispersa la obliga a improvisar criterios cada vez que recibe un brief. |
| POV-2 | Mariana, estudiante de diseño, necesita ejemplos aplicados de métricas en empresas reales porque la teoría académica no le da pruebas concretas con las que construir su portafolio. |
| POV-3 | Ambas personas necesitan un puente entre métrica y argumento de negocio porque, sin él, sus decisiones de diseño son percibidas como subjetivas por sus stakeholders. |
Convertí cada POV en preguntas How Might We — la formulación que abre el espacio de exploración sin amarrar la solución. Estas son las que sobrevivieron al filtrado:
- HMW-1 ofrecer una taxonomía visual que permita reconocer una métrica en menos de 10 segundos.
- HMW-2 conectar cada métrica con casos de uso de empresas reales, no con definiciones aisladas.
- HMW-3 permitir que el usuario filtre métricas por dimensión de comportamiento (qué quiere medir), no por nombre.
- HMW-4 incluir un “tip UX” por métrica que el diseñador pueda llevarse a su próxima reunión.
Los diseñadores y estudiantes en LATAM no carecen de información sobre métricas UX; carecen de un mapa curado, visual y aplicable que les permita identificar la métrica correcta para un problema concreto y defender su decisión con evidencia frente a stakeholders.
FASE 03 · IDEAR - De problema a backlog
Con un problem statement firme, la ideación dejó de ser brainstorming abierto y se convirtió en una sucesión de filtros. Tres herramientas guiaron la fase: Jobs To Be Done para asegurar que cada idea respondía a un trabajo real, User Stories para traducir el JTBD a implementación y una matriz de priorización para decidir qué entraba al MVP académico.
Jobs To Be Done
El framework JTBD me obligó a pensar el producto no como “una web de métricas”, sino como un trabajo que el usuario contrata. Lo más interesante apareció al separar las tres dimensiones del job: la funcional es solo la punta del iceberg; el peso real está en la dimensión emocional y social.
Figura 6. Canvas Jobs To Be Done con job statement principal y tres dimensiones del trabajo.
REFRAME DEL PRODUCTO
Datasigners no vende información sobre métricas. Vende confianza profesional al usuario que tiene que defender una decisión de diseño con datos. Toda la información que ofrecemos es vehículo, no fin.
User Stories
Traduje los Jobs y los HMW a User Stories en formato “Como [rol], quiero [acción], para [beneficio]”. Cada historia incluye criterios de aceptación medibles, lo que las vuelve directamente accionables en sprint.
| ID | User Story | Criterios de aceptación |
| US-01 | Como diseñador con un brief en mano, quiero filtrar las métricas por dimensión HEART para identificar rápidamente cuáles aplican a mi caso. | · Los filtros corresponden a las 5 dimensiones HEART · Más de un filtro puede coexistir (chip-style) · El listado se actualiza sin recarga de página · Tarjeta visual identifica la dimensión por color |
| US-02 | Como estudiante explorando, quiero ver una página dedicada al framework HEART para entender la teoría completa antes de aplicar métricas individuales. | · Página independiente con las 5 dimensiones · Cada dimensión expone qué mide, dónde encontrarla y por qué importa · Incluye señales típicas y ejemplos por dimensión |
| US-03 | Como diseñador presentando hallazgos, quiero ver casos de uso de empresas reales por cada métrica, para sostener mi argumento con un referente. | · Mínimo 3 casos por métrica · Cada caso identifica el contexto, la empresa y el resultado · Acompañados de ilustraciones consistentes con el sistema visual |
| US-04 | Como usuario nuevo, quiero entender qué hace Datasigners en menos de 10 segundos para decidir si me sirve. | · Hero con propuesta de valor explícita · Tres tarjetas que muestran las puertas de entrada |
| US-05 | Como diseñador en un sprint, quiero un “tip UX” por métrica para llevarlo a la siguiente reunión sin tener que sintetizarlo yo mismo. | · Tip presente en cada ficha de métrica · Máximo 3 oraciones, accionable · Lenguaje neutro, no académico |
| US-06 | Como usuario que descubrió una métrica útil, quiero guardarla para volver a consultarla sin tener que buscarla otra vez. | · Botón de guardado en la tarjeta y en la ficha · Persistencia local (MVP académico, sin cuenta) · Listado accesible desde la sección Usuario |
| US-07 | Como diseñador profundizando en una métrica, quiero ver métricas relacionadas para construir un sistema, no usarla aislada. | · Bloque “Métricas relacionadas” al final de cada ficha · Mínimo 3 métricas afines visibles · Click-through al detalle sin perder el contexto |
| US-08 | Como estudiante con poca experiencia, quiero recursos externos curados al final de cada métrica para profundizar después. | · Sección Recursos en cada ficha · Mínimo 2 enlaces verificados por métrica · Indicador visual del tipo (paper, video, blog) |
Matriz de priorización
Con catorce features candidatos sobre la mesa, necesitaba un criterio para decidir cuáles entraban al MVP académico. Usé una matriz Impacto vs Esfuerzo, donde Impacto se ponderó según cobertura de POVs (cuántos POV resuelve cada feature) y Esfuerzo según horas estimadas en Figma + tiempo de redacción del contenido editorial.
Figura 7. Matriz Impacto vs Esfuerzo. El alcance MVP cubre los Quick Wins completos y los Big Bets más estratégicos.
Lo que entró al MVP
El alcance final concentra siete piezas: catálogo de métricas con filtros HEART (F1, F2), ficha de detalle con plantilla rica (F3), página dedicada al Framework HEART (F5), casos de uso por métrica (F4), Tip UX (F7) y recursos externos (F6). Es la mínima combinación que cubre los tres POVs y permite probar la hipótesis central del producto.
Lo que quedó fuera (y por qué)
- Página de Roles (F9): se mantiene como esqueleto navegable con marca “In Development” para validar con usuarios el interés sin construir la lógica de recomendación todavía.
- Sistema de cuentas y guardados sincronizados (F10): el storage local cubre la promesa al usuario al 80% del costo.
- Comunidad y comentarios (F11): es alto esfuerzo y requiere moderación; no se prueba con un MVP académico.
- Multilingüe EN/ES (F14): la propuesta se diferencia por hablar a LATAM en español; el inglés diluye la apuesta.
FASE 04 · PROTOTIPAR
Construir la experiencia
El prototipado tomó tres semanas y se resolvió en cuatro frentes paralelos: arquitectura de información, sistema de diseño, contenido editorial y composición de pantallas en alta fidelidad. Cada frente alimentó al siguiente con piezas que ya estaban probadas.
Arquitectura de información
El primer entregable fue un sitemap que respondiera a una pregunta simple: ¿cuáles son las rutas mentales del usuario? El research había revelado tres modos de entrada: el que viene buscando una métrica concreta (Carolina con su brief), el que quiere aprender la teoría completa (Mariana en exploración) y el que llega desde un rol específico (un Product Manager curioso). La IA refleja esos tres modos como ramas de primer nivel: Métricas, Framework y Roles.
Figura 8. Arquitectura de información. Una taxonomía única (HEART) atraviesa las cuatro ramas.
DECISIÓN ARQUITECTÓNICA
Una sola taxonomía — HEART — atraviesa las tres ramas. La consistencia taxonómica es lo que permite al usuario saltar entre Framework y Métricas sin reconfigurar su modelo mental.
Service Blueprint
El blueprint extiende el journey hacia los procesos invisibles que sostienen la experiencia. Lo construí porque, aunque Datasigners no es un servicio en el sentido clásico, sí depende de un trabajo editorial constante que el usuario no ve: curaduría de casos, actualización de recursos, mantenimiento del sistema visual. Documentarlo deja claro qué queda dentro del MVP académico y qué requiere el roadmap de la siguiente fase.
Figura 9. Service Blueprint con los cinco momentos de uso y los procesos de soporte que los habilitan.
Sistema de diseño
El sistema visual nace de una restricción que se convirtió en virtud: HEART tiene cinco dimensiones, así que el sistema necesita cinco colores funcionales antes que cualquier otra cosa. Cada dimensión tiene un color y un icono que se repiten consistentemente en tarjetas, filtros, ilustraciones y bloques de detalle. Cuando el usuario ve un círculo amarillo con un trofeo, sabe que está mirando algo de Task Success — antes de leer la etiqueta.
| Dimensión HEART | Color | Significado en el sistema |
| Happiness | Azul | Satisfacción y percepción afectiva del usuario. |
| Engagement | Verde lima | Profundidad e intensidad de la interacción. |
| Adoption | Rojo coral | Velocidad y volumen con que nuevos usuarios incorporan el producto. |
| Retention | Púrpura | Capacidad del producto para retener al usuario en el tiempo. |
| Task Success | Amarillo | Eficacia y eficiencia con que el usuario completa tareas críticas. |
Sobre esa base de cinco colores, el sistema añade tipografía (Arial para texto largo, una display tipográfica para hero y secciones), una grilla de 12 columnas, ilustraciones isométricas en blanco y negro con halos de color que refuerzan la dimensión, y una iconografía sintética que identifica cada métrica.
Pantallas en alta fidelidad
Cinco pantallas completan el MVP. Las muestro en el orden en que el usuario las recorre.
Home — Las tres puertas de entrada
El hero abre con una promesa explícita: “Visualiza la data detrás de tus decisiones”. Debajo, tres tarjetas grandes funcionan como puertas de entrada: Métricas, Framework y Roles. La cuarta tarjeta, intencionalmente posicionada como un feature lateral, invita al usuario que aún no sabe por dónde empezar a explorar la sección Roles, marcada como “In Development”. Esa marca cumple un doble propósito: comunica honestidad sobre el estado del producto y, a la vez, valida interés sin requerir que la lógica esté completa.
Figura 10. Home. Las tres puertas de entrada al sistema.
Catálogo de métricas — La capa de exploración
El catálogo presenta las trece métricas del MVP en un grid con el patrón visual común: ilustración isométrica, dimensión HEART por color y nombre + descripción corta. La barra lateral izquierda contiene los filtros HEART como chips: Éxito, Felicidad, Engagement, Retención y Adopción. El usuario puede combinarlos sin recargar la página, y un buscador superior permite el atajo directo cuando ya sabe qué busca. Las micro-interacciones de los filtros y los iconos de guardado fueron especificados en Figma con estados hover y active.
Figura 11. Catálogo de Métricas. Filtros HEART como chips, búsqueda y tarjetas con dimensión codificada por color.
Framework HEART — La capa pedagógica
Esta página es el ancla teórica. La estructura responde a una decisión: cada dimensión se explica con la misma plantilla — qué estás midiendo, dónde encontrarlo, por qué importa, señales típicas. La consistencia de la plantilla es lo que permite al usuario aprender rápido: cuando ya leyó la primera dimensión, sabe qué esperar de las cuatro restantes. El header presenta una ilustración del framework completo y una explicación que ata HEART a la promesa del producto: convertir intuiciones en evidencia.
Figura 12. Framework HEART. Estructura repetible por dimensión — Éxito, expandido en la captura.
Roles — La capa de aplicación (en desarrollo)
La sección de Roles es el roadmap visible. Seis tarjetas presentan los perfiles del ciclo de producto — UX Designer, UI Designer, Growth Marketer, Data Analyst, Product Manager y Project Manager — cada uno con una descripción corta de qué hace y qué mide. La interacción detallada (recomendar métricas según el rol) queda como fase 2 del producto, pero la página existe en el MVP para validar interés y dar pie a una segunda visita.
Figura 13. Roles. Seis perfiles con esqueleto navegable; la lógica de recomendación queda en roadmap.
Detalle de métrica — La capa de profundidad
La ficha de cada métrica es la pieza más densa del producto y la que más tiempo tomó diseñar. La plantilla siempre responde las mismas preguntas en el mismo orden: Importancia, Fórmula, Aplicación, Casos de Uso, Empresas usándolo, Tip UX y Recursos. Esa consistencia editorial es estratégica: el usuario aprende la plantilla una vez y luego solo tiene que aprender el contenido, no la estructura.
La barra lateral izquierda funciona como tabla de contenidos navegable, lo que reduce el scroll para usuarios que vienen con una pregunta específica. La sección “Casos de Uso” ocupa la mayor parte vertical de la página intencionalmente: es el insight central — ver cómo Spotify, Google o Mercado Libre aplican la métrica — el que convierte la información en argumento. Al final, un bloque de “Métricas relacionadas” invita al usuario a seguir explorando lateralmente, no solo en profundidad.
Figura 14. Ficha de detalle de la métrica User Retention Rate. Sidebar de navegación + plantilla rica + métricas relacionadas.
FASE 05 · TESTEAR - Validar con usuarios reales
El testing del MVP combinó tres métodos: tareas de usabilidad moderadas con cinco participantes, una evaluación heurística usando los principios de Nielsen y la escala SUS (System Usability Scale) administrada al cierre de cada sesión.
Diseño del test
Cinco participantes —tres del perfil Carolina y dos del perfil Mariana— recibieron tres tareas en orden aleatorizado:
- Tarea 1. Imagina que estás trabajando en el rediseño de un onboarding y necesitas medir si los nuevos usuarios completan el primer flujo. Encuentra la métrica adecuada y explica por qué la elegirías.
- Tarea 2. Tu PM te pregunta qué es exactamente el HEART framework. Encuentra la información que necesitas para responderle en menos de dos minutos.
- Tarea 3. Tu equipo está debatiendo si User Retention Rate es la métrica correcta. Encuentra al menos dos casos de uso de empresas que la usen para sostener tu argumento.
Resultados cuantitativos
| Métrica | Tarea 1 | Tarea 2 | Tarea 3 |
| Tasa de éxito | 100% | 100% | 80% |
| Tiempo promedio (s) | 47s | 38s | 92s |
| Errores promedio | 0.4 | 0.2 | 1.6 |
| Satisfacción (1-5) | 4.6 | 4.8 | 4.0 |
El System Usability Scale al cierre de la sesión arrojó un puntaje promedio de
82.5 sobre 100 — por encima del benchmark de 68 que marca la usabilidad “buena”, y muy cerca del umbral “excelente” (≥ 85). Es un resultado prometedor para un MVP académico, aunque la muestra (n = 5) limita su capacidad inferencial.
Hallazgos cualitativos
Lo que funcionó
- La plantilla repetible de la ficha de detalle fue mencionada por 4 de 5 participantes como “fácil de leer una vez que entiendes el patrón”.
- Los filtros HEART como chips redujeron el tiempo de localización de métrica frente a la búsqueda libre, especialmente para los participantes mid-level.
- La asociación color-dimensión se aprendió de forma intuitiva: tras la segunda métrica, los participantes ya anticipaban la dimensión por el color de la tarjeta.
Lo que falló
- Tarea 3 — Casos de uso. Dos participantes intentaron buscar “casos” o “empresas” en el buscador principal antes de entrar al detalle de la métrica. La sección está, pero no es descubrible desde fuera.
- Sidebar de la ficha. Tres participantes no notaron el sidebar de navegación interna en la primera visita. Hicieron scroll lineal en lugar de saltar entre secciones.
- Sección Roles. La marca “In Development” fue interpretada por dos participantes como “esta sección está rota”. La intención (validar interés) no se transmitió.
Iteraciones aplicadas
El testing devolvió el proceso a una mini-iteración de prototipado. Tres ajustes respondieron directamente a los hallazgos:
| Hallazgo | Iteración aplicada |
| Casos de uso poco descubribles | Se añade chip “Casos de empresas” al filtro lateral del catálogo. La búsqueda global ahora indexa nombres de empresas mencionadas en cada ficha. |
| Sidebar de detalle invisible | El sidebar pasa de fondo neutro a fondo lavanda con el ítem activo destacado. En mobile, se convierte en un sticky header con scroll horizontal. |
| "In Development" malinterpretado | Se reformula como “Próximamente: recomendaciones por rol” y se añade un opt-in para recibir aviso cuando esté disponible. Convierte la fricción en señal de interés. |
RESULTADOS Y APRENDIZAJES
Lo que el proyecto enseñó
Datasigners cierra el ciclo académico con un MVP funcional, validado con usuarios reales y puntuado por encima del umbral de buena usabilidad. Más importante que la métrica, sin embargo, fueron los aprendizajes que el proceso dejó sobre cómo trabajar el research y la traducción a producto.
Métricas del proyecto (Datasigners aplicado a sí mismo)
Diseñar un producto sobre métricas obliga a tomar las métricas propias en serio. Estas son las que el MVP propone para la fase 2:
| Dimensión HEART | Métrica | Cómo aplicarla a Datasigners |
| Happiness | Customer Satisfaction (CSAT) | Encuesta breve al cierre de cada sesión: ¿te resultó útil esta ficha? |
| Engagement | Time on Task | Tiempo promedio en una ficha de detalle. Menos de 30 segundos sugiere que la ficha no se está leyendo; más de 4 minutos sugiere que el contenido enganchó. |
| Adoption | Conversion Rate | % de visitantes que llegan al home y cruzan al menos a una de las tres puertas. |
| Retention | User Retention Rate | % de usuarios que vuelven dentro de los 30 días. La hipótesis: una segunda visita implica que el usuario lo trata como herramienta, no como artículo. |
| Task Success | Task Success Rate | Eficacia para encontrar una métrica específica desde el catálogo en menos de 60s (replicable como tarea de usabilidad). |
Decisiones que tomé y volvería a tomar
- Una sola taxonomía. Atravesar todo el producto con HEART eliminó conflictos de modelo mental. Cada vez que estuve tentado de añadir otra clasificación (por industria, por tipo de producto), la simplicidad de tener una sola lente ganó.
- Plantilla repetible. La consistencia de la ficha de detalle es lo que el testing más valoró. Lo que al principio parecía rigidez editorial, terminó siendo el principal driver de usabilidad.
- Decir que no al multilingüe. La diferenciación competitiva del producto está en hablarle a LATAM en español. Añadir inglés habría diluido la apuesta y duplicado el costo editorial.
- Mostrar el “In Development”. Aunque el testing reveló que la marca confunde, mostrar el roadmap visible fue una decisión correcta — solo necesita mejor copy.
Decisiones que volvería a evaluar
- Persistencia local en lugar de cuentas. Cubrió el MVP, pero el testing reveló deseo de sincronización entre dispositivos. El producto futuro probablemente necesite un sistema de cuentas mínimo.
- 13 métricas en el catálogo. Suficientes para probar la hipótesis, pero algunos participantes esperaban un catálogo más exhaustivo. El balance entre profundidad editorial y amplitud del catálogo merece más investigación.
Próximos pasos
Roadmap propuesto para la fase 2 del producto:
| Fase | Hito | Detalle |
| Q1 | Iteración tras testing | Aplicar las 3 iteraciones de UI (chip de empresas, sidebar destacado, copy del In Development). |
| Q2 | Recomendaciones por rol | Activar la sección Roles con lógica básica: cada rol sugiere las 5 métricas más relevantes. |
| Q3 | Sistema de cuentas | Login simple (SSO con Google) para sincronizar guardados y desbloquear personalización. |
| Q4 | Casos LATAM curados | Sustituir progresivamente casos de empresas USA por entrevistas a equipos LATAM. Es la diferenciación competitiva que el research validó. |
REFLEXIÓN PERSONAL
Lo que me llevo
Diseñar un producto que enseña a tomar decisiones con datos me obligó a tomar mis propias decisiones de diseño con datos. Esa simetría entre tema y método fue, sin que yo lo buscara, la mayor lección del proyecto.
Tres reflexiones cierran el caso:
Sobre el research
Las seis entrevistas iniciales me hicieron reformular el problema en la primera semana. Había llegado al proyecto pensando que el usuario necesitaba más información sobre métricas; el research reveló que necesitaba menos información, mejor curada. La diferencia entre esas dos hipótesis es la diferencia entre un producto saturado y un producto útil.
Sobre la priorización
Decidir qué quedaba fuera del MVP fue más difícil que decidir qué entraba. La matriz de Impacto vs Esfuerzo no me dio respuestas; me dio un lenguaje para defender mis decisiones frente al equipo y, sobre todo, frente a mí mismo. Cada feature descartado tiene una justificación rastreable.
Sobre el sistema de diseño
Aprendí que la consistencia visual no es un detalle estético: es el principal vehículo para que el usuario aprenda rápido. La plantilla repetible de la ficha de detalle, los cinco colores HEART y la iconografía sintética hicieron más por la usabilidad del producto que cualquier feature que pudiera haber añadido en su lugar.
"El producto no es la suma de sus features. Es la coherencia del modelo mental que invita al usuario a construir."
— Aprendizaje del proyecto
GRACIAS POR LEER