OKRs para equipos de diseño: objetivos medibles sin perder el criterio
Los OKRs unen las metas del equipo de diseño con las de la empresa mediante resultados clave medibles. Cómo escribirlos y medir resultados, no entregables.
¿Qué son los OKRs y de dónde vienen?
Según Wikipedia, Andrew Grove popularizó el método en Intel en los años setenta, donde se llamaba iMBO, y lo documentó en su libro High Output Management (1983). John Doerr, que asistió a un curso de Grove, lo llevó después a Google. Google lo describe hoy en su guía re:Work como una forma de fijar metas ambiciosas y seguir el progreso, con OKRs anuales y trimestrales.
En su forma básica, el objetivo responde a qué queremos lograr en el próximo trimestre; los resultados clave, a cómo vamos a medir el progreso. Tability lo plantea con las mismas preguntas en términos sencillos, y añade una tercera: qué proyectos son nuestras mejores apuestas para llegar.
Su valor está en la alineación. Si la empresa quiere retener clientes, el equipo de diseño puede tener un objetivo que contribuya a esa meta y que el resto del equipo entienda. Sin ese vínculo, el diseño trabaja en lo que parece más urgente y nadie sabe si sirve.
¿Por qué es difícil para diseño?
Porque el trabajo de diseño es más difícil de cuantificar que el de ventas o marketing. Tability lo dice así: los diseñadores entregan activos creativos que aportan valor al negocio de forma indirecta, y eso no siempre es fácil de medir.
La tentación es escribir resultados que suenan a medición pero son solo actividad: “entregar 30 pantallas”, “realizar cinco pruebas”, “crear un sistema de componentes”. Esos números dicen cuánto se hizo, no si sirvió.
¿Cómo se escribe un buen OKR de diseño?
Un método práctico tiene tres pasos:
- Empieza por el resultado del usuario o del negocio. Pregunta qué debería cambiar para que el trabajo de diseño valga la pena.
- Escribe el objetivo en lenguaje claro. Por ejemplo: “Reducir los problemas de usabilidad que llegan a producción”. Weekdone sugiere que el objetivo responda a “qué esperamos lograr” y que sea inspirador y claro.
- Define unos pocos resultados clave medibles. Wikipedia habla de tres a cinco por objetivo; la guía de Google, de alrededor de tres. Deben ser específicos, medibles, alcanzables, relevantes y con plazo (SMART, según Weekdone). Ejemplo ilustrativo: “Bajar los reportes de problemas de usabilidad de 40 a 20 al mes antes del cierre del trimestre”. Tability propone ejemplos del mismo tipo, como que los problemas de UX sean menos de 20 % de los nuevos reportes de errores.
Tability propone una prueba útil para cada resultado clave: ¿haríamos algo distinto si este resultado se desvía? Si la respuesta es no, hay que afinar el OKR.
¿Cómo se puntúan?
Wikipedia describe una escala de 0.0 a 1.0. Según la misma fuente, un resultado aspiracional apunta a 0.7, mientras que uno comprometido, como entregar un producto o cumplir una fecha, debe llegar a 1.0; Doerr recomienda una tasa de éxito objetivo de 70 % para los resultados clave. La guía de Google re:Work coincide en lo esencial: usa la escala de 0 a 1.0, dice que el punto óptimo está entre 60 y 70 % y que no esperan promediar 1.0, porque las metas se fijan un poco más allá de lo que parece posible.
Lo importante es usar una sola forma en toda la organización y revisar al final del trimestre qué se aprendió, no solo qué puntaje se obtuvo. Google añade que los OKRs no son sinónimo de evaluación de desempeño.
¿Qué diferencia hay entre output y outcome?
La distinción más importante para diseño es esta. Un output es lo que produces: pantallas, prototipos, documentos. Un outcome es el cambio que provoca en las personas o en el negocio. Tanto Weekdone como Tability presentan los OKRs como una forma de mantener un enfoque en resultados y no en producción, para que el equipo no se mida por lo que entrega.
Esta distinción se profundiza en la nota sobre outcomes frente a outputs, que conviene leer antes de escribir los primeros OKRs. Para elegir un indicador que sirva de resultado clave, mira también la métrica norte. Si el resultado clave suena a entregable, probablemente hay que reescribirlo.
Ejemplo
Ejemplo ilustrativo: un equipo de diseño de un banco digital tiene como objetivo “Que los clientes completen la apertura de cuenta sin llamar a soporte”. Sus resultados clave son tres: bajar la tasa de abandono en el paso de verificación de identidad de 35 % a 20 % en el trimestre, reducir las consultas de soporte sobre documentos a menos de 50 por semana, y lograr que el 80 % de los usuarios de prueba completen el flujo sin ayuda. Las pantallas que el equipo entregue son el medio, pero no aparecen en los resultados. Al cierre del trimestre, el equipo revisa qué funcionó y qué no, y decide el siguiente objetivo.
Para tu equipo: revisa tus OKRs actuales y marca los resultados clave que describen entregables. Reescríbelos como cambios en el comportamiento de alguien.
¿Cuándo NO conviene?
- Cuando el equipo es muy pequeño y los objetivos cambian cada semana. Es criterio de práctica, no un dato medido: un marco trimestral no encaja con metas que duran días.
- Cuando la empresa no tiene objetivos claros y el equipo de diseño intenta inventar la estrategia por su cuenta.
- Cuando los OKRs se usan para evaluar personas en lugar de medir el avance del equipo. Google aclara que no son sinónimo de evaluación de desempeño, y Wikipedia señala que muchas organizaciones ya no definen OKRs individuales porque tienden a parecer listas de tareas y a confundirse con evaluaciones.
- Cuando no hay forma razonable de medir el resultado. Entonces conviene empezar con un indicador provisional y revisarlo.
Errores comunes
- Usar resultados que son actividades, como “realizar cinco entrevistas”.
- Tener más de cinco resultados clave por objetivo.
- Escribir objetivos vagos como “mejorar la experiencia”.
- Ignorar la alineación con los objetivos de la empresa.
- No revisar a mitad de trimestre y descubrir al final que el resultado no avanzó.
- Usar la escala de puntuación como evaluación individual.