Diseño de paneles de control que impulsan decisiones, no vanidad

Martes, 9:47 p.m. El ping de Slack. "Oye, este informe está mal. Nuestro MRR muestra 4,1 M, pero Finanzas dice 4,3 M. ¿Puede echarle un vistazo?"

Abre el panel de control. No lo ha tocado en siete meses. El campo de propietario dice "Sarah K" y Sarah se fue en octubre. Hay 14 gráficos. Tres de ellos dicen mostrar MRR y todos difieren. El último visitante fue hace tres semanas, y era usted, abriéndolo para compartir el enlace en exactamente este hilo.

Ese ping no es un problema de calidad de datos. Es un problema de diseño. Probablemente su problema de diseño, de una construcción que publicó durante un Sprint que ya ha olvidado.

La mayoría de los BI tools reportan en silencio el mismo número: entre el 60 y el 80 por ciento de los paneles de control se abren menos de cinco veces durante toda su vida útil. Los datos de uso internos de Looker, los registros de administración del servidor de Tableau, las analíticas de adopción de Hex: la misma forma siempre. El cementerio es más grande que el piso activo. Y cada panel de control muerto sigue costándole: gasto en consultas del almacén para la actualización programada, erosión de confianza cuando las partes interesadas encuentran números contradictorios, y su tiempo en el calendario cuando alguien lo resucita a las 9:47 p.m.

Este Playbook es la disciplina de diseño que mantiene su recuento de paneles de control plano o decreciente mientras la confianza de las partes interesadas se acumula. Es habilidad de un IC, no teatro de un proveedor de BI.

Los principios que eliminan el exceso

Antes de cualquier regla específica, tres principios. Si los interioriza, el resto se escribe solo.

Una decisión por panel de control. Escriba la decisión en el título. No "Resumen de Ventas". Eso es un tema, no una decisión. Escriba "¿Debemos revisar la previsión de ventas del Q3?" o "¿Qué pipelines de AE necesitan revisión gerencial esta semana?" Si no puede escribir la decisión en una oración, no sabe para qué sirve el panel de control, y tampoco lo sabrá la persona que lo abra. Los temas se multiplican. Las decisiones no.

Jerarquía visual, no democracia visual. El número principal del panel de control debe ser al menos 3 veces más grande que cualquier otra cosa en la página. Los estudios de seguimiento ocular en BI tools (Tableau Research, 2023) muestran que los usuarios pasan el 60% de sus primeros 8 segundos en el bloque más grande. Si todo tiene el mismo tamaño, le ha dicho al usuario que nada es importante. Elija el número que responde la decisión. Hágalo enorme. Todo lo demás es evidencia de respaldo.

Disciplina de color. Un color de acento para la marca o la métrica principal. Gris para todo lo demás. Rojo y verde solo para la variación respecto a un objetivo, nunca para series categóricas. Si su gráfico de "Ingresos por Región" tiene barras rojas, verdes, azules, amarillas y naranjas, ha condicionado al usuario a que el rojo no significa nada. Luego, cuando el rojo realmente significa "no alcanzamos el plan", no impacta. El color es un presupuesto finito. La mayoría de los analistas lo agota en el primer gráfico.

Estos tres son la base. El resto es aplicación.

La regla de las 5 métricas

Ningún panel de control se publica con más de 5 métricas primarias. Punto.

Esta es la regla que todos cuestionan y que todos se equivocan al cuestionar. El argumento siempre es el mismo: "pero el VP quiere ver X, e Y, y también Z". Bien. Construyalos en algún lugar. Simplemente no en la misma superficie que la decisión.

¿Por qué 5? La investigación sobre la carga cognitiva (Miller, 1956, sí, el estudio del "número mágico siete", refinado por Cowan en 2001 a una capacidad de memoria de trabajo de 4±1) es el límite mínimo. En una reunión, con alguien presentando, con Slack enviando notificaciones, el límite práctico es aún menor. Un panel de control con 14 bloques no se lee. Se escanea. El usuario elige los dos que parecen sorprendentes e ignora el resto. Usted hizo el trabajo de 12 bloques por la atención de 2.

La regla, aplicada:

• Si tiene 5 métricas primarias y alguien pide una 6.ª, está construyendo dos paneles de control. Uno sirve a la Decisión A, el otro a la Decisión B. Divídalo.
• Si no puede decidir cuáles son las 5, no ha decidido qué decisión sirve el panel de control. Vuelva al paso uno.
• Los desgloses detallados no son métricas. Un número principal en el que se puede hacer clic y que abre un desglose es una métrica, no siete. Trate el recuento de bloques visibles como el límite.
• Los bloques de "referencia" (una definición, una marca de tiempo de actualización, un panel de filtro) no cuentan contra las 5. Solo los bloques que una parte interesada lee para tomar la decisión.

