Rediseñar una herramienta de monitoreo sin perder lo que funcionaba

La herramienta de monitoreo es un producto que Syniverse vende a operadores de redes móviles. Sus ingenieros lo usan para vigilar el tráfico de roaming en GTPC, GTPU, Diameter, GSM y SIP, y para detectar fallas antes que los clientes. La herramienta anterior corría sobre un framework rentado, así que Syniverse la reconstruyó internamente, dentro del portal de clientes de la empresa, sobre el design system, que ahora evoluciona hacia su siguiente versión.

Hice la auditoría de diseño, diseñé los flujos, los presenté sección por sección a producto e ingeniería para su aprobación e hice el QA de diseño de la construcción.

Abrir imagen completa (se abre en una pestaña nueva)

Quienes lo usan son ingenieros de red y de roaming cuyo trabajo es notar cuándo algo se rompe. El dashboard anterior les daba los datos, pero un muro de bloques de KPI saturados y portlets configurables por separado lo hacía difícil de leer y de personalizar.

El encargo era migrar el núcleo y mejorarlo. El riesgo de toda migración es que «mejorar» se vuelva una capa de pintura. La auditoría de diseño y las entrevistas señalaron cuatro problemas:

• Difícil de escanear. El color seguía el tipo de KPI y de gráfica, no algo en lo que piense un ingeniero.
• Difícil de personalizar. La herramienta no era lo bastante flexible para necesidades distintas.
• Las alarmas eran un portlet más, administradas en una tabla de administración densa.
• Controles inconsistentes. Los portlets de GSM tenían su propio selector de tiempo.

Qué tenía que sobrevivir. Partí de la documentación de funciones del equipo de ingeniería, que inventariaba cada banner, portlet, condición y temporizador.

Cómo lo usaba la gente de verdad. Mi manager y yo hicimos alrededor de 20 entrevistas con un trainer de Syniverse que capacita a equipos de clientes, product managers, desarrolladores y un par de usuarios finales. Nos dijeron qué usaba la gente, qué ignoraba y qué quería ver más, y eso se convirtió en las tres vistas del dashboard. Una salvedad: solo un par de las entrevistas fueron directamente con usuarios finales. El trainer fue nuestro canal más rico hacia el resto.

Área por área. El trabajo se entregó en MVPs, un trimestre a la vez, durante unos dos años. Cada área pasó por una revisión conjunta con PM e ingeniería, donde aprobamos los flujos antes del desarrollo.

Abrir imagen completa (se abre en una pestaña nueva)

Tres vistas para tres audiencias, más Editor Mode

Decidido

Tres vistas predeterminadas con las mismas tarjetas. Network View reúne todo en un lugar para los ingenieros; Executive View da a los gerentes un panorama sin detalle técnico; Display View se configura una vez para pantallas de pared, como un tablero de aeropuerto. Editor Mode permite a cada persona adaptar su dashboard.

Descartado

Un solo dashboard para todos los operadores.

Por qué

Las peticiones de gráficas nuevas no paraban y variaban de un cliente a otro, así que la respuesta fue una herramienta para construir las propias.

Abrir imagen completa (se abre en una pestaña nueva)

Un color por protocolo, a partir de tokens existentes

Decidido

Cada protocolo (GTPC, GTPU, Diameter, GSM, SIP) tiene un color en las tarjetas de KPI, los encabezados de widgets y las gráficas, construido con tokens que el design system ya tenía, dentro de Highcharts, que el producto anterior ya usaba.

Descartado

Una paleta nueva.

Por qué

Un ingeniero distingue a qué protocolo pertenece un widget antes de leer una etiqueta, y se mantiene consistente a medida que el sistema evoluciona hacia su siguiente versión.

Las alarmas tienen su propio lugar

Decidido

Una página dedicada con tarjetas de resumen, la lista completa con interruptores en línea y un detalle que muestra el estado a lo largo del tiempo. El silenciamiento cubre el mantenimiento planeado y los ingenieros pueden reconocer una alarma (Fix/Unfix, individual y masivo).

Descartado

Las alarmas como un portlet más.

Por qué

Los ingenieros necesitaban evitar que las alarmas se dispararan durante el mantenimiento y poder decir «visto y atendido». El reconocimiento viene de la herramienta anterior.

Efecto

El silenciamiento necesitó dos componentes nuevos, un date-time picker y un scheduler, ahora en el design system para todos los proyectos.

Abrir imagen completa (se abre en una pestaña nueva)

Rangos de fechas predefinidos donde los datos no admiten rangos personalizados

Decidido

El dashboard tiene un selector de fechas, pero GTP, Diameter y SIP conservan rangos predefinidos. Los indicadores de tendencia comparan el valor actual con los 15 minutos anteriores, o con el lapso que elija la persona.

Descartado

Un rango personalizado para esos protocolos.

Por qué

Ingeniería me dijo que los conteos de roamers no se pueden calcular con exactitud en rangos arbitrarios. Un control que produce números en los que nadie puede confiar es peor que uno limitado.

• Dashboard: tres vistas predeterminadas, drilldowns por protocolo, configuración de widgets, una vista de mapa para pantalla grande y Editor Mode.
• Alarms: home, log y filtros, favoritos, detalle, creación en cuatro pasos, silenciamiento (recurrente y por rango de tiempo), desactivación, notificaciones en la app y por correo.
• Reports: secciones de resumen y APN, búsqueda avanzada, drilldown de tabla de cuatro niveles, favoritos.
• Query: búsqueda por suscriptor, dos niveles de resultados, consultas guardadas.
• Settings: roaming partners y grupos, causas y grupos de causas.

Las gráficas usan Highcharts, con tipos de gráfica elegidos según la pregunta y el mismo comportamiento de drilldown en todas partes.

Abrir imagen completa (se abre en una pestaña nueva)

Abrir imagen completa (se abre en una pestaña nueva)

Abrir imagen completa (se abre en una pestaña nueva)

Abrir imagen completa (se abre en una pestaña nueva)

Abrir imagen completa (se abre en una pestaña nueva)

No me detuve en la entrega. Cuando la construcción llegó al ambiente de pruebas, busqué diferencias entre los diseños y lo construido y registré cada una como un issue de JIRA. Pasaron a un triage conjunto con PM, front-end, back-end, UX y QA. El proyecto sigue en marcha mientras el design system evoluciona hacia su siguiente versión.

Abrir imagen completa (se abre en una pestaña nueva)

Dashboard y Alarms están en producción y los usan los ingenieros de red de los operadores. El date-time picker y el scheduler diseñados para Alarms ahora forman parte del design system, disponibles para todos los productos de Syniverse.

Una herramienta de monitoreo para operadores no se puede diseñar para «el usuario». Cada cliente quería gráficas distintas, así que la respuesta correcta no era un mejor dashboard predeterminado, sino darle a cada equipo los medios para construir el suyo. De ahí salieron el Editor Mode y el scheduler.

Algunas de mis mejores decisiones vinieron de que ingeniería me dijera lo que los datos no podían hacer, como el límite de los rangos de fechas. En las herramientas de monitoreo, la restricción honesta suele dar mejor diseño que el control flexible.

Los nombres de clientes en las capturas están difuminados.