Un portal de red para una empresa de redes corporativas

Rediseñar el portal que usan las grandes empresas para gestionar las redes de sus oficinas, y probar cada cambio como una hipótesis con una cifra asociada

Mi papel

Diseñador UX líder

Empleador
World Wide Technology
Cliente
Una empresa de redes corporativas
Años
2022 a 2024
Equipo
Tres diseñadores de producto
  1. Dirigí a tres diseñadores de producto en el portal de red de una empresa de redes corporativas.
  2. Llevé Lean UX al equipo y lo puse a prueba, en un proyecto de DesignOps: un enunciado del problema construido a partir de lo prometido a los clientes, una hipótesis con su cifra escrita primero y una guía de campo compartida para las pruebas.
  3. Dirigí el diseño de la cronología de avisos, las plantillas de configuración reutilizables y las tablas para muchos dispositivos, cada una comprobada con el seguimiento en el producto real.
  • 8→4 semanas para incorporar la red de un cliente nuevo, con plantillas de configuración reutilizables
  • +55% de finalización de tareas cuando las tareas comunes salieron de menús de cuatro clics de profundidad
  • 20→1 avisos por sede, más o menos, se convirtieron en una cronología en lugar de un montón
  • 8 s tiempo medio para entender la cronología en las pruebas, frente a un límite de fracaso de 30 segundos

Resumen

Una empresa de redes corporativas vende conectividad a grandes compañías, y los ingenieros de red de esas compañías usan su portal para vigilar decenas de miles de equipos. El portal ya existía, y no funcionaba: configurar una red llevaba ocho semanas, y cuando algo se rompía la pantalla se llenaba de miles de avisos sin ninguna pista de cuál importaba. Los ingenieros dejaron de confiar en él.

Tenía dos trabajos. Uno era el propio diseño. El otro era cambiar la forma en que el equipo decidía, porque los diseños se discutían en lugar de probarse. Cada problema pasaba por los mismos cuatro pasos dentro de los sprints de los gerentes de producto, y cada resultado de esta página se fijó como objetivo antes de que nadie diseñara.

Quiénes participaron

  • Ingenieros de red La gente de los clientes que opera la red y usa el portal a diario.
  • Ingenieros de ventas Los de la propia empresa, que resuelven problemas de clientes reales; ocuparon el lugar de los clientes en las pruebas.
  • Gerentes de producto Llevaban los sprints y fijaban las prioridades; las hipótesis funcionaban dentro de sus ciclos.
  • Tres diseñadores de producto El equipo que dirigí.
Dos vistas de una sede central, una superpuesta a la otra. Detrás, en la vista oscura en vivo: Down 1h 5m ago, Edge 2 is offline, que interrumpe la conectividad en todos los circuitos, y Circuit 3 is down, que afecta a 256 aplicaciones, con Restart Edge 2, Reconnect Circuit 3 y Start Failover. Delante, en la vista clara rebobinada: la cronología en el borde derecho, marcada de 13:45 a 14:25 con avisos y errores, retrasada hasta las 13:57, que muestra Warning 1h 38 mins ago, High Latency and Packet Loss detected on Edge 2, Edge may be approaching capacity y un botón Return to Live. Reconstruido para este sitio a partir de maquetas tardías de la interfaz, no es una captura del portal real, que se lanzó en 2024.
Una cronología por sede. En vivo, Edge 2 está caído y hay 256 aplicaciones afectadas. Rebobinada, la misma sede muestra el aviso que llegó primero.
Leer el expediente . 7 secciones, unos 2 min

Contexto

El portal ya existía, y no funcionaba. Configurar una red llevaba ocho semanas. El mapa en vivo de la red aparecía vacío. La carga masiva, una hoja de cálculo pensada para cambiar muchos dispositivos a la vez, nunca había funcionado. Los flujos comunes estaban a cuatro o más clics de profundidad, en menús dentro de menús. Cuando algo se rompía, la pantalla se llenaba de miles de avisos sin ninguna pista de cuál importaba.

Los ingenieros que lo usaban dejaron de confiar en él. Ese tipo de fallo nunca aparece como un informe de error, así que otra ronda de rediseño basada en opiniones tampoco lo habría encontrado. El equipo necesitaba una forma de saber, antes y después de cada cambio, si el cambio había ayudado.

El enunciado del problema

El contrato promete lo que nos comprometimos a dar. Hoy el portal en qué se queda corto. Eso pone en riesgo lo que está en juego. Sabremos que está arreglado cuando la señal.

