Decidir qué probar primero en el registro de equipos de la red de una compañía eléctrica
Un taller de Lean UX para ayudar a una gran compañía eléctrica a decidir qué arreglar primero en la herramienta que registra los equipos de su red
Mi papel
Diseñador UX líder
- Empleador
- World Wide Technology
- Cliente
- Una gran compañía eléctrica
- Cuándo
- Junio y julio de 2022
- Formato
- Cinco días en línea, once personas
- Fui el coach de uno de los dos equipos pequeños en un taller de Lean UX de cinco días, el que trabajaba en las interrupciones del servicio.
- Dibujé los wireframes de las dos ideas que eligieron los equipos y narré los storyboards, ilustrados con una biblioteca de recursos para talleres que había ayudado a crear en World Wide Technology.
- Fui coautor del cuaderno de taller de 83 páginas que se llevó la compañía: las hipótesis priorizadas, las personas, los mapas de recorrido, los storyboards y los wireframes.
- Extendido nuestro contrato, después de que la compañía llevó las diez hipótesis principales a su siguiente sprint
- 19→10 hipótesis priorizadas hasta quedar diez, la mayoría con su umbral de éxito escrito antes de cualquier prueba
- La mitad de las diez primeras trataban de conectar la herramienta con otros sistemas, no de pantallas
- 2 ideas bocetadas como storyboards y wireframes: Data Stewardship y el Incident Impact Diagram
Resumen
Una gran compañía eléctrica guarda en una herramienta interna la lista de los equipos que ayudan a operar su red eléctrica, y las normas de fiabilidad exigen que esa lista sea correcta. Agregar y actualizar registros se había vuelto tan engorroso que la gente copiaba los datos y trabajaba con ellos en otro sitio, así que la lista oficial se iba quedando atrás.
Nuestro trabajo no era rediseñar la herramienta. Era sentarnos con las personas que la gestionan y la usan, averiguar qué correcciones valía la pena construir y dejarles una forma de hacerlo por su cuenta la próxima vez.
Quiénes participaron
- Partes interesadas Los responsables con verdadera voz sobre el rumbo de la herramienta.
- Especialistas en la red Expertos que conocen la red eléctrica.
- Usuarios del día a día Personas que usan la herramienta a diario para mantener la lista de equipos.
- Dos equipos pequeños Las once personas de la sala se dividieron en dos; yo fui el coach del que trabajaba en las interrupciones.
Leer el expediente .
Contexto
La herramienta interna de la compañía registra todos los dispositivos de red, computadoras, programas y bases de datos que ayudan a operar su red eléctrica. Las normas de fiabilidad de la red exigen que esa lista sea correcta.
La herramienta cumplía con lo básico. Pero a medida que los registros se hacían más detallados, la gente empezó a evitarla y a trabajar con copias en otros sitios. Cada copia dejaba la lista oficial más atrás, y la gente confiaba cada vez menos en los datos y en la herramienta. Eso ponía en riesgo la seguridad de la red y la capacidad de la compañía de cumplir esas normas.
Investigación
Antes del taller, nos sentamos con el directivo que lo pagaba y con los expertos para acordar, en una sola frase, el problema que íbamos a resolver. También anotamos 20 cosas que todos daban por hechas sobre el negocio y sus usuarios, y valoramos cada una según lo que importaba y lo arriesgado que sería equivocarse.
En el taller, cada equipo creó una persona, un usuario inventado pero típico en el que toda la sala estuvo de acuerdo: Sean, una ingeniera de telecomunicaciones que mantiene al día los registros de equipos, y Jason, un analista que resuelve las interrupciones a medida que ocurren. Cada equipo dibujó un mapa de recorrido de la semana de una persona. El mismo patrón aparecía una y otra vez: alivio cuando se terminaba un trabajo y preocupación cada vez que no estaban seguros de que los datos fueran correctos.
Cada punto es una creencia, situada según cuánto importaba y cuánto sabíamos de verdad. La esquina superior derecha es donde equivocarse dolería más y donde menos sabíamos, así que la investigación empezó por ahí. Dos creencias quedaron ahí.
- Se sostuvo
- Se sostuvo en parte
- No se sostuvo
- Nunca se probó
| ID | Supuesto | Certeza | Importancia | Estado |
|---|---|---|---|---|
| A1 | People copy equipment data out of the tracker to work on it elsewhere because adding and updating records in the tool is too clumsy. | High | Critical | ExploratoryParticipants described this in the workshop, and it framed the whole problem, but nobody measured it. |
| A2 | People who keep the equipment list trust it less whenever they can't be sure a record is right. | Medium | High | ExploratoryBoth journey maps showed relief when a job got done and worry whenever the data might be wrong, drawn from what participants said. |
| A3 | An outage diagram showing every affected service and connected device would cut half an hour off a typical outage fix for analysts like Jason. | Low | Critical | Not testedIt passed if someone could explain an outage's full damage in under five minutes; the utility got the test, and we have no result. |
| A4 | Letting analysts attach equipment records from the tracker to Incident Command messages would make outage communication faster and more complete. | Low | Critical | Not testedIt passed if someone could create and send outage details within five minutes in a usability test; no result came back to us. |
| A5 | Showing an accuracy score on each equipment record would help analysts act sooner after an outage report arrives. | Low | High | Not testedIts time target was never filled in and still reads X mins. |
| A6 | Keeping the list of applications open while a record opens beside it would fix Sean's worst moment, going through records one tab at a time. | Medium | High | Not testedThe idea came from Sean's journey map and was sketched as wireframes, but nobody measured it. |
| A7 | Most of the fixes worth building for the tracker would be changes to its screens. | Medium | High | Didn't holdHalf of the top ten hypotheses were about getting the tracker to talk to other systems, like the trouble-ticket system, not about screens. |
Diseño
Los equipos convirtieron los supuestos en 19 hipótesis, conjeturas escritas de forma que se pudieran probar, cada una con el experimento más barato que podía comprobarla y, en la mayoría, lo que contaría como éxito. Las hipótesis de ambos equipos se ordenaron según lo arriesgadas y lo valiosas que parecían, y se quedaron las diez primeras. La hipótesis n.º 2, por ejemplo, prometía quitar media hora a la resolución de una interrupción típica, y se daba por superada si alguien podía explicar todo el alcance de una interrupción en menos de cinco minutos.
Una interrupción real de la red en la última mañana se llevó a varias personas, así que aplazamos una semana la sesión de bocetos (un Design Studio). Convertí esos bocetos en wireframes para dos de las ideas, Data Stewardship, para mantener los registros en orden, y el Incident Impact Diagram, para ver a qué afecta una interrupción, y narré cada una como un storyboard. Los storyboards se dibujan con una biblioteca de recursos para talleres que había ayudado a crear en World Wide Technology, para que un equipo pueda contar la historia de un usuario sin dedicar una semana a ilustrarla.
Resultados
La compañía llevó la lista priorizada de diez hipótesis, la mayoría con su umbral de éxito escrito de antemano, a su siguiente sprint, y extendió nuestro contrato. Los storyboards y wireframes le dieron algo con qué hacer los experimentos más arriesgados. Priorizar la lista también mostró que el supuesto tácito de que la mayoría de las correcciones serían cambios de pantalla no se sostenía. Estuvo bien saberlo antes de que nadie gastara dinero en construir pantallas.
No medimos resultados, y no tengo cifras de las pruebas que hizo la compañía cuando terminó mi parte.
Dos personas: Sean, la ingeniera de telecomunicaciones, y Jason, el analista de interrupciones.
Un enunciado del problema de una sola frase, acordado de antemano con el directivo que pagaba y con los expertos.