Как подступиться к большому незнакомому интерфейсу, если его нужно практически полностью пересобрать? Часть 1.

Сейчас у меня как раз такой проект.

Контекст «Медоед» — система в области IT и информационной безопасности, которая помогает компаниям работать с требованиями законодательства и регуляторов.

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

Нового функционала на этом этапе не добавляем. Задача — полностью пересобрать UX существующей системы и затем перезапустить UI.

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

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

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

На первом этапе работы я разбираюсь, как устроен сам продукт. 1. Разбираю модули и собираю общую картину Для каждого модуля фиксирую его цель, начало и результат работы, основные сущности, справочники, сценарии, состояния, связи и используемые механики. Получается паспорт модуля.

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

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

2. Разбираю пользовательские сценарии Дальше основные сценарии из паспортов раскладываю подробно в Task Analysis: — цель пользователя; — последовательность шагов; — зависимости; — точки принятия решений; — взаимодействие с сущностями; — смену контекста; — результат сценария.

Если в паспорте сценарий просто перечислен, здесь уже видно, как именно пользователь решает задачу.

3. Проверяю сквозные UX-паттерны Теперь можно сопоставить найденные в матрице повторения с реальными сценариями.

Например, в разных модулях могут повторяться: — создание сущности; — работа с таблицей и фильтрами; — выбор объекта из справочника; — изменение статуса; — назначение ответственного; — прикрепление документа.

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

Так появляется библиотека UX-паттернов: общие правила для повторяющихся пользовательских операций, которые дальше не придётся проектировать отдельно для каждого модуля. #проект #uxаудит #предпроектныйанализ