Что проверять в первую очередь в системе учёта сетевого оборудования энергокомпании
Воркшоп по Lean UX, который помог крупной энергокомпании решить, что в первую очередь исправлять в системе учёта оборудования её энергосети
Моя роль
Ведущий UX-дизайнер
- Работодатель
- World Wide Technology
- Клиент
- Крупная энергокомпания
- Когда
- Июнь и июль 2022 года
- Формат
- Пять дней онлайн, одиннадцать человек
- Был коучем одной из двух небольших команд на пятидневном воркшопе по Lean UX, той, что занималась сбоями.
- Нарисовал вайрфреймы для обеих идей, которые выбрали команды, и написал текст раскадровок, проиллюстрированных библиотекой материалов для воркшопов, которую я помогал создавать в World Wide Technology.
- Стал соавтором 83-страничной книги воркшопа, которую энергокомпания забрала с собой: приоритизированные гипотезы, персоны, карты пути пользователя, раскадровки и вайрфреймы.
- Продлён наш контракт, после того как энергокомпания взяла десять главных гипотез в следующий спринт
- 19→10 гипотез, отобранных в десятку лучших, у большинства порог успеха записан ещё до проверки
- Половина из первой десятки касалась связи системы с другими системами, а не экранов
- 2 идеи, проработанные в раскадровках и вайрфреймах: Data Stewardship и Incident Impact Diagram
Кратко
Крупная энергокомпания ведёт во внутренней системе список оборудования, которое обеспечивает работу её энергосети, и правила надёжности требуют, чтобы этот список был точным. Добавлять и обновлять записи стало настолько неудобно, что люди копировали данные и работали с ними где-то ещё, и официальный список постоянно отставал.
Нашей задачей было не перепроектировать систему. Нужно было сесть с её владельцами и пользователями, понять, какие исправления вообще стоит делать, и оставить им способ решать это самостоятельно в следующий раз.
Кто участвовал
- Заинтересованные стороны Руководители, которые действительно влияют на развитие системы.
- Специалисты по энергосети Эксперты, хорошо знающие энергосеть.
- Повседневные пользователи Люди, которые каждый день ведут в системе список оборудования.
- Две небольшие команды Одиннадцать участников разделились на две группы; я был коучем той, что занималась сбоями.
Читать материалы .
Контекст
Внутренняя система учёта оборудования энергокомпании хранит список всех сетевых устройств, компьютеров, программ и баз данных, которые обеспечивают работу её энергосети. Правила надёжности энергосети требуют, чтобы этот список был точным.
Базовые задачи система выполняла. Но по мере того как записи становились подробнее, люди начали избегать её и работать с копиями в других местах. Каждая копия всё сильнее отдаляла официальный список от реальности, и люди всё меньше доверяли и данным, и самой системе. Под угрозой оказались безопасность энергосети и способность компании выполнять эти правила.
Исследование
Перед воркшопом мы встретились с руководителем, который его оплачивал, и с экспертами, чтобы одной фразой сформулировать проблему, которую решаем. Мы также записали 20 общих допущений о бизнесе и его пользователях и оценили каждое по важности и по тому, насколько рискованно в нём ошибиться.
На воркшопе каждая команда создала персону, вымышленного, но типичного пользователя, с которым согласились все участники: Sean, инженер по телекоммуникациям, которая поддерживает записи об оборудовании в актуальном состоянии, и Jason, аналитик, который разбирается со сбоями по мере их возникновения. Каждая команда нарисовала карту недели одной из персон. Одна и та же картина повторялась: облегчение, когда работа закончена, и тревога каждый раз, когда нет уверенности в правильности данных.
Каждая точка обозначает одно предположение, расположенное по тому, насколько оно было важно и насколько хорошо мы его знали. В правом верхнем углу ошибка обошлась бы дороже всего, а знали мы меньше всего, поэтому исследование началось именно там. В этот угол попало предположений: 2.
- Подтвердилось
- Подтвердилось частично
- Не подтвердилось
- Не проверялось
| ID | Допущение | Уверенность | Важность | Статус |
|---|---|---|---|---|
| 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. |
Дизайн
Команды превратили допущения в 19 гипотез, то есть предположений, сформулированных так, чтобы их можно было проверить, у каждой самый дешёвый эксперимент для проверки и, у большинства, условие успеха. Гипотезы обеих команд ранжировали по рискованности и ценности и оставили первую десятку. Например, гипотеза № 2 обещала сократить устранение типичного сбоя на полчаса и считалась бы подтверждённой, если бы человек смог объяснить весь масштаб сбоя меньше чем за пять минут.
В последнее утро реальный сбой в сети отвлёк нескольких участников, поэтому сессию эскизов (Design Studio) мы перенесли на неделю. Я превратил эти эскизы в вайрфреймы для двух идей: Data Stewardship, чтобы записи оставались в порядке, и Incident Impact Diagram, чтобы видеть, что затрагивает сбой, и описал каждую в виде раскадровки. Раскадровки собираются из библиотеки материалов для воркшопов, которую я помогал создавать в World Wide Technology, чтобы команда могла рассказать историю пользователя, не тратя неделю на иллюстрации.
Результаты
Энергокомпания взяла приоритизированный список из десяти гипотез, у большинства которых порог успеха записан заранее, в следующий спринт и продлила наш контракт. Раскадровки и вайрфреймы дали ей, с чем проводить самые рискованные эксперименты. Ранжирование показало и то, что негласное допущение, будто большинство исправлений сведётся к изменению экранов, не подтвердилось. Хорошо было узнать это до того, как кто-то потратил деньги на разработку экранов.
Результаты мы не измеряли, а цифр по проверкам, которые энергокомпания провела после окончания моей части работы, у меня нет.
Две персоны: Sean, инженер по телекоммуникациям, и Jason, аналитик по сбоям.
Формулировка проблемы в одну фразу, заранее согласованная с руководителем-заказчиком и экспертами.