Сетевой портал для компании в сфере корпоративных сетей

Редизайн портала, через который крупные компании управляют сетями своих офисов, и проверка каждого изменения как гипотезы с конкретной цифрой

Моя роль

Ведущий UX-дизайнер

Работодатель
World Wide Technology
Клиент
Компания в сфере корпоративных сетей
Годы
С 2022 по 2024
Команда
Три продуктовых дизайнера
  1. Руководил тремя продуктовыми дизайнерами, работавшими над сетевым порталом компании в сфере корпоративных сетей.
  2. Вёл Lean UX в команде и проверял его на практике, в проекте по DesignOps: формулировка проблемы исходя из того, что обещали клиентам, гипотеза, цифра которой записывается первой, и общее полевое руководство для тестов.
  3. Руководил дизайном хронологии предупреждений, переиспользуемых шаблонов настройки и таблиц для работы со множеством устройств, и каждое решение сверялось с отслеживанием в рабочем продукте.
  • 8→4 недели на подключение сети нового клиента с переиспользуемыми шаблонами настройки
  • +55% выполненных задач после того, как частые задачи вынесли из меню глубиной в четыре клика
  • 20→1 предупреждений на площадку (примерно) сведены в одну хронологию вместо кучи
  • 8 с в среднем уходило на то, чтобы понять хронологию на тестах; граница провала 30 секунд

Кратко

Компания продаёт сетевые услуги крупному бизнесу, а сетевые инженеры клиентов через её портал следят за десятками тысяч единиц оборудования. Портал уже существовал, и он не работал: настройка сети занимала восемь недель, а когда что-то ломалось, экран заполнялся тысячами предупреждений без малейшего намёка, какое из них важно. Инженеры перестали ему доверять.

У меня было две задачи. Первая касалась самого дизайна. Вторая заключалась в том, чтобы изменить порядок принятия решений в команде, потому что о макетах спорили вместо того, чтобы их проверять. Каждая проблема проходила одни и те же четыре шага внутри спринтов продакт-менеджеров, и каждый результат на этой странице был задан как цель до начала проектирования.

Кто участвовал

  • Сетевые инженеры Сотрудники клиентов, которые управляют сетью и каждый день пользуются порталом.
  • Инженеры по продажам Сотрудники самой компании, которые решают проблемы реальных клиентов; на тестах они выступали вместо клиентов.
  • Продакт-менеджеры Вели спринты и задавали приоритеты; гипотезы работали внутри их циклов.
  • Три продуктовых дизайнера Команда, которой я руководил.
Два вида площадки штаб-квартиры, один поверх другого. Сзади, в тёмном режиме реального времени: Down 1h 5m ago, Edge 2 is offline, связь нарушена на всех каналах, и Circuit 3 is down, затронуто 256 приложений, с кнопками Restart Edge 2, Reconnect Circuit 3 и Start Failover. Спереди, в светлом режиме перемотки: хронология вдоль правого края с отметками предупреждений и ошибок с 13:45 до 14:25, перемотанная на 13:57, где видно Warning 1h 38 mins ago, High Latency and Packet Loss detected on Edge 2, Edge may be approaching capacity и кнопку Return to Live. Воссоздано для этого сайта по поздним макетам интерфейса, а не снимок реального портала, вышедшего в 2024 году.
Одна хронология на площадку. В реальном времени Edge 2 недоступен, затронуто 256 приложений. После перемотки на той же площадке видно предупреждение, которое пришло первым.
Читать материалы . Разделов: 7, около 2 мин

Контекст

Портал уже существовал, и он не работал. Настройка сети занимала восемь недель. Карта сети в реальном времени отображалась пустой. Массовая загрузка, таблица для изменения многих устройств разом, не работала ни разу. Обычные сценарии прятались на глубине четырёх и более кликов, в меню внутри меню. Когда что-то ломалось, экран заполнялся тысячами предупреждений без малейшего намёка, какое из них важно.

Инженеры, которые им пользовались, перестали ему доверять. Такой сбой никогда не попадает в баг-репорты, поэтому ещё один раунд редизайна на основе мнений тоже его бы не нашёл. Команде нужен был способ понять, до и после каждого изменения, помогло ли оно.

Формулировка проблемы