Completado para la monitorización

El contrato promete una monitorización que permite a los clientes encontrar, entender y resolver los problemas de su red. Hoy el portal llena la pantalla de miles de avisos sin ninguna pista de cuál importa. Eso pone en riesgo la confianza de los ingenieros en el portal. Sabremos que está arreglado cuando un ingeniero pueda nombrar el circuito caído en menos de 30 segundos.

Cada problema de producto se escribía de esta forma antes de pasar a diseño, partiendo de lo que se le había prometido al cliente. Aquí la promesa viene de la propia propuesta de monitorización de la empresa, que pedía pantallas que permitieran a los clientes investigar y resolver cualquier problema que surgiera.

Investigación

Antes de que nadie diseñara nada, cada problema se convertía en una hipótesis con la cifra que la resolvería. Diseñadores, gerentes de producto e ingenieros convertían después esa cifra en preguntas que una persona pudiera responder en voz alta, y las guardaban en una guía de campo compartida.

La plantilla de hipótesis

Creemos que dar esta función a quienes hacen este trabajo logrará este resultado. Sabremos que tenemos razón cuando veamos esta señal.

Completada para la cronología de avisos

Creemos que dar una cronología de avisos por sede a quienes hacen el triaje cuando falla parte de la red logrará encontrar rápido la causa de una caída. Sabremos que tenemos razón cuando veamos que un ingeniero encuentra la causa en menos de 30 segundos.

Cada diseño empezaba con esta frase, con el último espacio en blanco completado antes de que nadie abriera un archivo de diseño. Escribir primero la señal significaba que nadie podía cambiar después, sin que se notara, lo que significaba el éxito.

Por qué no incluye una persona

La plantilla nombra un trabajo, no a una persona, y fue a propósito. Llevaba años creando personas, y a esas alturas ya no creía que hicieran el trabajo para el que se venden. Una persona le da a alguien inventado una edad, una foto y una historia. Nada de eso cambiaba lo que necesitaba un ingeniero de redes cuando se caía parte de la red. Lo que lo cambiaba era el trabajo: qué intentaban hacer, bajo qué presión y cómo sabrían que lo habían hecho. El portal tenía que funcionar para quien estuviera de turno.

Los datos demográficos, además, invitan a hacer suposiciones. En cuanto un usuario imaginario tiene edad, género o nacionalidad, los equipos empiezan a diseñar para el estereotipo en lugar de para las pruebas, un problema que los investigadores han documentado en cómo se usan las personas (Marsden y Haag, CHI 2016). Si nuestra investigación hubiera mostrado que algo de quiénes eran los usuarios cambiaba de verdad el trabajo, como el idioma en que trabajaban, habría entrado en la hipótesis como un hallazgo. Nunca ocurrió. Así que la plantilla solo dejaba espacio para lo que podíamos probar: la función, el trabajo, el resultado y la señal.

Validation Field Guide

Antes de la sesión

  • Hipótesis que se prueba: creemos que dar una cronología de avisos por sede a quienes hacen el triaje cuando falla parte de la red logrará encontrar rápido la causa de una caída. Sabremos que tenemos razón cuando veamos que un ingeniero encuentra la causa en menos de 30 segundos.
  • Umbral de éxito, fijado antes de la primera sesión: cada participante demuestra que entiende la pantalla en menos de 30 segundos. Treinta segundos es el límite del fracaso.
  • Participantes: los ingenieros de ventas de la empresa, en lugar de clientes. Anótelo en cada resultado; si más adelante ellos y los datos reales no coinciden, ganan los datos reales.
  • Pida permiso para grabar y diga cómo se usará la grabación.

Introducción

  • Gracias por ayudarnos. Esto lleva entre 30 y 45 minutos.
  • Estamos probando un prototipo temprano, no a usted. Nada de esto está terminado, así que las críticas son lo más útil que nos puede dar.
  • Por favor, piense en voz alta mientras avanza. Puede que no responda preguntas durante las tareas; volveré a ellas al final.

Calentamiento

  • Cuénteme la última vez que algo se rompió en la red de un cliente. ¿Cómo se enteró?
  • ¿Qué miró primero y qué usa hoy para encontrar la causa?

Tiempo hasta entender (el reloj arranca cuando aparece la pantalla; 30 segundos es el límite del fracaso)

  • ¿Qué falla en esta red, si es que falla algo?
  • ¿De qué línea se ocuparía primero y por qué?
  • Anotar: segundos hasta que demostró que lo entendía y si su respuesta fue correcta.

