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

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

На примере этого проекта покажу, как я выстраиваю анализ и использую его результаты при подготовке к редизайну.

Меня зовут Лена Плинер. Я занимаюсь UX/UI‑дизайном сложных интерфейсов: CRM, ERP, SaaS‑платформ и сервисов, веб‑ и мобильных приложений. Сотрудничаю с заказчиками и командами как попроектный дизайнер. Занимаюсь дизайном 15+ лет и мне всегда есть что рассказать. Делаю это в своем телеграм‑канале, где пишу о проектировании и дизайне сложных интерфейсов, разбираю реальные задачи, показываю свои решения и делюсь опытом работы над B2B‑системами, SaaS и специализированным ПО.

Контекст

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

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

Моя задача — полностью пересобрать UX существующей системы и затем пересобрать UI. При этом системой уже пользуются, и мне важно сохранить базовые возможности, на которые опираются пользователи.

Почему нельзя просто начать с экранов

На старте команда предлагала ограничить редизайн конкретным набором страниц. Можно было бы зафиксировать именно этот объём работы над UI, но системную несогласованность UX это не решает: одинаковые механики проходят через разные модули и страницы. Если улучшать выбранные экраны по отдельности, таблица в одном модуле станет удобнее, а в соседнем такую же задачу по‑прежнему будут решать иначе.

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

Основные недостатки текущего интерфейса:

• одинаковые таблицы и фильтры работают по‑разному;

• похожие действия реализованы через разные механики;

• навигация усложнена лишними переходами и промежуточными экранами;

• одинаковые элементы оформлены в разных стилях;

• на экранах повторяются тексты, инструкции, баннеры и видео;

• не всегда понятно, почему пользователю показывают именно эти данные.

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

Как я планирую процесс анализа

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

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

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

В «Медоеде» задача была конкретной: унифицировать разные паттерны, пересмотреть неудобный UX, сохранив при этом базовые возможности системы, сделать свежий UI и. Поэтому все шаги ниже собраны вокруг одной идеи: вычленить сквозные UX‑паттерны и превратить их в общие правила.

1. Что это за модуль и зачем он нужен? Для каждого модуля я заполняю описание (паспорт) по шаблону: цель, кто с ним работает, с чего начинается работа и что считается результатом, какие в нём сущности и справочники, как он связан с другими модулями

2. Что в продукте повторяется? Из описаний модулей я собираю одну таблицу (матрицу). Из неё сразу видно, где одно и то же реализовано по‑разному. Например, фильтры есть в шести модулях из восьми, и реализованы они четырьмя способами.

3. Как это выглядит в работе пользователя? Я беру типовую задачу, например «найти критические уязвимости», и разбираю её от цели до результата: какие действия нужны, что пользователю нужно знать или иметь на каждом шаге, где ему приходится принимать решение. Так видно, сколько шагов требует простая цель и чего на пути не хватает. Например, чтобы отфильтровать критические записи, нужно пройти семь шагов и вручную ввести значение «Критический», которое интерфейс не подсказывает. Эти разборы потом пригодятся для паттернов, навигации и данных.

4. Что из повторов станет общим правилом? Если одна механика реализована четырьмя способами, я сначала проверяю, действительно ли во всех случаях она решает одну и ту же задачу. Если да, выбираю решение, которое подходит для всех этих сценариев. Если ни один не справляется, собираю его из лучших решений. Результат записываю как правило, по которому механика работает везде. Это и есть сквозной UX‑паттерн.

5. Какие данные нужны пользователю?

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

Каждый шаг опирается на результат предыдущего. UX‑аудит я провожу параллельно со всеми шагами, с первого дня знакомства с продуктом.

Дальше я разберу каждый шаг: как выглядит его результат, зачем он нужен и что он дал на примере проекта «Медоед».

1. Разбираю модули и собираю общую картину

Для каждого модуля я собираю короткий паспорт модуля по одной и той же структуре:

• цель модуля;

• кто в нём работает;

• с чего начинается работа и что считается результатом;

• основные сущности;

• сценарии;

• справочники, которые модуль использует;

• связи с другими модулями;

• основные состояния;

• механики: таблицы, фильтры, формы, мастера и так далее.

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

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

Как я с ней работаю

Если у строки отметки во многих столбцах, это кандидат на сквозное решение. Если отметка одна, это, скорее всего, особенность конкретного модуля.

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

Пример из «Медоеда»:

В «Медоеде» матрица подтвердила часть подозрений, которые были у меня после первого знакомства. Фильтры есть почти во всех модулях, но сделаны несколькими разными способами. Выбор значения из справочника повторяется в разных модулях, а контролов для него несколько. Почти все модули построены на одном каркасе стартовой страницы. Заказчик как раз просил его упростить, и по матрице стало видно, что решать это можно один раз на уровне каркаса.

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

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

2. Разбираю пользовательские сценарии

Дальше основные сценарии из паспортов я раскладываю подробно в Task Analysis:

• цель пользователя;

• последовательность шагов;

• зависимости;

• точки принятия решений;

• взаимодействие с сущностями;

• смену контекста;

• результат сценария.

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

Пример из «Медоеда»: поставить задачу на устранение уязвимости. Уязвимость — это слабое место в программе, через которое можно взломать компьютер. В таблице модуля уязвимости перечислены списком и пользователь должен поручить кому‑то закрыть каждую.

Путь выглядит так:

Шаг 1. Щёлкнуть по строке с уязвимостью в таблице.

Найденные проблемы: Выбор не очевиден. После клика строка еле заметно меняет цвет, галочки нет. Если до этого таблицу сгруппировали, подсвечивается вся группа, например 22 записи, а форма откроется только по одной. Необходимо реализовать функционал групповых действий, чтобы ставить одну задачу сразу на несколько уязвимостей. Сейчас в интерфейсе одна задача относится к одной записи.