Договор обещает то, что мы обязались дать. Сейчас портал в чём он подводит. Под угрозой оказывается то, что стоит на кону. Мы поймём, что проблема решена, когда появится сигнал.

Заполнено для мониторинга

Договор обещает мониторинг, который позволяет клиентам находить, понимать и устранять проблемы в своей сети. Сейчас портал заполняет экран тысячами предупреждений без намёка на то, какое из них важно. Под угрозой оказывается доверие инженеров к порталу. Мы поймём, что проблема решена, когда инженер сможет назвать упавший канал меньше чем за 30 секунд.

Каждую продуктовую проблему записывали в таком виде до того, как она попадала в дизайн, отталкиваясь от того, что было обещано клиенту. Здесь обещание взято из собственного предложения компании по мониторингу, в котором требовались экраны, позволяющие клиентам разобраться в любой возникшей проблеме и устранить её.

Исследование

Прежде чем кто-то начинал проектировать, каждая проблема превращалась в гипотезу с цифрой, которая её подтвердит или опровергнет. Затем дизайнеры, продакт-менеджеры и инженеры превращали эту цифру в вопросы, на которые человек может ответить вслух, и хранили их в общем полевом руководстве.

Шаблон гипотезы

Мы считаем, что если дать эту функцию людям, которые заняты этой задачей, мы добьёмся этого результата. Мы поймём, что правы, по этому сигналу.

Заполнено для хронологии предупреждений

Мы считаем, что если дать одну хронологию предупреждений на каждую площадку людям, которые заняты разбором ситуации, когда часть сети выходит из строя, мы добьёмся быстрого поиска причины сбоя. Мы поймём, что правы, по тому, что инженер находит причину меньше чем за 30 секунд.

Каждый макет начинался с этого предложения, и последний пропуск заполняли до того, как кто-то открывал файл с дизайном. Сигнал записывали первым, чтобы потом никто не мог незаметно поменять, что считается успехом.

Почему в нём нет персоны

Шаблон называет задачу, а не человека, и так было задумано. Я много лет создавал персоны и к тому моменту уже не верил, что они делают то, ради чего их продают. Персона наделяет вымышленного человека возрастом, фотографией и предысторией. Ничто из этого не меняло того, что нужно сетевому инженеру, когда падает часть сети. Меняла задача: что человек пытается сделать, под каким давлением и как он поймёт, что справился. Портал должен был работать для любого, кто сейчас на смене.

Демографические детали к тому же провоцируют домыслы. Как только у воображаемого пользователя появляются возраст, пол или национальность, команды начинают проектировать под стереотип, а не под данные, и исследователи описали эту проблему в том, как используются персоны (Marsden и Haag, CHI 2016). Если бы наше исследование показало, что какие-то свойства пользователей действительно меняют задачу, например язык, на котором они работают, это вошло бы в гипотезу как вывод. Такого ни разу не случилось. Поэтому в шаблоне осталось место только для того, что можно проверить: функции, задачи, результата и сигнала.

Validation Field Guide

Перед сессией

  • Проверяемая гипотеза: мы считаем, что если дать одну хронологию предупреждений на каждую площадку людям, которые заняты разбором ситуации, когда часть сети выходит из строя, мы добьёмся быстрого поиска причины сбоя. Мы поймём, что правы, по тому, что инженер находит причину меньше чем за 30 секунд.
  • Порог успеха, заданный до первой сессии: каждый участник показывает, что понимает экран, меньше чем за 30 секунд. Граница провала: тридцать секунд.
  • Участники: инженеры компании по продажам вместо клиентов. Отмечайте это в каждом результате; если позже их ответы разойдутся с реальными данными, верх берут реальные данные.
  • Попросите разрешения на запись и скажите, как она будет использоваться.

Вступление

  • Спасибо за помощь. Это займёт от 30 до 45 минут.
  • Мы проверяем ранний прототип, а не вас. Здесь ничего не закончено, поэтому критика будет для нас самой полезной.
  • Пожалуйста, рассуждайте вслух по ходу дела. Во время заданий я могу не отвечать на вопросы; вернусь к ним в конце.

Разминка

  • Расскажите о последнем случае, когда что-то сломалось в сети клиента. Как вы об этом узнали?
  • Куда вы посмотрели первым делом и чем сегодня пользуетесь, чтобы найти причину?