Encontrarlo (sin pistas y sin hacer clic por la persona)

  • Muéstreme cómo averiguaría más sobre el problema del que se ocuparía primero.
  • Anotar: llegó al detalle sin ayuda, sí o no.

Decidir

  • ¿Qué está pasando en esta línea ahora mismo y desde cuándo?
  • ¿Ha superado sus límites? ¿Cómo lo sabe?
  • ¿Qué haría a continuación?

Cierre

  • ¿Qué esperaba ver que no estaba? ¿Qué quitaría?
  • ¿Qué tan seguro está de su primera respuesta, del 1 (adivinando) al 5 (seguro)?

Diseño

Reunimos en un solo lugar el historial de avisos, las cifras en vivo y una imagen de los dispositivos. Un problema aparece como una sola zona sombreada en el mapa en lugar de mil avisos apilados, y cada sede tiene una cronología de sus avisos que se puede rebobinar y anotar. Las plantillas reutilizables sustituyeron a la carga masiva que no funcionaba, y las tablas se rehicieron para que un ingeniero pudiera actuar sobre muchos dispositivos a la vez.

Lo que hice

Cada problema pasaba por los mismos cuatro pasos, dentro de los sprints que ya llevaban los gerentes de producto.

  1. 1Escribirlo primero

    Escribir la hipótesis y su cifra antes de que nadie empiece a diseñar. Escribirla primero significaba que nadie podía cambiar después, sin que se notara, lo que significaba el éxito.

  2. 2Preguntarlo en voz alta

    Convertir esa cifra en una pregunta que una persona pueda responder en voz alta: nombre el circuito sobrecargado, nombre el que está caído, muéstreme dónde haría clic. Diseñadores, gerentes de producto e ingenieros las escribieron juntos en una guía de campo compartida.

  3. 3Diseñar frente a ella

    Miles de avisos apilados se convirtieron en una cronología por sede que se podía rebobinar. Las plantillas reutilizables sustituyeron a la carga masiva que no funcionaba, y la red se dibujaba en vivo en lugar de quedarse en blanco.

  4. 4Probar antes de construir

    Los ingenieros de ventas de la empresa, que resuelven problemas de clientes reales a diario, probaron las tareas en un prototipo clicable mientras los puntuábamos frente a lo que habíamos escrito.

Solo se construyeron los diseños que pasaron la prueba. Esas mismas tareas se convirtieron en el seguimiento integrado en el producto, así que la medición continuó después del lanzamiento.

Topología radial Region US East 1 en modo oscuro: un anillo exterior de iconos de dispositivos edge alrededor de segmentos de sede atenuados, varios dispositivos marcados con distintivos de aviso naranjas, rutas discontinuas que trazan el recorrido afectado y un centro con un anillo rojo que dice 1 site-wide error. Reconstruido para este sitio a partir de maquetas tardías de la interfaz, no es una captura del portal real, que se lanzó en 2024.
El triaje como imagen, no como montón. Un anillo rojo en el mapa de la región muestra dónde está el problema; los iconos y los estilos de línea muestran qué conexiones están sanas.

Iteración

Los ingenieros de ventas de la empresa probaron cada diseño en un prototipo clicable mientras cronometrábamos cuánto tardaban en demostrar que lo entendían. Habíamos fijado 30 segundos como la línea en la que un diseño fracasaba. La media fue de 8 segundos, nadie se acercó al límite, y en varias sesiones los propios ingenieros de ventas detuvieron el ejercicio en cuanto entendieron la idea. Cuando el equipo no estaba de acuerdo, construíamos ambas hipótesis y probábamos las dos. Solo se construyeron los diseños que pasaron la prueba.

Encontrar lo que está roto. La tarea de prueba en el prototipo: nombrar el circuito sobrecargado, nombrar el que está caído y mostrar dónde haría clic para ver el detalle.
De la región a la sede y al dispositivo. Un problema señalado se sigue desde el mapa de la región hasta el dispositivo, sin tener que buscarlo de nuevo en cada nivel.

Un diseño que no funcionó

No todas las versiones resistieron. Una pantalla de dispositivo anterior indicaba cómo estaba un dispositivo casi solo con el color: una marca verde en cada parte de la red, puntos verdes y rojos a lo largo de las últimas 24 horas, barras de circuito a rayas verdes, amarillas y rojas, y una cara sonriente o triste para la puntuación de cada circuito. Cuando todo iba bien, se veía bien. Cuando algo se rompía, la pantalla no decía qué se había roto ni qué hacer. Había que buscar el rojo, y aproximadamente uno de cada doce hombres no distingue con facilidad ese rojo del verde.

