Показываю полный цикл на одном эпизоде: разобрал рабочую задачу, проверил две версии с пользователями, перестроил путь к проблемному участку и подготовил решение к использованию на совещаниях. Часть компонентов затем вышла за пределы раздела аналитики.
Один эпизод из двух лет работыПроект под NDA. Названия и данные на экранах изменены.
Сервисом пользовались сотрудники аналитического центра и органов власти. Внутри были реестры, карточки, аналитика и длинные переходы между разделами. Сам раздел аналитики занимал около 50–70 экранов.
Аналитика использовалась не ради просмотра отчёта. Перед совещанием или прямо во время него сотруднику нужно было быстро увидеть проблемную территорию, открыть детали и понять этап, срок и ответственного.
экранов во всём сервисе
экранов в разделе аналитики
человек в постоянном рабочем контакте
Постановки писали прежде всего для разработки: в них были поля, требования и ограничения. Вместе с аналитиком я дополнял их пользовательским контекстом и проверял, как решение связано с соседними разделами.
Этого хватало разработке, но не всегда хватало для сборки понятного пользовательского пути.
До детальной отрисовки мы согласовывали цель, переходы и поведение системы в сложных случаях.
Вместе с аналитиком разбирал, кто принимает решение, какие данные знает на входе и что должно измениться после действия.
Связывал роли, права, статусы, документы, пустые состояния и развилки длинного сценария.
Проверял существующие компоненты, соседние разделы и ограничения разработки, прежде чем добавлять новое поведение.
Объяснял не внешний вид экрана, а связь решения с задачей, ограничениями и последующими шагами пользователя.
В нужный подраздел приходили с конкретным вопросом: где возникло отклонение, на каком этапе появилась проблема и кто отвечает за этот участок. Первая версия встречала пользователя плотным набором показателей.
Пользователи начинали последовательно считывать показатели, хотя основная задача подраздела состояла в другом: быстро заметить отклонение.
Некоторые нажимали не туда, уходили в другой раздел и тратили время на анализ показателей, которые не помогали найти этап проблемы.
Путь по всему сервису сюда не входил. Стартовой точкой была уже открытая страница аналитики.
Те же восемь пользователей сначала прошли версию с множеством показателей, затем версию с картой и переходом в детали. В обеих сессиях стартовали с открытой страницы нужного подраздела.
В сервисе около 500 экранов, в разделе аналитики около 50–70. Для проверки выбрал один основной сценарий конкретного подраздела: от открытого обзора до найденной причины отклонения.
Фиксировал время, ошибочные клики, возвраты и уходы в соседние разделы. Так результат показывал качество самого сценария, а не знание навигации по всей системе.
Проходили вариант, в котором первый экран был построен вокруг множества показателей.
Повторяли задачу на версии с картой, сокращённым набором сигналов и переходом в детали.
Сравнивал время, ошибки, возвраты и то, куда уходило внимание.
Люди начинали утопать в цифрах и проваливались в аналитику, уходя от нужного сценария: быстро заметить отклонение и найти его причину.
Оставил основные сигналы, поставил карту в центр и сохранил переход от территории к этапу процесса и ответственному.
Между версиями я убрал четыре причины лишнего маршрута.
Оставил сигналы, которые помогают заметить отклонение. Детальные цифры перенёс глубже.
Территория с проблемой стала видна до чтения детальных показателей.
Выбранная территория, период и фильтры переходили вместе с пользователем на следующий экран.
На каждом экране оставил один главный вопрос, чтобы вторичные данные не мешали следующему действию.
Количество шагов изменилось незначительно. Пользователь быстрее видел отклонение, не утопал в аналитических данных и сохранял контекст при переходе внутрь.
Первые два экрана показывают переход от общего отклонения к выбранной территории. Третий относится к другому подразделу аналитики и показывает, как тот же подход работал с длинным процессом.
Карта показывает распределение по территориям и даёт первый осмысленный выбор.
При переходе сохраняются выбранная территория, период и фильтры. Пользователь продолжает тот же сценарий, а не начинает анализ заново.
Экран показывает весь процесс, текущий этап и сроки. Можно быстро понять, где находится работа и укладывается ли она в план.
До выявления проблемного участка и конкретной причины отклонения.
Путь занимал примерно на 50–60% меньше времени.Одни и те же восемь пользователей последовательно прошли две версии. Во второй сессии они быстрее доходили до нужной зоны и реже уходили по ошибочному пути.
Для сотрудника контролирующего органа это важно перед совещанием или прямо во время него: можно быстро найти территорию, открыть проблемный этап и ответить на вопрос по конкретной ситуации.
Сервисом пользовались на больших совещаниях, где аналитику выводили на проектор для всего зала. Светлая тема в таких условиях читалась не всегда хорошо, поэтому для раздела аналитики дополнительно собрал тёмную тему.
Маршрут не обрывался, если по территории ещё не было полных данных.
Пользователь понимал, что произошло и что делать дальше.Показывал, какой вопрос решает каждый уровень и зачем нужен следующий переход.
Команда обсуждала сценарий на одном языке.Разработчики получили не только основной экран, но и поведение фильтров, переходов и неполных данных.
Сценарий можно было собрать без догадок между макетами.Кроме конкретного сценария, в продукте остались переработанные компоненты и новый способ ставить задачи на дизайн. Эти изменения использовались уже в других разделах системы.
задач по новому шаблону можно было начинать без обязательного часового созвона. Инициативу предложил я, затем мы продумали и внедрили шаблон вместе с командой дизайн-студии.
До: 2 человеко-часа на созвон аналитика и дизайнера. После: до 30 минут аналитика на заполнение шаблона. Экономия составляла около 1,5 часа на подходящую задачу.Расчётно это ≈105–240 человеко-часов на наблюдаемой выборке из 100–200 задач.Как меняли постановку →экранов всей системы использовали компоненты, которые я придумал или переработал для раздела аналитики
Локальные решения вышли за рамки аналитики и помогли связать разные разделы единым поведением.подряд получал внутреннюю номинацию «Гордость компании» за работу и помощь коллегам
Команда отмечала мою вовлечённость, помощь коллегам и умение доводить задачи до результата.В аналитике я связал основной вопрос пользователя с понятным сценарием: увидеть отклонение, сохранить контекст при переходе и открыть конкретные детали проблемы. Проверка двух версий показала сокращение времени примерно с десяти до четырёх или пяти секунд.
Для запуска подготовил состояния, правила и отдельную тёмную тему для демонстраций на проекторе. Компоненты раздела затем использовали ещё на 50–100 экранах, а предложенный мной шаблон постановки сократил трудозатраты команды на подходящих задачах.