Проверка картографических данных, работающая полностью офлайн

Замена отживающей своё программы для Windows, которая проверяла картографические данные подрядчиков для картографической программы федерального ведомства, на React-приложение на основе собственной дизайн-системы правительства

Моя роль

Старший UX-дизайнер

Работодатель: World Wide Technology
Клиент: Картографическая программа федерального ведомства
Годы: С 2018 по 2020
Команда: Ведущий дизайнер в команде дизайна из четырёх человек, вместе с фронтенд- и Python-разработчиками

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

Дни→часы на проверку пакета картографических данных, по словам подрядчиков; никто не засекал время
2000+ картографических файлов проверено за первый месяц, по собственным подсчётам команды внедрения
40+ элементов интерфейса, которых не хватало в правительственной дизайн-системе, сделанных на React с тестами
WCAG 2.1 AA стандарт доступности соблюдён; проверяли мы сами, инструментами и с программой экранного доступа, без внешнего аудитора

Кратко

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

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

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

Подрядчики Должны были доказать, что в их картографических данных нет ошибок, прежде чем отправить их в ведомство; запускали инструмент на защищённых ноутбуках в полевых условиях.
Картографы Подчинялись собственному руководству; никто из тех, кто вёл проект, не считал их заказчиком.
ИТ-специалисты в закрытых сетях Устанавливали обновления со съёмных носителей с цифровой подписью, чтобы быть уверенными в их подлинности.
Команда дизайна Два исследователя, технический владелец продукта и я как ведущий дизайнер.
Фронтенд- и Python-разработчики Команда разработки World Wide Technology; я был одним из фронтенд-разработчиков и делал экраны на React.
Руководители программы Владелец продукта, бизнес-аналитик и руководитель внедрения.
Собственная команда ведомства Инженеры и владелец продукта со стороны ведомства работали вместе с нами на заказчика внутри ведомства.

Экран результатов. Заголовок «44 things to look at» с отметкой о 2 блокирующих условиях и данными запуска: стандарт данных, ячейка, завершено в 14:22. Внизу слева карта квадрата с крупными красными маркерами для блокирующих находок и меньшими синими для рекомендательных внутри пунктирной границы ячейки. Внизу справа шесть условий, блокирующие первыми, с количеством. — **Проблемы на карте.** Карта показывает, где находится каждая проблема, а список ставит обязательные к исправлению наверх.

Читать материалы Разделов: 6, около 2 мин

Контекст

Старая программа проверки была написана на Visual Basic, старом языке программирования Microsoft, а Microsoft объявила, что прекращает поддержку нужной ей версии Windows. Подрядчики вообще не могли её установить, и под угрозой оказалось всё требование целиком. Пользоваться ею значило прокликивать одно всплывающее окно за другим, сверяясь с чек-листом из папки толщиной в шесть дюймов. Каждая сдача данных занимала дни.

Кроме того, федеральные правила требовали, чтобы новый инструмент следовал U.S. Web Design System (USWDS), дизайн-системе правительства. В 2018 году она была немногим больше руководства по стилю и файла шаблона и предназначалась для веб-страниц, а не для рабочей программы.

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

Схема того, как программа проверки попадала к пользователям. Снаружи подписанный релиз копируется на съёмный носитель. Носитель вручную проносят через пропускной пункт объекта. Внутри, в закрытой сети без интернета, ИТ-специалисты проверяют подпись и устанавливают релиз на офлайн-ноутбуки, где подрядчики проверяют свои картографические данные. Пунктирный путь обозначает выезды исследовательской команды на объект для наблюдения за работой. — **Через воздушный зазор.** Релизы попадали на офлайн-ноутбуки на подписанных съёмных носителях, а мы приезжали на объекты наблюдать за работой.

Схема того, как подключались удалённые интервью. В ноутбук исследовательской команды вставлена государственная смарт-карта в считывателе, и сертификат карты вместе с PIN-кодом подтверждают, кто подключается. Соединение идёт зашифрованным туннелем через общую сеть, где шлюз проверяет сертификат, прежде чем пропустить его. Внутри защищённого объекта люди, выполняющие работу, подключаются к видеосвязи. Офлайн-ноутбуки программы проверки отмечены как никогда не подключаемые к этой линии. — **Интервью по линии со смарт-картой.** Между визитами мы брали интервью по видеосвязи, через зашифрованное соединение, которое открывал сертификат карты.

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

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

Дизайн

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

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

