Всем привет! Меня зовут Севда Комарова, я работаю в ИТ-команде «Северстали». Мы проектируем сложные B2B-системы, которыми ежедневно пользуются сотрудники предприятий.

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

Для большинства исследований хватает Figma, корпоративного мессенджера, видеозвонка и нескольких пользователей.

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

Почему мы тестируем интерфейсы

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

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

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

Мы проектировали систему для контроля комплексных поставок. Одним из самых сложных элементов стала диаграмма Ганта: стандартного решения из дизайн-системы было недостаточно, потому что оно не покрывало бизнес-логику проекта.

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

Но именно тестирование показало, где наше представление о «понятно» расходится с пользовательским.

Способ 1. Глубинные онлайн-тесты для сложных сценариев

Если нужно проверить большую новую функциональность или длинный пользовательский сценарий, я провожу полноценное онлайн-тестирование.

Сначала готовлю реалистичный прототип. Не обязательно доводить каждый экран до идеального pixel perfect, но данные и состояния должны быть похожи на настоящие.

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

Дальше готовлю задания.

Вместо:

— Вам понятен интерфейс?

Задаю:

— Какие позиции уже завершены?

— Где фактическая дата вышла за плановую?

— Перейдите к производственным этапам.

— Вернитесь обратно.

То есть человек не оценивает дизайн, а работает с ним.

На тестировании нашей диаграммы Ганта участвовали пять пользователей. Сценарий рассчитали примерно на 25 минут. Из-за жёсткого дедлайна все пять сессий провели за один день. Мы фиксировали не только комментарии, но и время выполнения заданий, ошибки, количество действий и ситуации, когда человеку требовалось дополнительное объяснение. Основные сценарии пользователи считывали быстро: большинство определяло завершённые позиции и отклонения между планом и фактом не более чем за пять секунд. Сам принцип наложения факта на план тоже сработал: все пять пользователей оценили его на 5 из 5.

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

После первой сессии я добавила в сценарий два вопроса для остальных пользователей:

— В каком временном периоде вы сейчас находитесь?

— Где на диаграмме текущая дата?

Так исследование начало меняться прямо во время проведения.

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

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

Способ 2. Быстрая проверка гипотезы: когда не нужен ещё один большой тест

Не каждое изменение требует нового исследования на несколько дней. Иногда нужно проверить один экран, название, расположение кнопки или уже исправленную проблему. Тогда я использую короткую проверку. Обычно достаточно показать решение нескольким людям и дать одну конкретную задачу. Иногда на такую сессию уходит 7–10 минут.

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

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

Способ 3. Иногда лучший инструмент — обычный карандаш

Это, наверное, самый простой способ в моём списке.

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

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

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

Способ 4. A/B-тест без сложной аналитики

Иногда есть две версии решения и обе выглядят логично. Например, можно по-разному расположить фильтры, сгруппировать данные или назвать действие.

Вместо долгого спора внутри команды я показываю пользователям два варианта и задаю один и тот же вопрос:

— Где вам проще найти нужную информацию?

Или:

— В каком варианте быстрее понятно, что делать дальше?

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

Мы не стали автоматически менять интерфейс по одному из комментариев.

И в A/B-проверках я придерживаюсь того же принципа: важно не только понять, какой вариант выбрали, но и почему. Иногда один хороший комментарий объясняет результат лучше, чем итоговая цифра.

Способ 5. Анализ записей: самое полезное иногда начинается после тестирования

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

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

На записи уже видно другое:

• где человек сделал паузу;

• где несколько раз перечитал текст;

• где долго двигал курсором;

• куда пошёл сначала;

• в какой момент поменял своё решение.

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

Например:

• усилили отображение текущей даты;

• добавили флажок в легенду и пояснили его в тултипе;

• сделали навигацию назад заметнее;

• скорректировали названия и порядок столбцов;

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

• добавили возможность выгрузить таблицу в Excel.

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

Пользователь не должен проектировать интерфейс за нас. Его задача показать, где ему удобно, где он ошибается и чего не понимает. А уже наша задача разобраться в причине и найти решение.

Что в итоге

Удалённое тестирование не обязательно должно быть большим отдельным этапом проекта. Иногда это пять пользователей и полноценный сценарий. Иногда один семиминутный звонок. Иногда два варианта одного экрана. А иногда работа начинается вообще с карандаша и листа бумаги. На практике эти способы постоянно смешиваются.

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

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