La versión posterior, la de arriba en esta página, mantuvo el color pero dejó de apoyarse en él. Cada problema lleva un icono y una palabra, Warning o Down, las líneas entre las partes se dibujan continuas, naranjas o discontinuas, y el problema más reciente se explica en una frase con los botones para resolverlo justo debajo.

Una pantalla de dispositivo anterior para un dispositivo edge: un diagrama de conectividad con una marca verde en cada nodo, una franja de 24 horas de puntos verdes y rojos, barras de salud de los circuitos a rayas verdes, amarillas y rojas, y una cara sonriente o triste junto a la puntuación de cada circuito. El dispositivo aparece como Up aunque su franja de 24 horas muestra fallos en rojo.
Antes: la salud contada con colores. Marcas verdes, puntos rojos y verdes, barras a rayas. Dice que algo va mal, pero no qué, ni qué hacer después.

Resultados

Las mismas preguntas de prueba se convirtieron en el seguimiento integrado en el portal real, así que la medición continuó después del lanzamiento. Unos 20 avisos se redujeron a uno por sede, y los ingenieros encontraban la causa en menos de 30 segundos, el objetivo escrito antes de diseñar.

  • 8 → 4 semanas

    Las plantillas de configuración reutilizables redujeron a la mitad el tiempo para incorporar la red de un cliente nuevo.

  • +55%

    La finalización de tareas subió cuando las tareas comunes salieron de menús de cuatro o más clics de profundidad.

  • 3 diseñadores

    Dirigí a tres diseñadores de producto; cada diseño empezaba como una hipótesis con su cifra por delante.

Retrospectiva: lo que hace falta para que una práctica se mantenga

El hábito no sobrevivió a mi paso por allí. Mientras estuve en el equipo, escribíamos primero las hipótesis y trabajábamos con la guía de campo, y de ahí salieron las cifras de arriba. Cuando me fui, el equipo dejó de hacerlo.

Todo se redujo a inversión y riesgo, y diseño, producto e ingeniería los valoraban de forma distinta. Ingeniería necesitaba una interfaz que su propia gente pudiera construir y mantener, así que la empresa eligió PrimeVue, un kit gratuito de piezas listas para usar en Vue.js, el framework sobre el que funcionaba el portal. Fue una decisión razonable: bajo costo, bajo riesgo y dentro de lo que el equipo podía mantener en 2024.

La presión de producto ese año era la velocidad. Acababa de llegar la ingeniería asistida por IA, y el empuje era producir más rápido. El argumento de diseño era que la velocidad solo se sostiene cuando el sistema está por escrito: un sistema de diseño codificado, con reglas claras sobre quién lo cambia y cómo. Eso cuesta tiempo al principio, y la empresa decidió dedicarlo a otras cosas.

También propuse un único lugar donde una decisión, las pruebas que la respaldaban y la versión en la que se lanzó estuvieran juntas. No se adoptó. La próxima vez plantearía ese caso como un riesgo para la hoja de ruta, en los términos de producto e ingeniería, y buscaría un patrocinador ejecutivo antes de cambiar la forma de trabajar de un equipo, no después de que llegaran las cifras.

Lo que dijo mi equipo

  • Bobby se ocupó de todo, desde las tareas del día a día hasta funciones complejas. Siempre mantiene el foco en el usuario, ya sea en la conceptualización o en las pruebas de usabilidad. Gracias a su esfuerzo, nuestros clientes y nuestro equipo de diseño tienen un verdadero sentido de dirección.

    Diseñador de producto Equipo de diseño

  • Agradezco haber trabajado con Bobby. Ha sido clave para [la empresa], cumpliendo siempre y tendiendo puentes de comunicación entre nuestros equipos. Su presencia diaria mejoró nuestra velocidad y nuestra moral, incluso trabajando principalmente en remoto.

    Gerente de producto Equipo del cliente

  • Fue un honor trabajar con Bobby, y siento que no pudiéramos retenerlo tanto como queríamos. Aun así, su impacto en agilizar la incorporación de clientes y en impulsar las operaciones de diseño es innegable. Agradecemos el camino que marcó.

    Director de Ingeniería de Software Equipo del cliente