Время до понимания (отсчёт начинается, когда появляется экран; граница провала: 30 секунд)

  • Что не так в этой сети, если что-то не так?
  • Каким каналом вы займётесь в первую очередь и почему?
  • Записать: сколько секунд прошло, пока участник показал, что понимает, и был ли ответ верным.

Найти (без подсказок и без кликов за участника)

  • Покажите, как бы вы узнали подробнее о проблеме, которой займётесь первой.
  • Записать: добрался ли до подробностей без помощи, да или нет.

Решение

  • Что сейчас происходит на этом канале и как долго?
  • Вышел ли он за свои пределы? Как вы это поняли?
  • Что бы вы сделали дальше?

Завершение

  • Что вы ожидали увидеть, но не увидели? Что бы вы убрали?
  • Насколько вы уверены в своём первом ответе, от 1 (наугад) до 5 (уверен)?

Дизайн

Мы собрали в одном месте историю предупреждений, показатели в реальном времени и схему устройств. Проблема отображается одним закрашенным участком на карте, а не тысячей сваленных в кучу предупреждений, и у каждой площадки есть хронология её предупреждений, которую можно отмотать назад и снабдить заметками. Переиспользуемые шаблоны заменили неработающую массовую загрузку, а таблицы переделали так, чтобы инженер мог работать сразу со множеством устройств.

Что я делал

Каждая проблема проходила одни и те же четыре шага внутри спринтов, которые уже вели продакт-менеджеры.

  1. 1Сначала записать

    Записать гипотезу и её цифру до того, как кто-то начнёт проектировать. Запись заранее означала, что никто не сможет потом незаметно поменять, что считается успехом.

  2. 2Спросить вслух

    Превратить эту цифру в вопрос, на который человек может ответить вслух: назовите перегруженный канал, назовите упавший, покажите, куда бы вы нажали. Дизайнеры, продакт-менеджеры и инженеры писали такие вопросы вместе в общем полевом руководстве.

  3. 3Проектировать под неё

    Тысячи сваленных в кучу предупреждений превратились в одну хронологию на площадку, которую можно отмотать назад. Переиспользуемые шаблоны заменили неработающую массовую загрузку, а сеть стала отображаться в реальном времени, а не пустым полем.

  4. 4Проверить до разработки

    Инженеры компании по продажам, которые каждый день решают проблемы реальных клиентов, выполняли задания на кликабельном прототипе, а мы оценивали их по тому, что записали заранее.

В разработку шли только макеты, прошедшие проверку. Эти же задания стали встроенным в продукт отслеживанием, поэтому измерения продолжились и после запуска.

Радиальная топология Region US East 1 в тёмной теме: внешнее кольцо значков пограничных устройств вокруг затемнённых сегментов площадок, несколько устройств с оранжевыми значками предупреждения, пунктирные линии, отмечающие затронутый маршрут, и центр с красным кольцом и надписью 1 site-wide error. Воссоздано для этого сайта по поздним макетам интерфейса, а не снимок реального портала, вышедшего в 2024 году.
Разбор ситуации в виде картины, а не кучи. Красное кольцо на карте региона показывает, где проблема; значки и стили линий показывают, какие соединения в порядке.

Итерации

Инженеры компании по продажам пробовали каждый макет на кликабельном прототипе, а мы засекали, сколько времени им нужно, чтобы показать, что они его поняли. Мы заранее определили 30 секунд как границу, на которой макет проваливается. В среднем вышло 8 секунд, никто и близко не подошёл к границе, а на нескольких сессиях инженеры сами останавливали упражнение, как только понимали идею. Когда в команде были разногласия, мы делали макеты для обеих гипотез и проверяли оба. В разработку шли только макеты, прошедшие проверку.

Как найти неисправность. Тестовое задание на прототипе: назвать перегруженный канал, назвать упавший и показать, куда нажать, чтобы увидеть подробности.
От региона к площадке и к устройству. Одну отмеченную проблему можно проследить от карты региона до устройства, не разыскивая её заново на каждом уровне.

Решение, которое не сработало