He publicado paneles de control con tres métricas. Tres. El CFO los abre semanalmente. He publicado paneles de control con once métricas. El CFO los abrió una vez y me pidió que "resumiera los hallazgos". Ese es el mismo panel de control fallando.

El contexto supera a la visualización, siempre

Aquí está la herejía: un número con un diagnóstico escrito supera a un gráfico hermoso sin narrativa. Siempre.

"MRR: 4,18 M (-4,2% MoM)" con una anotación de una línea ("Baja impulsada por 3 abandonos empresariales en EMEA, los tres marcados en el QBR; la reserva de expansión de 2,1 M compensa a -1,8% neto") es más útil que el gráfico de líneas más bonito del mundo. Porque el gráfico le muestra que algo ocurrió. La anotación le dice qué ocurrió, por qué, y si debe preocuparse.

Convierta esto en una regla para cada bloque que aparezca en un panel de control que un humano leerá: una línea de "qué cambió y por qué". No un párrafo. Una línea. Si no puede escribirla, el bloque no está listo para publicarse.

Esta es la parte que la mayoría de los analistas omite porque se siente como redacción, no como análisis. Es análisis. El acto de escribir "bajó un 4,2% por tres abandonos empresariales en EMEA" le obliga a responder realmente la pregunta en lugar de presentar el gráfico y alejarse. Si la respuesta es "todavía no lo sé", esa también es una anotación válida. "Bajó un 4,2% MoM, causa raíz por determinar antes del viernes, ver #data-investigations" le dice a la parte interesada que usted lo vio, que está trabajando en ello, y que no necesita escribirle. Ese ping que no recibe es la línea de texto con mayor ROI que escribirá en toda la semana.

Herramientas que facilitan esto: las celdas de texto junto a las celdas de gráficos de Hex, el bloque HTML de Looker con un comentario con plantilla, los paneles de control de Tableau con una nota al pie de texto por bloque. Todos ellos admiten el patrón. Ninguno lo aplica. Usted lo aplica.

El análisis posterior al pánico por "este informe está mal"

Eventualmente una parte interesada cuestionará un número. No es opcional. La pregunta es si lo maneja como un profesional o como alguien que intenta ganar un debate en Slack.

Este es el protocolo. Memorícelo. Le salvará la carrera al menos dos veces.

Paso 1. Confirme la recepción en 5 minutos, no en 5 horas. "Recibido, revisando ahora, responderé antes del EOD con lo que encuentre." Ese es el mensaje completo. No defienda. No argumente. No explique por qué su número es correcto antes de haberlo verificado realmente. La ansiedad de la parte interesada baja en el momento en que ve "revisando ahora".

Paso 2. Confirme la consulta. Abra el SQL subyacente. Ejecútelo de nuevo. ¿Reproduce el número del panel de control? Si es así, el panel de control no está mintiendo. Aún queda la pregunta de si la consulta es correcta, pero la superficie es consistente. Si no es así, tiene un problema de caché o de programación; señálelo y actualice.

Paso 3. Confirme la fuente de verdad. ¿Qué dice Finanzas, RevOps o el sistema de registro? ¿Su columna mrr se deriva de subscriptions.amount o de una vista materializada monthly_recurring_revenue construida en 2022 por alguien que ya no está? ¿Finanzas está extrayendo directamente de Stripe mientras usted extrae de una sincronización de Fivetran con 6 horas de retraso? El 90% de los tickets "este informe está mal" se resuelven aquí, y la resolución rara vez es "el panel de control está mal" o "Finanzas está mal". Es "estamos calculando dos cosas ligeramente diferentes y las llamamos con el mismo nombre".

Paso 4. Documente la discrepancia. En la plantilla del análisis posterior, complete: marca de tiempo del informe, consulta utilizada (péguela), valor de la fuente de verdad, valor del panel de control, causa raíz (discrepancia de definición, datos desactualizados o error real), corrección (nueva ejecución, cambio de definición o nueva anotación) y comunicación con la parte interesada.

Paso 5. Publique una corrección o una advertencia en 24 horas. O corrige el problema subyacente, o añade una anotación a nivel de bloque que explica la brecha. Ambas son aceptables. Lo que no es aceptable es dejarlo estar mientras dos partes de la organización siguen operando con números diferentes.

Nunca argumente en hilos de Slack. Los argumentos en hilos son la forma en que los analistas se ganan la reputación de ser "defensivos". Mueva la conversación al documento del análisis posterior en 30 minutos. El documento es el artefacto. El hilo es el ruido.