Шаг 2. Нажать кнопку «Запланировать действие». Откроется форма «Планирование действия».

Шаг 3. Заполнение формы.

Название и описание планируемого действия уже заполнены: система сама подставила рекомендацию по устранению. Нужно выбрать ответственного из списка всех сотрудников компании и указать срок.

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

Шаг 4. Нажать «сохранить».

Найденные проблемы: Сохранение ничем не подтверждается. После нажатия таблица остаётся прежней. Понять, что задача создана, можно только в «Планировщике». Задача пропадает из виду. В самой уязвимости ссылки на задачу нет. Чтобы узнать, выполнена ли она, нужно идти в другой раздел. Отметить выполненной можно иконкой‑галочкой, которая подписана лишь подсказкой при наведении мыши.

Всё это записано в документе: таблица по шагам и итоговая сводка проблем, переходов между разделами и открытых вопросов.

3. Проверяю сквозные UX‑паттерны

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

UX‑паттерн — это единый способ решать одну и ту же задачу везде, где она встречается. Например, «оставить в таблице только нужные записи» должно работать одинаково в любом модуле.

Я делаю три вещи:

1. Беру повтор из матрицы.

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

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

Пример из «Медоеда»: фильтры в таблицах.

1. Матрица. Фильтры есть в шести модулях из восьми, и сделаны они четырьмя способами.

2. Сценарии. Везде человек решает одну и ту же задачу: оставить в таблице нужные записи. Значит, паттерн один.

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

Результат: одно правило вместо четырёх способов.

Бывает и по‑другому. «Назначение ответственного» выглядело как одна операция, но по сценариям оказалось двумя задачами: назначить одного исполнителя на задачу и собрать комиссию из ролей. Поэтому паттернов получилось два.

Так появляется библиотека UX‑паттернов: общие правила для повторяющихся операций.

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

4. Инвентаризирую данные

Когда сценарий понятен, можно проверить данные, с которыми пользователь в нём работает.

Например: форма создания → карточка объекта → таблица или список

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

Расхождения обычно бывают двух видов:

• данные, которые пользователь вводит в форме, а дальше нигде не видит;

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

Пример из «Медоеда»

В «Медоеде» я проверяла так задачу на устранение уязвимости. Если одна и та же уязвимость есть на нескольких машинах, исполнитель в списке задач не видит, к какой из них относится его задача. В общей таблице уязвимостей не видно, назначено ли по записи хоть какое‑то действие.

Здесь нет правила «поле есть в форме, значит оно должно быть в таблице».

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

5. Проверяю архитектуру и навигацию

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

• может ли пользователь из любого места попасть куда нужно;

• понимает ли он, где находится;

• понятно ли из названия раздела то, что внутри;

• может ли вернуться.

Какие проблемы нашлись в «Медоеде»

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

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

• Ссылки, по которым нельзя перейти. На странице для неавторизованных пользователей были ссылки на модули, но открыть их без входа в систему было нельзя.

• После перехода из таблицы пользователь теряется. Ссылка на связанную запись, например на компьютер или программу, уводит в другой раздел. Фильтры таблицы пропадают, и вернуться к исходной строке непонятно как.

Новых решений без подтверждения я не добавляю.

UX‑аудит идёт всё это время

Документ с находками создаю сразу, как только начинаю знакомиться с продуктом, и пополняю на каждом этапе.

Каждую находку я записываю в одном формате:

• скриншот;

• что видно на экране;

• почему это проблема для конкретного сценария;

• какая эвристика нарушена;

• степень серьёзности, от катастрофической до косметической;

• статус: новое, предложено решение, согласовано с заказчиком или отклонено.

Часть анализа дополнительно проверяю с Claude по эвристикам Нильсена. Сначала сама фиксирую наблюдение, контекст сценария и то, что меня смущает. Claude помогает привести находки к единому формату и сверить их с эвристиками. Вывод о проблеме и решение остаются за мной. Фиксирую и проблемы, и удачные решения, которые стоит сохранить.

Пример из «Медоеда»

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

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

Что получает команда

К концу анализа любой вопрос по будущему дизайну можно отнести к одной из групп:

• Решаем один раз для всей системы. Например, фильтры в таблицах: они будут работать одинаково везде.

• Нужны два разных решения. Например, «назначить ответственного» может означать поручить задачу одному человеку или собрать группу из ролей. Это две разные задачи, и объединять их в один элемент нельзя.

• Общее правило с дополнением по месту. Например, быстрые фильтры: они добавляются только там, где пользователи часто ищут одно и то же.

• Планирование дальнейшей работы выстроено по степени влияния правил на систему.

Что получает команда заказчика:

• общую картину продукта, на которую можно опираться в обсуждениях;

• сценарии, где видно, как пользователи решают задачи и где спотыкаются;

• библиотеку паттернов с согласованными правилами для повторяющихся операций;

• список вопросов, без ответа на которые решение принимать рано;

• решения, которые уже согласованы и не потеряются между созвонами.

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

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

Что на выходе

• Общая картина продукта. Все модули описаны по одному шаблону, поэтому их можно сравнивать, видеть повторы и особенности. На эту картину можно опираться в любых обсуждениях.

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

• Приоритеты. Параллельный UX‑аудит даёт список находок с оценкой серьёзности. Из него можно собирать план работ, учитывая приоритетность задач.

• Правила для повторяющихся операций. Библиотека паттернов фиксирует, как одна и та же операция работает везде и какие у неё исключения.

• Список открытых вопросов. Расхождения между интерфейсом и вводными, а также вопросы, без ответа на которые решение принимать пока рано.

• Единый список решений. Решения основаны на фактах, а не на субъективных впечатлениях.

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

Спасибо за внимание!