Не каждая версия выдержала проверку. Ранний экран устройства показывал его состояние почти только цветом: зелёная галочка на каждом участке сети, зелёные и красные точки за последние 24 часа, шкалы каналов в зелёную, жёлтую и красную полоску и улыбающийся или грустный смайлик для оценки каждого канала. Когда всё было в порядке, всё и выглядело в порядке. Когда что-то ломалось, экран не говорил, что сломалось и что с этим делать. Приходилось искать красное, а примерно каждый двенадцатый мужчина плохо отличает этот красный от зелёного.

Более поздняя версия, та, что в начале этой страницы, сохранила цвет, но перестала на него опираться. У каждой проблемы есть значок и слово, Warning или Down, линии между элементами рисуются сплошными, оранжевыми или пунктирными, а самая свежая проблема описана предложением, и кнопки для её устранения находятся прямо под ним.

Ранний экран одного пограничного устройства: схема связности с зелёной галочкой на каждом узле, полоса за 24 часа из зелёных и красных точек, полосы состояния каналов в зелёную, жёлтую и красную полоску и улыбающийся или грустный смайлик рядом с оценкой каждого канала. Устройство отмечено как Up, хотя на его полосе за 24 часа видны красные сбои.
До: состояние, переданное цветом. Зелёные галочки, красные и зелёные точки, полосатые шкалы. Экран говорит, что что-то не так, но не говорит, что именно и что делать дальше.

Результаты

Те же тестовые вопросы стали встроенным отслеживанием в рабочем портале, поэтому измерения продолжились и после запуска. Около 20 предупреждений свелись к одному на площадку, и инженеры находили причину меньше чем за 30 секунд, как и требовала цель, записанная до начала проектирования.

  • 8 → 4 недели

    Переиспользуемые шаблоны настройки вдвое сократили время подключения сети нового клиента.

  • +55%

    Доля выполненных задач выросла, когда частые задачи вынесли из меню глубиной в четыре и более кликов.

  • 3 дизайнера

    Я руководил тремя продуктовыми дизайнерами; каждый макет начинался с гипотезы, у которой первой шла цифра.

Ретроспектива: что нужно, чтобы практика прижилась

Привычка не пережила моего ухода. Пока я был в команде, мы сначала записывали гипотезы и работали по полевому руководству, и именно оттуда взялись цифры выше. Когда я ушёл, команда перестала так делать.

Всё упёрлось в инвестиции и риски, а дизайн, продукт и разработка оценивали их по-разному. Разработке был нужен интерфейс, который её люди могут сами строить и поддерживать, поэтому компания выбрала PrimeVue, бесплатный набор готовых компонентов для Vue.js, фреймворка, на котором работал портал. Решение было разумным: низкая стоимость, низкий риск и в пределах того, что команда могла поддерживать в 2024 году.

Давление со стороны продукта в тот год касалось скорости. Только что появилась разработка с помощью ИИ, и все стремились выпускать быстрее. Дизайн настаивал, что скорость держится только тогда, когда система записана: формализованная дизайн-система с понятными правилами, кто и как её меняет. Это требует времени на старте, и компания решила потратить его на другое.

Я также предлагал единое место, где решение, данные в его пользу и версия, в которой оно вышло, хранились бы вместе. Предложение не приняли. В следующий раз я подал бы его как риск для дорожной карты, на языке продукта и разработки, и нашёл бы спонсора среди руководителей до того, как менять порядок работы команды, а не после того, как пришли цифры.

Что говорила моя команда

  • Бобби брался за всё, от повседневных задач до сложных функций. Он всегда держит в фокусе пользователя, будь то разработка концепции или юзабилити-тестирование. Благодаря его усилиям у наших клиентов и у нашей команды дизайнеров появилось настоящее понимание направления.

    Продуктовый дизайнер Команда дизайна

  • Работать с Бобби было большой удачей. Он сыграл ключевую роль для [компании], неизменно выдавая результат и налаживая общение между нашими командами. Его ежедневное участие повысило и скорость работы, и боевой дух, даже при преимущественно удалённом формате.

    Продакт-менеджер Команда клиента

  • Работать с Бобби было честью, и мне жаль, что мы не смогли удержать его так долго, как хотели. Как бы то ни было, его вклад в упрощение подключения клиентов и в продвижение дизайн-операций неоспорим. Мы благодарны за путь, который он проложил.

    Директор по разработке ПО Команда клиента