Mantengo un registro de cada análisis posterior de pánico que he publicado. Releerlos es el mejor ejercicio de desarrollo de habilidades que hago. Puedo ver exactamente qué discrepancias de definición siguen apareciendo (siempre es el reconocimiento de ingresos, siempre) y dónde invertir en correcciones en el origen. Cada pánico también es una señal sobre qué bloque necesita una anotación permanente para que la próxima persona no escriba ese ping.

La tasa de adopción es la métrica que demuestra que el panel de control funciona

El panel de control que construyó el trimestre pasado: ¿está funcionando? La mayoría de los analistas no puede responder esa pregunta, lo cual es extraordinario dado que estamos profesionalmente obsesionados con la medición.

Instrumente la tasa de adopción. Cada BI tool tiene los datos:

• Looker tiene System Activity, un Explore interno. history.query_run_count, dashboard.view_count, user.id, todos consultables.
• Tableau Server, Cloud tiene el proyecto Admin Insights. views_workbooks y views_dashboards le dan las aperturas por activo y por usuario.
• Hex tiene analíticas de uso integradas en la página de configuración del espacio de trabajo.
• Mode tiene la Discovery API y los informes de administración.
• Power BI tiene informes de métricas de uso por espacio de trabajo.

Realice el seguimiento de tres números por panel de control, mensualmente:

1. Visitantes únicos. No aperturas. Personas. Un panel de control con 200 aperturas de 2 visitantes es una pestaña que alguien dejó anclada, no un panel de control funcional.
2. Tiempo en el panel de control. Un panel de control que nadie desplaza es un panel de control que nadie lee. La mayoría de los BI tools registran la duración de la sesión; menos de 30 segundos significa que lo abrieron y lo cerraron.
3. Tasa de visitantes recurrentes. De los visitantes del mes pasado, ¿cuántos regresaron este mes? Los visitantes recurrentes son el público real. Todos los demás vinieron una vez y siguieron adelante.

Un panel de control con menos de 3 visitantes únicos por mes, durante dos meses consecutivos, es candidato para la retirada. No candidato para un "rediseño". Candidato para la retirada. Deje de optimizar cosas que nadie abre.

El ejercicio más útil que realizo trimestralmente: clasificar todos los paneles de control que poseo por recuento de visitantes recurrentes. Los 5 primeros reciben mi tiempo y dedicación. Los 5 últimos reciben una revisión de retirada. Los del medio reciben una negligencia benigna, lo cual está bien. La negligencia es barata, la retirada es honesta, y el cuidado activo es costoso. Gáste donde retorna.

La revisión de retirada a los 6 meses

La retirada es una característica, no un fracaso. Adopte esto y nunca volverá a sentirse mal por eliminar un panel de control.

Cada seis meses, hace el barrido. Reserve medio día. Extraiga los datos de adopción de cada panel de control en su espacio. Ordene por visitantes únicos, de menor a mayor. Luego:

1. Cualquier panel con menos de 3 visitantes al mes durante los últimos 6 meses: archívelo. No elimine. Archive. Muévalo a una carpeta oculta, publique un aviso en #data-archive anunciando lo que se movió, incluya el enlace al archivo. Si alguien protesta, puede restaurarlo en 60 segundos. Nadie protestará. No lo abrían.
2. Cualquier panel con 3-10 visitantes al mes: confirme la propiedad. Escriba al propietario nombrado. "¿Aún es el responsable? ¿Sigue siendo relevante? ¿Tiene todavía una decisión nombrada?" Si el propietario se fue, usted es el nuevo responsable. Decida si vale la pena mantenerlo o enviarlo al archivo. Sin respuesta en una semana, al archivo.
3. Cualquier panel con más de 10 visitantes al mes: manténgalo, audite las anotaciones de los bloques, actualice los números obsoletos y actualice la decisión en el título si el negocio cambió. Estos son su superficie real. Merecen mantenimiento.
4. Publique la lista de eliminaciones públicamente. Un breve mensaje en el canal de datos de la organización: "Barrido completo: se archivaron 12 paneles de control, se mantuvieron 47, aquí está la lista." Suceden tres cosas. (a) Nadie se queja porque nada que realmente usaban desapareció. (b) Otros equipos ven la cadencia y comienzan a hacer la suya. (c) La dirección nota que alguien está tratando la instancia de BI como infraestructura, no como un depósito de basura.

La primera vez que realicé un barrido como este en una empresa anterior, archivé 38 paneles de control. Dos personas me escribieron, ambas sobre el mismo panel de control, que restauré en tres minutos. Esa es toda la superficie de riesgo. La recompensa fue una instancia de BI que cargaba más rápido, tenía resultados de búsqueda más claros y visiblemente menos hilos de Slack del tipo "espera, ¿cuál es el panel de control real de ingresos?".

En seis meses, su instancia de BI debería tener menos paneles de control que hoy. No más. Si tiene más, la disciplina de diseño no está funcionando y se está omitiendo la cadencia de retirada. Ambas son corregibles. Ambas son su responsabilidad.