Стартовая страница. Узкая полоса вверху гласит «An application for data producers.» Заголовок «Check your data before it ships» стоит над кнопками Start a check и See a sample report, рядом карточка с образцом отчёта: карта с красными и синими маркерами и список условий point not inside area 6, area feature not transferred 12, complete duplicates 4. Ниже три пронумерованные карточки объясняют, как работает проверка: выбрать схему и загрузить, мы проверяем пакет, затем подробные правила, вы получаете карту того, что нужно исправить. — **Стартовая страница.** Стартовая страница объясняет этапы проверки до того, как вы что-либо загрузите, и позволяет сначала открыть образец отчёта.

Проверка пакета не пройдена. Карточку венчает красная линия, надпись «Three things are wrong with the folder» объясняет, что подробные проверки правил невозможны, пока пакет не исправлен. Перечислены три ошибки: отсутствует слой дорог, неожиданная проекция EPSG:3857 там, где протокол ждёт EPSG:4326, и два файла, не входящие в протокол. Доступны только действия Fix and upload again и Download the payload log. — **Жёсткая остановка.** Если не хватает слоя, проекция неверна или в папке лежат лишние файлы, инструмент останавливается здесь и точно перечисляет, что не так. Кнопки, чтобы перескочить к подробным проверкам, намеренно нет.

Открыто блокирующее условие: Point not inside area, затронуто 6 объектов. Сначала простое объяснение: устье скважины записано за пределами границы своего объекта, поэтому всё, что группирует точки по содержащей их области, их пропустит; затем раздел «How to fix it», который направляет правку в рабочую базу данных. Карта показывает, где это происходит, а таблица перечисляет затронутые объекты по слою и положению, показаны 3 из 6. — **Одна обязательная к исправлению проблема.** Каждая проблема объясняется простыми словами вместе со способом её исправить; номер правила служит ярлыком, а не заголовком.

Ещё экраны

Проверка пакета пройдена. Карточка гласит «The folder has everything it should» и подводит итог: 14 слоёв, 61 208 объектов, EPSG:4326. В таблице каждый слой с числом объектов и статусом Complete, над кнопкой, запускающей подробные проверки правил. — **Успех с расшифровкой.** Когда папка проходит проверку, программа перечисляет найденные слои с числом объектов, чтобы можно было отличить настоящий успех от проверки, которая так и не запустилась.

Подробные проверки правил идут по 61 208 объектам и 96 ограничениям. Подпись о ходе выполнения называет проверяемое правило, правило вложенности, а строка ниже сообщает, что результаты будут храниться в разделе Running checks. — **Подробные проверки в процессе.** Долгий этап называет правило, которое проверяется прямо сейчас, а не только процент.

Этап скачивания для одного квадрата, 44 объекта, относительно стандарта данных. Варианты формата: только .shp, только .csv или .csv и .shp, у каждого пояснение, для чего он нужен; область: все 44 объекта или только блокирующие. Кнопка скачивания называет выбранный формат, а пояснение повторяет, что получится при текущем выборе. — **Что включить в отчёт.** Вы выбираете тип файла и содержимое, а кнопка скачивания повторяет ваш выбор, а не прячет его в настройках.

Список Running checks. Показаны четыре задания с ячейкой, протоколом и временем начала, у каждого текстовый статус и действие по состоянию: View progress для запуска на 62%, View для задания в очереди, Open report для завершённого запуска с 27 объектами и See why для задания, у которого не прошла проверка пакета. Пояснение сообщает, что проверки продолжаются, даже если закрыть вкладку, а готовые отчёты хранятся 30 дней. — **Проверки, которые не останавливаются.** Проверки продолжаются, даже если закрыть вкладку, и у каждой есть кнопка по её состоянию: посмотреть ход выполнения, открыть отчёт или узнать, почему она не прошла.

Результаты

Подрядчики рассказывали, что проверка пакета картографических данных стала занимать часы вместо дней, и данные попадали в ведомство быстрее. Замеров до и после никто не делал, так что это их слова, а не измерение. За первый месяц инструмент проверил более 2000 картографических файлов, по подсчётам самой команды внедрения. Он соответствовал федеральному стандарту доступности (WCAG 2.1 AA); это мы проверяли сами, автоматическими инструментами и с программой экранного доступа, внешний аудитор его не проверял.

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

40+

Недостающие элементы дизайн-системы, сделанные на React, с инструкциями и автоматическими тестами.
Каждую неделю

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

Что сказал руководитель внедрения

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

Matt Todd Руководитель внедрения