El problema de los objetivos que no se miden
Cada inicio de trimestre el equipo define objetivos. Suenan bien en la reunión, se escriben en una plantilla y luego viven en un documento que nadie vuelve a abrir hasta la evaluación. Cuando llega el momento de revisar, la pregunta incómoda es siempre la misma: ¿esto se cumplió o no?
Y la respuesta honesta es que no hay forma clara de saberlo.
El problema casi nunca es la falta de objetivos. Es que están redactados sin criterio de éxito, sin un número que mover y sin ningún sitio donde verlos evolucionar semana a semana. Esta herramienta existe para resolver eso.
Qué es un OKR, de verdad
OKR son las siglas de Objective and Key Results: un objetivo cualitativo, inspirador, sin números, más los resultados clave que miden si lo estás consiguiendo.
El Objetivo responde a "¿a dónde queremos llegar?". Debe ser motivador y direccional. No lleva cifras.
Los Key Results responden a "¿cómo sabremos que llegamos?". Miden el resultado, no el trabajo. Se expresan siempre como un movimiento: de X a Y.
Aquí está la trampa más habitual en equipos de diseño:
- Trampa: "Hacer 3 rondas de tests de usabilidad este trimestre."
- OKR real: "Aumentar el porcentaje de tareas completadas sin ayuda del 54% al 75%."
La diferencia es la que separa una lista de tareas de un indicador de impacto. La tarea te dice qué hacer; el Key Result te dice si funcionó. Las iniciativas, el trabajo concreto que haces para mover el KR, van aparte. Son el cómo, no el qué.
Cada objetivo puede tener entre 2 y 5 Key Results. Más de cinco y pierdes el foco.
Cómo se puntúa
Al cerrar un ciclo, cada Key Result recibe una calificación de 0.0 a 1.0.
La norma contraintuitiva de los OKRs aspiracionales es que 0.7 ya es éxito. Si lograste el 70% de un objetivo ambicioso, lo estás haciendo bien. Si siempre llegas a 1.0 en todos tus objetivos, las metas son demasiado fáciles.
Esto cambia radicalmente la conversación. El score no es un examen que apruebas o suspendes, es un diagnóstico para aprender: ¿qué funcionó, qué se bloqueó, qué calibraremos el próximo trimestre?
Esta distinción importa mucho en equipos de diseño: el cierre del ciclo incluye una retrospectiva con ese espíritu. No "¿quién falló?", sino "¿qué aprendimos?".
Dos formas de medir según el rol
Oye, aquí es donde la mayoría de guías de OKRs se quedan cortas. Hablan de métricas como si todas las personas del equipo midieran lo mismo. Y no es así.
Dentro de un equipo de diseño hay dos tipos de trabajo con naturalezas muy distintas, y cada uno necesita un framework de métricas diferente.
HEART: para roles de producto
HEART es un framework de Google (Kerry Rodden) que mide la experiencia del usuario final. Aplica cuando tu trabajo repercute directamente en cómo alguien usa un producto.
Las cinco dimensiones:
- H — Happiness (satisfacción): ¿cómo de satisfecho está el usuario con la experiencia?
- E — Engagement (implicación): ¿con qué frecuencia e intensidad usa el producto?
- A — Adoption (adopción): ¿cuánta gente nueva empieza a usar una feature?
- R — Retention (retención): ¿cuánta gente sigue usándola?
- T — Task success (éxito en tareas): ¿completan las tareas clave sin fricciones?
El proceso para construir un KR con HEART tiene tres pasos: primero defines el Goal (qué quieres mejorar), luego la Signal (qué comportamiento observable indica que vas en esa dirección), y finalmente la Metric, que es tu KR.
Roles que miden con HEART: Product Designer, UX Researcher, Content Designer, Design System Designer, Design Lead.
REACH: para roles de operaciones
REACH es un framework de NN/g (Kate Kaplan) que mide la salud de la función de diseño, no el outcome del usuario. Aplica cuando tu trabajo repercute en cómo funciona el equipo, no en lo que experimenta quien usa el producto.
Las cinco dimensiones:
- R — Results (resultados): ¿el equipo está logrando sus objetivos de negocio y de producto?
- E — Efficiency (eficiencia): ¿los procesos son fluidos o están llenos de fricción?
- A — Ability (capacidad): ¿el equipo tiene las habilidades, herramientas y acceso que necesita?
- C — Clarity (claridad): ¿el equipo entiende bien los objetivos, roles y expectativas?
- H — Health (salud): ¿la cultura, la confianza y la energía del equipo están en buen estado?
REACH no se prueba estadísticamente como las métricas de producto. Funciona triangulando: combinas varias señales para construir una imagen razonablemente fiable del estado de la función.
Roles que miden con REACH: DesignOps, ResearchOps, ContentOps, DesignSystemOps.
Por qué importa tener dos frameworks
Un Product Designer mejora la experiencia de quien usa el producto. Tiene sentido medir con HEART.
Un DesignOps mejora cómo funciona el equipo de diseño. No tiene sentido medir eso con métricas de usuario.
Medir un rol de operaciones con métricas de producto es un error de encuadre: estás evaluando el trabajo con el instrumento equivocado, y los KRs que generas no reflejan realmente lo que ese rol mueve.
Spoiler: la herramienta lo gestiona por ti. Cuando eliges el rol, la app ya sabe qué framework aplicar.
El ritmo: trimestre, semana, cierre
Los OKRs tienen una cadencia que, si la respetas, lo cambia todo.
El ciclo base es trimestral. Un trimestre es lo suficientemente largo para mover métricas reales, y lo suficientemente corto para corregir si algo no funciona.
El seguimiento es semanal. Cada semana actualizas el nivel de confianza de tus Key Results: ¿crees que vas a llegar? Este check-in no lleva mucho tiempo, pero tiene un efecto enorme: si algo empieza a descarrilar, lo ves antes de que sea tarde. La herramienta registra esa evolución en una sparkline que te muestra la tendencia de cada objetivo.
El cierre es una retrospectiva. Al terminar el ciclo, calificas cada KR de 0.0 a 1.0 y te preguntas tres cosas: ¿qué pasó?, ¿qué aprendí?, ¿qué cambiaría el próximo trimestre? Ese momento de reflexión es donde los OKRs pasan de ser un sistema de seguimiento a ser una herramienta de aprendizaje del equipo.
Errores que la herramienta te ayuda a evitar
La metodología OKR tiene trampas conocidas. Esta herramienta tiene avisos integrados para las más habituales:
Set and forget. El error más extendido: defines los objetivos en enero y no vuelves hasta junio. Sin check-ins semanales, los OKRs son solo decoración. La app te recuerda que actualices el seguimiento.
KRs que son listas de tareas. "Completar el rediseño de la pantalla de inicio" no es un Key Result, es una tarea. Si tu KR no tiene un número que se mueve, es probablemente una iniciativa disfrazada. La app tiene avisos para cuando un KR parece más tarea que resultado.
Demasiados objetivos. Si tienes ocho objetivos en un trimestre, en realidad no tienes ninguno. La atención se diluye y nada avanza de verdad. La herramienta está pensada para que elijas 3-4 batallas, no para que lo metas todo.
Métricas de vanidad. El número de pantallas entregadas, la cantidad de componentes en el design system o el número de sesiones de research no dicen nada sobre el impacto. Lo que importa es si esas pantallas mejoraron el flujo, si los componentes redujeron el tiempo de desarrollo, si el research informó decisiones reales.
Atribuir a diseño métricas de negocio puras. Si una empresa vende más o menos este trimestre, diseño puede haber contribuido, pero hay demasiadas variables en la cadena causal. Medir a tu equipo de diseño por el revenue es una cadena tan larga que se vuelve inútil. Elige métricas que diseño pueda mover directamente.
Para qué sirve este recurso (y para qué no)
Seré directo: este recurso no es una herramienta de OKRs corporativa. No tiene integraciones con tu stack, no genera reportes automáticos y no se sincroniza con nada.
Lo que sí hace es ayudarte a pensar bien antes de escribir mal. La mayoría de OKRs de diseño que he visto llegan a Lattice o Perdoo ya deformados: objetivos que son tareas, resultados clave sin baseline, iniciativas disfrazadas de métricas. Este recurso es el paso previo, el borrador honesto que haces para ti antes de escribir en la herramienta oficial.
Sirve si:
- Eres líder de diseño y quieres preparar tus OKRs con criterio antes de la revisión con tu manager.
- Trabajas en un equipo pequeño, freelance o consultora sin una herramienta de OKRs impuesta.
- Quieres aprender a diferenciar un objetivo de un resultado clave, y un resultado clave de una iniciativa.
No sirve si:
- Buscas reemplazar Lattice, Perdoo, Linear o la herramienta que tu empresa ya usa. No lo intentes: sigue donde tu empresa trabaja.
- Quieres que tu equipo colabore aquí. Este espacio es individual y privado. Es tuyo.
- Esperas que el seguimiento se actualice solo. No se actualiza. Si no vuelves cada semana a poner el dato real, no sirve de nada.
Oye, eso no es un defecto. Es honestidad sobre lo que es.
Para quién está pensado
- Líderes de diseño que quieren llevar los OKRs del equipo de manera estructurada, con visión por rol.
- Profesionales de DesignOps, ResearchOps o ContentOps que necesitan demostrar el impacto de su trabajo más allá de las entregas.
- Cualquier diseñadora o diseñador que quiera definir sus propios objetivos con criterio y llevar su propio seguimiento.
No necesitas que tu empresa use OKRs a nivel corporativo para que esto te sea útil. Puedes empezar en tu equipo, en tu rol, este trimestre.
Lo que no es
No es un sistema de evaluación de personas. El score de 0.7 no es una nota, es una señal.
No es una plantilla más que rellenas y olvidas. Sin los check-ins semanales, es solo papel.
No es un tablero de tareas. Si lo que necesitas es gestionar el día a día de tu equipo, esto no es lo que buscas.
Es el sitio donde un objetivo deja de ser una frase y pasa a ser algo con un número, un peso y un avance que puedes mirar cualquier semana del año. Con el framework correcto para tu rol. Y con el cierre que cierra de verdad.