Plantillas que puede usar

Ficha de especificación de una página para el panel de control. Complete antes de construir:

• Decisión que responde este panel de control: (una oración, termina en verbo)
• Audiencia: (rol nombrado, no "partes interesadas")
• 5 métricas primarias, en orden de importancia: (1, 2, 3, 4, 5)
• Cadencia de actualización: (en tiempo real, por hora, diaria, semanal; que coincida con la velocidad de la decisión)
• Propietario: (persona nombrada, no un equipo)
• Criterios de cierre: ("archivar si menos de 3 visitantes únicos al mes durante 60 días")

Plantilla de análisis posterior al pánico. Complete dentro de las 24 horas de cada cuestionamiento:

• Reportado por, cuándo, en qué canal
• Número esperado por la parte interesada vs. número del panel de control
• Consulta utilizada (pegue el SQL completo)
• Comparación con la fuente de verdad (valor de Finanzas, RevOps o del sistema)
• Causa raíz (definición, actualización, error, error del usuario o realmente correcto)
• Corrección publicada (enlace al PR o a la anotación)
• Comunicación de vuelta a la parte interesada (pegue la respuesta)

Lista de verificación de la revisión semestral. Reserve medio día, realice el barrido:

• Extraiga datos de adopción de todos los paneles de control propios
• Ordene de menor a mayor por visitantes únicos
• Archive: menos de 3 visitantes al mes durante 6 meses
• Confirmación de propiedad: 3-10 visitantes al mes
• Auditoría y actualización: más de 10 visitantes al mes
• Publique la lista de eliminaciones públicamente
• Actualice el registro de retiradas (fecha, recuento archivado, recuento mantenido)

Estos tres documentos representan el 90% de la higiene de los paneles de control. Imprimalos. Péguelos donde pueda verlos. Úselos.

Errores comunes

Algunos patrones que veo repetidamente en todos los equipos:

• Construir a partir de la solicitud, no de la decisión. La parte interesada dice "quiero un gráfico de conversión por fuente". Usted lo construye. Lo publica. Seis semanas después, nadie lo abre, porque la decisión real era "¿debemos seguir pagando el contrato de Google Ads?", y eso requería CAC por fuente más una superposición de retención, no un gráfico de barras de conversión. Siempre pregunte por la decisión antes de escribir el SQL.
• El panel de control ejecutivo con 14 bloques porque el VP "quiere verlo todo". El VP no quiere verlo todo. El VP quiere sentirse informado y detectar las dos sorpresas. Dele un panel de control de 5 bloques con un resumen escrito de una línea en la parte superior, y le dará las gracias. Probablemente lo promoverá, eventualmente.
• Paletas arcoíris. Ocho series, ocho colores, todos con la misma saturación. El usuario no lee nada. Use un acento, gris en todo lo demás, resalte solo la serie de la que depende la decisión.
• Nunca retirar, solo añadir. Esta es la muerte lenta. Cada trimestre, el recuento sube. Cada trimestre, la calidad media del panel de control baja. A los seis meses, la instancia de BI es imposible de buscar y tres paneles de control diferentes dicen tres cosas diferentes sobre el MRR. La solución es la cadencia de barrido. Sin ella, está acumulando deuda técnica indefinidamente.

Cómo es el trabajo bien hecho

Ha interiorizado esto cuando:

• Cada panel de control que posee tiene una decisión nombrada en su título, no un tema.
• Puede enumerar de memoria sus 5 paneles de control con mayor tasa de adopción y sus 5 candidatos a la retirada.
• Los pings de "este informe está mal" disminuyen trimestre a trimestre, porque cada bloque tiene un diagnóstico escrito que la parte interesada lee primero.
• La instancia de BI tiene menos paneles de control en 6 meses que hoy, no más.
• Su documento de análisis posterior al pánico tiene al menos 5 entradas del último año, y puede señalar la corrección en el origen que surgió de cada una.

Ese es el estándar. No "construí más paneles de control". No "a las partes interesadas les encantan mis gráficos". Es: publiqué la superficie que la gente usa, documenté los fracasos y eliminé los que no merecían su lugar.

El diseño de paneles de control no es un ejercicio estético. Es un ejercicio de presupuesto de atención. Cada bloque le cuesta la atención de una parte interesada. Cada panel de control le cuesta su tiempo de mantenimiento. Gaste ambos como si fueran escasos, porque lo son.

Más información

• Gestión de partes interesadas para Data Analysts
• SQL y modelado de datos a escala
• Métricas del Data Analyst: tiempo hasta el hallazgo, tasa de adopción e impacto
• Plantilla de descripción de puesto: Data Analyst