Мобильный прототип легко открыть на ноутбуке, кликать по нему мышкой и считать, что сценарий уже проверен. Но такое тестирование показывает только часть картины. На смартфоне пользователь взаимодействует с интерфейсом иначе: держит устройство одной рукой, промахивается по небольшим элементам, использует жесты, прокручивает экран большим пальцем и часто действует в условиях, далеких от спокойной работы за столом.
Эта статья будет полезна UX/UI-дизайнерам, продуктовым менеджерам, исследователям и командам, которые создают мобильные продукты и хотят проверять решения до разработки. Я разберу, как организовать тестирование так, чтобы прототип действительно отражал мобильный сценарий, а не просто выглядел как уменьшенная версия десктопного интерфейса.
В работе с клиентскими исследованиями я часто вижу одну и ту же проблему: команда хорошо проверяет логику экранов, но почти не проверяет само взаимодействие с ними. На макете всё выглядит очевидно, а на реальном устройстве оказывается, что пользователь не замечает элемент, не понимает, что экран можно прокрутить, пытается сделать свайп вместо нажатия или не может удобно дотянуться до важной кнопки.
Именно поэтому мобильное тестирование должно учитывать не только содержание экранов, но и способ взаимодействия с ними. Размер устройства, положение руки, привычные жесты, системная навигация и контекст использования могут заметно влиять на поведение человека.
При этом прототип не обязан полностью повторять готовое приложение. Его задача — дать достаточно реалистичный сценарий, чтобы проверить основные гипотезы. Еще до разработки можно обнаружить проблемы с последовательностью шагов, навигацией, расположением элементов, понятностью действий, возвратами между экранами и ожиданиями пользователя после нажатия или жеста.
Дальше разберем, как определить цель такого теста, подготовить прототип, сформулировать задания и наблюдать за поведением пользователя так, чтобы результаты помогали принимать продуктовые решения, а не просто собирать впечатления о дизайне.
До приглашения участников и подготовки сценария я советую ответить на простой вопрос: какое решение команда собирается принять по результатам тестирования? Это помогает избежать исследования, после которого остается много наблюдений, но непонятно, что с ними делать.
Формулировка «хотим проверить мобильный прототип» слишком широкая. В одном случае нас интересует, сможет ли новый пользователь зарегистрироваться без помощи. В другом — заметит ли он функцию поиска. В третьем — поймет ли разницу между двумя тарифами. А иногда нужно проверить сам принцип взаимодействия: например, догадается ли человек свайпнуть карточку или будет искать отдельную кнопку.
Все эти задачи требуют разного прототипа и разных критериев оценки.
Отделите сценарий от визуального оформления
На раннем этапе необязательно создавать детализированный интерфейс, чтобы получить полезные результаты. Если команда решает, в какой последовательности пользователь должен пройти регистрацию, достаточно прототипа, позволяющего воспроизвести этот путь.
В таком тесте меня прежде всего будет интересовать, понимает ли человек, что требуется на каждом этапе, соответствует ли последовательность его ожиданиям и может ли он двигаться дальше без объяснений.
Если же исследовательская задача звучит как «замечают ли пользователи основную кнопку на экране», визуальная часть становится значительно важнее. Расположение, размер, соседние элементы и общая иерархия уже непосредственно влияют на результат.
Поэтому перед тестированием полезно разделить вопросы. Что мы проверяем: структуру сценария, навигацию, терминологию, визуальную иерархию, жесты или понимание результата действия?
Необязательно выбирать только что-то одно. Но команда должна понимать, какие выводы позволяет сделать текущая версия прототипа.
Не требуйте от раннего прототипа слишком многого
Чем ниже детализация прототипа, тем осторожнее нужно интерпретировать поведение участников.
Представим, что на раннем макете пользователь не замечает серую прямоугольную область, которая в готовом приложении должна стать крупной фотографией с понятной подписью. Делать вывод о незаметности будущего элемента преждевременно: участник тестировал не финальную визуальную иерархию, а условное представление интерфейса.
С другой стороны, даже очень простой прототип может хорошо выявлять проблемы в логике сценария. Если пользователи после оформления заказа ожидают сразу увидеть подтверждение, а команда предлагает им пройти еще три обязательных этапа, высокая визуальная детализация для обнаружения такого расхождения не нужна.
Я стараюсь придерживаться принципа: детализация прототипа должна быть достаточной для проверки конкретной гипотезы, но не обязательно максимальной.
Создание практически готового интерфейса перед первым тестом иногда даже мешает. Команда уже вложила много времени в решение, поэтому менять структуру становится психологически и технически сложнее. Кроме того, участники начинают обращать внимание на цвета, изображения и мелкие детали, хотя исследователю в этот момент может быть важна совсем другая проблема.
Сформулируйте проверяемые вопросы
Вместо общей цели «проверить удобство приложения» полезнее подготовить несколько конкретных исследовательских вопросов.
Например: сможет ли новый пользователь самостоятельно начать оформление заказа? Поймет ли он, что выбранный параметр можно изменить? Какой способ возврата на предыдущий экран он попробует использовать? Что, по его ожиданиям, произойдет после подтверждения операции?
Такие вопросы не нужно зачитывать участнику. Они нужны исследователю, чтобы понимать, за каким поведением наблюдать.
Допустим, команда хочет проверить новый жест для удаления элемента. Если участнику прямо сказать «смахните карточку влево, чтобы удалить ее», исследование теряет смысл. Задача должна описывать цель — например, убрать ненужную позицию из списка. После этого мы наблюдаем, какой способ человек попробует первым: свайп, долгое нажатие, меню или поиск отдельной кнопки.
Если большинство пользователей не пытаются использовать задуманный жест, это важный результат. Возможно, жест недостаточно очевиден или не соответствует привычной модели взаимодействия.
Цель определяет и состав участников
Нельзя оценивать прототип в отрыве от аудитории, для которой он создается.
Если мобильное приложение рассчитано на опытных специалистов, поведение человека, впервые столкнувшегося с предметной областью, может дать много ложных сигналов. И наоборот, интерфейс для широкой аудитории не стоит проверять исключительно на коллегах, которые хорошо знают продукт и его внутреннюю терминологию.
Особенно внимательно я бы относился к исследованиям с сотрудниками собственной компании. Они удобны для быстрого предварительного теста: помогают найти сломанные переходы, очевидные несоответствия и технические проблемы прототипа. Но знание продукта делает их поведение нетипичным для реальных пользователей.
Поэтому подбор участников должен следовать из исследовательского вопроса. Если мы проверяем первый запуск приложения, нужны люди без опыта работы с ним. Если исследуем изменение существующей функции, наоборот, может потребоваться аудитория, которая уже знает предыдущую версию.
Четкая цель помогает и после исследования. Вместо расплывчатого вывода «пользователям в целом понравился прототип» команда получает ответ на конкретный вопрос: например, новые пользователи понимают последовательность оформления, но не замечают возможность изменить выбранный параметр.
Именно такой результат можно превратить в следующую продуктовую гипотезу и проверить в новой версии мобильного прототипа.
Даже хороший сценарий исследования может дать сомнительные результаты, если сам прототип подготовлен плохо. Пользователь нажимает на элемент, который выглядит активным, но ничего не происходит. Пытается вернуться назад привычным способом, а такой переход не предусмотрен. Прокручивает экран, но прототип реагирует иначе, чем мобильное приложение. В результате исследователь фиксирует затруднение, причиной которого оказался не дизайн продукта, а ограничение тестового макета.
Поэтому перед встречей с участниками я рекомендую самостоятельно пройти все задания на том устройстве и тем способом, которыми будет пользоваться респондент. Простого просмотра экранов в редакторе прототипов для этого недостаточно.
Проверьте не только основной маршрут
При подготовке прототипа команда обычно хорошо прорабатывает идеальный сценарий: открыть первый экран, нажать нужную кнопку, выбрать правильный вариант и перейти дальше. Но реальные пользователи редко двигаются строго по задуманной траектории.
Они нажимают на соседние элементы, возвращаются назад, открывают меню, пытаются изменить уже выбранный параметр. Именно в этих действиях часто обнаруживаются наиболее интересные расхождения между логикой продукта и ожиданиями аудитории.
Если любой неправильный клик приводит в тупик только потому, что команда не настроила соответствующий переход, результаты тестирования становятся сложнее интерпретировать. Мы не знаем, столкнулся ли человек с проблемой интерфейса или просто вышел за границы подготовленного прототипа.
Не нужно делать интерактивным абсолютно всё. Но желательно заранее предусмотреть наиболее вероятные альтернативные действия и возможность вернуться в основной сценарий.
Проверьте кликабельные области и прокрутку
На компьютере попасть курсором даже в небольшой элемент относительно легко. На смартфоне ситуация другая. Пользователь касается экрана пальцем, который закрывает часть интерфейса, а точность нажатия ниже.
Поэтому стоит проверить, соответствуют ли активные области тому, что человек видит на экране. Если визуально вся карточка воспринимается как интерактивная, но переход работает только при касании маленькой стрелки справа, участник может несколько раз нажать на карточку и решить, что она неактивна.
Отдельного внимания требует прокрутка. Некоторые проблемы появляются именно из-за того, что пользователь не понимает, продолжается ли экран ниже. Это может быть особенностью дизайна, а может оказаться артефактом прототипа — например, если высота экрана или положение фиксированных элементов настроены неправильно.
Перед исследованием я бы обязательно проверил длинные экраны, модальные окна, списки, горизонтальные элементы и области с фиксированными кнопками. Если сценарий предполагает свайп, жест тоже должен срабатывать достаточно естественно.
Не забывайте о клавиатуре и вводе данных
Формы в мобильных прототипах заслуживают отдельной проверки. В реальном приложении появление клавиатуры уменьшает доступную область экрана и может заметно изменить взаимодействие.
Кнопка, которая прекрасно видна на макете, после открытия клавиатуры может оказаться за ее пределами. Пользователю приходится закрывать клавиатуру или прокручивать экран, хотя дизайнер мог этого не предусмотреть.
Прототип не всегда позволяет точно воспроизвести системное поведение. В таком случае важно хотя бы понимать ограничение и учитывать его при анализе. Если участник не смог завершить форму потому, что тестовый инструмент некорректно показывает клавиатуру, записывать это как проблему будущего приложения неправильно.
То же касается автозаполнения, выбора даты, загрузки файлов, разрешений камеры и других системных компонентов. Чем сильнее сценарий зависит от возможностей операционной системы, тем внимательнее нужно относиться к тому, насколько реалистично их имитирует прототип.
По возможности тестируйте на реальном смартфоне
Когда меня интересует именно мобильное взаимодействие, я предпочитаю, чтобы участник держал устройство в руках. Это позволяет увидеть то, чего практически невозможно заметить при кликах мышкой по макету на компьютере.
Например, выясняется, что пользователь постоянно меняет хват, чтобы дотянуться до элемента. Или пытается закрыть окно системным жестом. Или ожидает, что карточку можно листать горизонтальным свайпом. Такие детали относятся не только к визуальному дизайну — они показывают, насколько интерфейс соответствует привычкам мобильного пользователя.
Размер экрана тоже имеет значение. Прототип, который удобно выглядит на большом смартфоне дизайнера, может восприниматься иначе на меньшем устройстве. Поэтому для важных сценариев полезно заранее определить диапазон устройств, характерный для аудитории продукта.
Это не означает, что каждое исследование необходимо проводить на десятках моделей смартфонов. Цель — не протестировать техническую совместимость, а не создать искусственно идеальные условия, которые существуют только на экране рабочего компьютера.
Отделяйте ограничения прототипа от UX-проблем
Перед началом теста допустимо коротко предупредить участника, что перед ним прототип и некоторые функции могут быть недоступны. Но я не советую заранее перечислять все места, где он может столкнуться с ограничениями: такое объяснение способно подсказать правильный маршрут.
Если техническая проблема возникла во время задания, ее стоит отдельно отметить в результатах. Например: «участник попытался использовать системный жест возврата, но прототип его не поддерживал». Это принципиально отличается от формулировки «пользователь не смог вернуться на предыдущий экран».
Первая запись описывает ограничение тестовой среды. Вторая уже звучит как проблема интерфейса.
Чем аккуратнее мы разделяем эти ситуации, тем меньше риск переделывать продукт из-за поведения самого прототипа. Его задача — не идеально имитировать готовое приложение, а создать достаточно реалистичные условия, чтобы пользователь мог показать нам, как он понимает сценарий и как пытается с ним взаимодействовать.
Даже реалистичный мобильный прототип мало что покажет, если пользователь заранее знает правильную последовательность действий. Формулировка задания напрямую влияет на его поведение, поэтому одна лишняя подсказка способна сделать результат исследования значительно менее полезным.
Представим, что мы проверяем приложение доставки и хотим узнать, сможет ли пользователь самостоятельно изменить адрес. Можно сказать: «Откройте профиль, перейдите в раздел "Адреса" и добавьте новый адрес». Скорее всего, участник успешно справится. Но мы проверили только способность выполнить инструкцию.
В реальной ситуации человек не получает такой подсказки. У него возникает другая задача: например, заказать продукты не домой, а в офис. Где он будет искать изменение адреса — на главном экране, в корзине, при оформлении заказа или в профиле — нам как раз и нужно выяснить.
Поэтому я стараюсь формулировать задания через цель пользователя, а не элементы интерфейса.
В нашем примере задание может звучать так: «Представьте, что после работы вы хотите заказать продукты в офис, хотя обычно оформляете доставку домой. Покажите, как бы вы это сделали».
Такая постановка создает контекст, но не раскрывает маршрут. Теперь действия участника становятся исследовательскими данными.
Не используйте в задании слова из интерфейса
Одна из самых незаметных подсказок — повторение названий кнопок и разделов.
Если на экране есть пункт «Управление подпиской», а исследователь просит «изменить настройки подписки», пользователь получает ориентир для поиска. В реальной ситуации он мог бы формулировать свою задачу иначе: например, «хочу перейти на более дешевый тариф».
Это особенно критично при проверке терминологии и информационной архитектуры. Если мы хотим узнать, понимает ли человек, где находится нужная функция, нельзя заранее сообщать ему название раздела, в котором она расположена.
По этой же причине стоит осторожно использовать профессиональные термины. Пользователь может не называть действие «авторизацией», «верификацией» или «управлением подпиской», даже если эти слова привычны продуктовой команде.
Формулировка задания должна быть понятна человеку сама по себе и при этом не содержать карту интерфейса.
Добавьте реалистичный контекст
Слишком абстрактные задания тоже дают слабые результаты. Просьба «попробуйте что-нибудь заказать» оставляет участнику слишком много свободы. Он может выбрать самый простой сценарий, хотя команда хотела проверить конкретную часть продукта.
Лучше дать человеку ситуацию, в которой появляется естественная мотивация выполнить нужное действие.
Например, вместо «найдите фильтры» можно сказать: «Вам нужен отель на две ночи, и вы не хотите рассматривать варианты дороже определенной суммы». Вместо «измените уведомления» — «Представьте, что вы хотите получать сообщения о статусе заказа, но не хотите получать рекламные предложения».
Для проверки регистрации можно создать ситуацию, в которой человеку действительно требуется аккаунт. Для оплаты — объяснить, что он хочет завершить конкретную покупку. Для поиска — дать объект, который необходимо найти, не называя сам механизм поиска.
Хорошее задание отвечает на вопрос «зачем пользователю это делать?», но не отвечает за него на вопрос «как это сделать?».
Не заставляйте участника угадывать выдуманные данные
Есть еще одна проблема мобильных тестов — необходимость вводить информацию, которой у пользователя нет.
Например, прототип просит указать номер заказа, промокод или данные условного клиента, но исследователь не предоставил их заранее. Участник начинает выяснять, что именно нужно вводить, и обсуждение интерфейса превращается в попытку разгадать условия задания.
Если для сценария нужны конкретные данные, их лучше включить в контекст. При этом информации не должно быть настолько много, чтобы человеку приходилось постоянно переключаться между инструкцией и смартфоном.
В некоторых случаях ввод можно упростить. Если нас интересует структура оформления заказа, а не удобство заполнения формы, необязательно заставлять участника печатать длинный адрес. Но если исследовательская гипотеза связана именно с мобильным вводом, клавиатурой или ошибками в полях, этот этап, наоборот, нужно воспроизвести максимально реалистично.
Не оценивайте только успешное завершение
Пользователь может выполнить задание и всё равно столкнуться с серьезной проблемой.
Допустим, участник должен найти товар и добавить его в избранное. Он сначала открывает карточку, возвращается назад, ищет функцию в меню, снова открывает товар и только после нескольких попыток замечает нужную иконку. Формально задача выполнена.
Если записать только результат «успех», мы потеряем основную часть наблюдения.
Поэтому для каждого задания я бы фиксировал не только финал, но и путь: с чего человек начал, какие варианты рассматривал, где остановился, возвращался ли назад и потребовалась ли ему помощь.
Иногда особенно полезен вопрос после завершения сценария: «Насколько вы уверены, что сделали именно то, что хотели?» Человек может дойти до нужного экрана, но не понимать, сохранилось ли действие. Для мобильных интерфейсов с небольшим количеством пространства под подтверждения и пояснения это довольно важный сигнал.
Правильно сформулированное задание создает небольшую, но реалистичную ситуацию использования продукта. Пользователь получает понятную цель и самостоятельно выбирает способ ее достижения. Именно в этом выборе мы и видим, насколько логика мобильного прототипа совпадает с логикой человека.
При тестировании мобильного прототипа важно смотреть не только на то, куда пользователь в итоге нажал, но и на то, как он физически взаимодействовал с устройством. На смартфоне часть ожиданий вообще не выражается словами: человек пытается свайпнуть карточку, тянет экран вниз, нажимает на всю строку вместо небольшой иконки или использует привычный системный жест возврата.
Такие действия позволяют увидеть то, что легко пропустить при демонстрации прототипа на компьютере. Пользователь может правильно понимать задачу и даже знать, какой результат ему нужен, но предложенный интерфейс не соответствует привычному для него способу взаимодействия.
Смотрите на первое действие
Первое действие после получения задания особенно информативно. В этот момент пользователь еще не успел изучить логику прототипа и действует в соответствии со своими ожиданиями.
Представим экран со списком сохраненных товаров. Команда предполагает, что для удаления позиции пользователь откроет дополнительное меню через иконку с тремя точками. Участник же сразу пытается свайпнуть карточку влево.
Если прототип не реагирует, человек может начать искать другой способ и в конце концов найти меню. Формально сценарий будет завершен успешно. Но первое действие показывает, какую механику пользователь считал естественной.
Это не означает, что интерфейс обязательно нужно переделывать под каждый ожидаемый жест. Один участник может использовать свайп, другой — долгое нажатие, третий сразу искать меню. Задача исследователя — собрать эти ожидания и посмотреть, появляется ли повторяющийся паттерн.
Фиксируйте промахи по элементам
На мобильном устройстве хорошо заметны проблемы, которые почти исчезают при тестировании мышью. Одна из них — промахи при нажатии.
Если человек несколько раз касается небольшого элемента и не получает ожидаемой реакции, стоит разобраться в причине. Возможно, кликабельная область действительно слишком мала. Возможно, активная зона прототипа не совпадает с визуальными границами кнопки. А иногда пользователь вообще воспринимает соседний элемент как часть той же области.
Один случайный промах обычно мало о чем говорит. Повторяющиеся попытки попасть в один элемент у нескольких участников уже заслуживают внимания.
Полезно наблюдать и за тем, как человек держит устройство. Например, при использовании смартфона одной рукой некоторые действия могут требовать изменения хвата. Пользователь сначала пытается дотянуться большим пальцем, затем перехватывает телефон второй рукой и только после этого нажимает на элемент.
Если подобное происходит с редко используемой настройкой, это может быть несущественно. Если так расположено основное действие, которое человек выполняет постоянно, наблюдение становится гораздо важнее.
Обращайте внимание на жесты, которых нет в прототипе
Мобильные пользователи приходят в новый интерфейс с опытом использования десятков других приложений. Поэтому они ожидают определенного поведения даже без явных подсказок.
Человек может попытаться потянуть экран вниз для обновления, свайпнуть изображение для просмотра следующего, закрыть модальное окно движением вниз или вернуться назад системным жестом.
Если прототип не поддерживает такое действие, важно понять, что именно произошло. Не стоит сразу записывать: «пользователь не понял управление». Возможно, наоборот, он продемонстрировал вполне понятную модель взаимодействия, которую текущий прототип просто не способен воспроизвести.
Я бы фиксировал такие ситуации отдельно: какое действие пытался совершить пользователь, какого результата ожидал и почему не смог его получить. Позже команда сможет решить, должен ли готовый продукт поддерживать такое поведение.
Следите за прокруткой
Прокрутка кажется настолько привычным мобильным действием, что ей легко не уделить внимания. Однако именно здесь могут скрываться важные проблемы.
Например, пользователь доходит до нижней части видимой области и считает, что экран закончился, хотя ниже расположена основная кнопка. Причиной может быть отсутствие визуального намека на продолжение контента. В другом случае человек постоянно прокручивает экран вниз в поисках действия, хотя оно находится в фиксированной панели сверху.
Особенно интересно наблюдать, что происходит после первого свайпа. Если пользователь сразу видит продолжение и двигается дальше, скорее всего, серьезной проблемы нет. Если он несколько раз делает короткие движения, возвращается вверх и явно пытается определить структуру страницы, этот момент стоит разобрать подробнее.
При этом снова нужно исключить технические особенности прототипа. Неестественная скорость прокрутки, неправильно закрепленная панель или случайно перекрытая область могут создавать затруднения, которых не будет в готовом приложении.
Наблюдайте за последовательностью действий
Отдельный жест редко дает полную картину. Намного полезнее рассматривать цепочку поведения.
Например, пользователь хочет открыть дополнительную информацию о товаре. Сначала нажимает на изображение, затем на название, после этого пытается свайпнуть карточку и только потом замечает маленькую стрелку. Каждая попытка показывает одно и то же ожидание: человек воспринимает большую часть карточки как область перехода.
Если исследователь зафиксирует только последнее успешное нажатие, интерфейс покажется рабочим. Если восстановить весь путь, становится видно потенциальное несоответствие между визуальным представлением элемента и его фактическим поведением.
Именно поэтому в мобильных исследованиях я стараюсь записывать не только результат задания, но и последовательность попыток. Иногда несколько секунд взаимодействия пальцами рассказывают о понятности интерфейса больше, чем длинный ответ пользователя после завершения теста.
Мобильный прототип стоит воспринимать не как набор экранов, а как модель взаимодействия. Пользователь не просто читает информацию — он касается, листает, возвращается, меняет хват и ожидает знакомой реакции устройства. Чем лучше исследование фиксирует эти действия, тем раньше команда сможет обнаружить проблемы, которые на статичном макете могли бы остаться незаметными.
Во время мобильного тестирования особенно трудно ничего не подсказывать. Пользователь держит смартфон, несколько секунд смотрит на экран, пробует один жест, другой, а затем спрашивает: «Что здесь нужно сделать?» У модератора возникает желание быстро показать правильное действие и продолжить исследование.
Но если помочь слишком рано, мы потеряем возможность понять, почему человек остановился. Поэтому я стараюсь сначала зафиксировать точку затруднения и только потом решать, требуется ли вмешательство.
Важно помнить, что цель тестирования — не добиться успешного прохождения прототипа любой ценой. Если участник не может выполнить задачу без помощи, это тоже результат исследования.
Не превращайте вопрос в подсказку
Когда пользователь останавливается, модератор может поддержать разговор, не раскрывая правильный маршрут.
Например, вместо «Попробуйте нажать на иконку в правом верхнем углу» лучше спросить: «Что вы сейчас пытаетесь найти?» Если человек рассматривает несколько элементов, можно уточнить: «Какой вариант кажется вам наиболее подходящим?» или «Что вы ожидаете увидеть после этого действия?»
Такие вопросы помогают восстановить логику пользователя.
Допустим, участник хочет изменить способ доставки и несколько раз возвращается на экран корзины. На вопрос исследователя он отвечает, что ожидает увидеть настройки доставки рядом с итоговой стоимостью заказа. В прототипе эта возможность появляется только на следующем этапе.
Теперь мы знаем не только то, что пользователь задержался. Мы получили конкретное ожидание, которое можно сравнить с поведением других участников.
При этом вопросов не должно быть слишком много. Если просить человека объяснять каждое нажатие, его поведение станет менее естественным. В обычной ситуации пользователь не анализирует интерфейс вслух после каждого действия.
Разделяйте самостоятельное выполнение и выполнение с помощью
При анализе результатов недостаточно записать, завершил ли пользователь сценарий. Важно учитывать, потребовалась ли ему помощь.
Представим, что пять участников дошли до последнего экрана. На первый взгляд успешность составляет 100%. Но двое справились самостоятельно, одному понадобился нейтральный вопрос модератора, еще двоим пришлось показать нужный элемент.
С точки зрения исследования это совершенно разные результаты.
Я обычно отдельно отмечаю момент первой помощи и ее характер. Это позволяет позже восстановить, какую часть сценария человек действительно прошел самостоятельно.
Особенно важно учитывать дальнейшее поведение после подсказки. Если модератор один раз объяснил принцип навигации, пользователь может применять полученное знание на всех следующих экранах. Поэтому нельзя считать последующие действия полностью независимыми от вмешательства исследователя.
Не спасайте пользователя от каждой ошибки
Иногда участник выбирает явно неправильный путь, и модератор сразу хочет вернуть его к основному сценарию. Но такое поведение может оказаться важнее правильного перехода.
Если пользователь открывает раздел, который команда вообще не связывала с заданием, стоит посмотреть, что он будет делать дальше. Возможно, именно там он ожидает найти нужную функцию.
Например, человек хочет изменить данные банковской карты и открывает «Безопасность», хотя команда разместила управление картами в разделе «Оплата». Если сразу сказать, что он находится не там, мы потеряем возможность выяснить причину выбора.
Лучше дать участнику немного времени. Он может самостоятельно понять, что ошибся, вернуться назад и выбрать другой путь. Способ восстановления после ошибки тоже характеризует понятность интерфейса.
Вмешательство становится оправданным, когда человек явно зашел в тупик и ситуация перестала давать новую информацию. Нет смысла несколько минут наблюдать за повторением одних и тех же действий только ради соблюдения принципа невмешательства.
Фиксируйте момент, а не общее впечатление
После теста легко написать в отчете: «У пользователя возникли сложности с оформлением заказа». Такая формулировка слишком широкая, чтобы на ее основании принимать решение.
Гораздо полезнее описать конкретную последовательность: пользователь перешел к оформлению, ожидал выбрать способ доставки до ввода адреса, не увидел такой возможности, вернулся в корзину и начал искать настройки там.
Теперь команда понимает, где возникло расхождение и какое ожидание стояло за действиями участника.
Я советую фиксировать три вещи: что пользователь хотел сделать, что он попытался сделать и чего ожидал в результате. Остальные детали можно добавлять уже при анализе записи.
Так исследователь меньше рискует смешать наблюдение со своей интерпретацией. Фраза «пользователь дважды нажал на изображение товара, ожидая открыть карточку» значительно полезнее, чем «карточка товара непонятная».
Молчание тоже дает данные
В модерируемом тестировании пауза часто кажется неловкой, но ее не обязательно немедленно заполнять вопросом. Пользователю может требоваться несколько секунд, чтобы прочитать текст, рассмотреть варианты или принять решение.
Если модератор начинает помогать при каждой паузе, нормальное изучение интерфейса можно ошибочно принять за затруднение.
Поэтому я обращаю внимание не только на продолжительность остановки, но и на поведение человека. Он спокойно читает содержимое экрана или несколько раз хаотично прокручивает его? Сравнивает варианты или возвращается к одним и тем же элементам? Действует уверенно после паузы или просит помощи?
Контекст позволяет отличить размышление от настоящего тупика.
Хорошая модерация мобильного теста — это баланс. Исследователь не оставляет участника бесконечно бороться с неработающим прототипом, но и не превращается в навигатор по интерфейсу. Чем меньше знаний о «правильном» пути мы передаем пользователю во время выполнения задания, тем лучше видим, способен ли мобильный продукт объяснить этот путь самостоятельно.
Один и тот же мобильный интерфейс может восприниматься по-разному в зависимости от того, где и как человек им пользуется. За столом участник внимательно читает каждую подпись и держит смартфон двумя руками. В реальной ситуации он может открывать приложение на ходу, переключаться между ним и другим сервисом или пытаться завершить действие одной рукой.
Воспроизвести абсолютно все реальные условия во время UX-теста невозможно, да это и не всегда требуется. Гораздо важнее понять, какие особенности контекста действительно способны повлиять на исследуемый сценарий.
Если мы проверяем сложную настройку, которую пользователи обычно выполняют спокойно и редко, лабораторное или удаленное тестирование вполне может дать необходимые данные. Если исследуется сценарий, рассчитанный на быстрое действие вне дома, искусственно комфортные условия способны скрыть часть проблем.
Отталкивайтесь от реального сценария
Перед тестированием я стараюсь ответить на вопрос: где и в какой ситуации пользователь обычно выполняет это действие?
Например, приложение для заказа еды чаще всего можно спокойно использовать дома или в офисе. А интерфейс электронного билета человек может открывать непосредственно перед посадкой, когда ему нужно быстро найти конкретную информацию. Навигационный сервис вообще предполагает взаимодействие в условиях ограниченного внимания.
Эти различия влияют на то, что именно стоит проверять.
Если пользователю нужно за несколько секунд показать код или найти номер заказа, длинный путь через несколько экранов может оказаться проблемой, даже если каждый отдельный экран понятен. В более спокойном сценарии дополнительные действия могут не создавать существенного затруднения.
Поэтому скорость выполнения задачи нельзя оценивать в отрыве от контекста. Само по себе утверждение «пользователь потратил 40 секунд» мало о чем говорит. Важно, допустимы ли эти 40 секунд для конкретной ситуации.
Обратите внимание на использование одной рукой
На мобильных прототипах расположение элементов особенно заметно, когда участник держит устройство так, как привык в повседневной жизни.
Если исследователь заранее кладет смартфон на подставку или просит держать его определенным образом, часть естественного поведения исчезает. Когда условия позволяют, я предпочитаю сначала просто передать устройство участнику и посмотреть, какой хват он выберет самостоятельно.
Это помогает обнаружить ситуации, когда для основного действия человеку постоянно приходится перехватывать смартфон. Особенно показательны повторяющиеся сценарии: например, добавление товаров, переключение между разделами или подтверждение небольших операций.
Но и здесь не стоит превращать отдельное наблюдение в универсальное правило. Люди держат смартфоны по-разному, размеры устройств отличаются, а некоторые пользователи изначально предпочитают взаимодействовать двумя руками.
Поэтому ценность представляет не сам факт необычного хвата, а его связь с конкретным затруднением.
Учитывайте отвлекающие факторы без искусственного усложнения теста
Иногда команда хочет сделать исследование «максимально реалистичным» и начинает специально создавать участнику помехи: просит идти во время выполнения задания, параллельно задает вопросы или ограничивает время.
Такой подход оправдан только тогда, когда соответствующий фактор действительно связан с исследовательской гипотезой.
Если мы проверяем приложение, которым предполагается пользоваться на ходу, движение может быть частью сценария. Но добавлять его в тест банковской настройки только потому, что продукт мобильный, необязательно.
Искусственные помехи способны создать новые ошибки, которые ничего не говорят о качестве интерфейса. В результате команда начнет оптимизировать продукт под экспериментальную ситуацию, редко возникающую в реальности.
Контекст должен помогать проверять гипотезу, а не просто делать исследование сложнее.
Удаленный тест тоже может быть реалистичным
Для проверки мобильного прототипа необязательно всегда находиться с участником в одной комнате. Удаленное исследование имеет свое преимущество: человек может использовать собственный смартфон в привычной обстановке.
Но такой формат требует технической подготовки. Исследователю нужно понимать, сможет ли он видеть экран участника, насколько удобно будет наблюдать за действиями и не создаст ли способ демонстрации дополнительные сложности.
Например, пользователь может испытывать трудности не с прототипом, а с переключением между видеозвонком и тестируемым интерфейсом. Если не отделить эти ситуации, результаты окажутся искаженными.
Перед основным исследованием полезно провести короткий технический прогон. Проверить ссылку на прототип, доступ с мобильного устройства, демонстрацию экрана и все действия, которые участнику потребуется выполнить до начала самого сценария.
Чем меньше технических инструкций приходится давать во время теста, тем естественнее будет дальнейшее взаимодействие.
Не пытайтесь проверить все контексты одновременно
Если продукт используется в разных ситуациях, не обязательно воспроизводить их в рамках одного исследования.
Предположим, мобильным приложением можно пользоваться дома, в магазине и непосредственно во время получения заказа. У этих сценариев разные задачи и ограничения. Объединение их в один длинный тест может утомить участника и усложнить анализ.
Я бы сначала выделил наиболее критичный контекст для конкретной гипотезы. После этого при необходимости можно провести отдельную проверку другого сценария.
Так результаты проще интерпретировать. Мы понимаем не просто, что «пользователям было сложно», а что определенное решение работает в спокойных условиях, но создает затруднение, когда действие нужно выполнить быстро.
Мобильность интерфейса заключается не только в размере экрана. Смартфон сопровождает пользователя в разных ситуациях, и условия использования могут менять требования к одному и тому же сценарию. Поэтому хороший тест не пытается искусственно воспроизвести всю жизнь пользователя, а выбирает тот контекст, который действительно способен повлиять на проверяемое решение.
Мобильное юзабилити-тестирование хорошо показывает, как именно пользователь взаимодействует с прототипом и почему в определенный момент возникает затруднение. Но небольшого числа сессий недостаточно, чтобы автоматически переносить наблюдение на всю аудиторию продукта.
Представим, что во время пяти тестов три участника попытались закрыть карточку свайпом вниз, хотя команда предусмотрела только кнопку. Это заметный сигнал и повод сформулировать гипотезу. Но утверждать, что большинство будущих пользователей ожидают именно такой жест, пока рано.
В таких случаях качественное исследование можно дополнить количественным. Сначала тестирование помогает обнаружить варианты поведения и причины затруднений, а затем опрос позволяет проверить отдельные выводы на более широкой аудитории.
Для подготовки такой анкеты можно использовать Тестограф: собрать ответы после тестирования или запустить отдельное исследование для нужного сегмента пользователей.
Проверяйте конкретное наблюдение
Я не рекомендую после каждого UX-теста отправлять участникам длинную анкету с общими вопросами об удобстве приложения. Если человек только что подробно прошел прототип вместе с исследователем, ответы вроде «Насколько удобным вам показался интерфейс?» редко объясняют обнаруженные проблемы.
Полезнее отталкиваться от конкретной гипотезы.
Например, участники тестирования по-разному понимают иконку, которая должна открывать историю действий. Тогда на более широкой выборке можно показать соответствующий фрагмент интерфейса и спросить, что, по мнению респондента, произойдет после нажатия.
Если во время тестов люди искали функцию в разных разделах, можно проверить ожидаемое расположение. Если возникли сомнения перед подтверждением операции — выяснить, какие последствия пользователи связывают с этим действием.
Так опрос становится продолжением наблюдения, а не отдельной оценкой продукта.
Спрашивайте об ожиданиях, а не только о понятности
В исследованиях интерфейсов вопрос «Вам всё понятно?» кажется естественным, но дает мало информации. Человек может ответить утвердительно и при этом совершенно иначе понимать результат действия.
Допустим, пользователь видит кнопку «Готово». Он считает ее понятной и ставит высокую оценку. Но один человек ожидает, что после нажатия изменения сохранятся как черновик, а другой — что данные будут окончательно отправлены.
Поэтому я предпочитаю проверять ожидаемый результат. Например: «Что, по вашему мнению, произойдет после нажатия этой кнопки?»
Варианты ответа можно сформировать на основании того, что участники говорили и делали во время предыдущих тестов. Если важно не ограничивать респондента готовыми интерпретациями, стоит добавить возможность сформулировать собственный ответ.
В Тестографе для этого можно сочетать разные типы вопросов: закрытые — когда нужно сравнить распространенность нескольких вариантов, и открытые — когда важно увидеть формулировки самих пользователей.
Не смешивайте оценку дизайна и выполнение задачи
После демонстрации мобильного экрана легко спросить, нравится ли пользователю его оформление. Такой вопрос может быть полезен для отдельной исследовательской задачи, но он практически ничего не говорит о способности человека выполнить сценарий.
Интерфейс может выглядеть современно и аккуратно, но пользователь не замечает основное действие. Или наоборот: визуально решение кажется ему непривычным, однако нужную функцию он находит быстро и без ошибок.
Поэтому субъективную оценку желательно сопоставлять с поведением.
Если после выполнения задания мы спрашиваем об уверенности пользователя, важно знать, действительно ли он завершил сценарий самостоятельно. Если просим оценить сложность, полезно учитывать количество возвратов, ошибочных переходов и подсказок модератора.
Именно сочетание этих данных помогает увидеть ситуации, в которых слова и действия расходятся.
Сегментируйте аудиторию осмысленно
Среднее значение по всем ответам может скрыть существенные различия между группами пользователей.
Например, большинство опытных клиентов сразу понимают привычную иконку, а новые пользователи интерпретируют ее иначе. Если объединить ответы, проблема может показаться небольшой. Но для продукта, который активно привлекает новую аудиторию, именно результат новичков будет особенно важен.
Поэтому в опрос можно добавить несколько вопросов для сегментации: пользовался ли человек продуктом раньше, насколько часто выполняет соответствующую задачу, знаком ли с похожими приложениями.
Не стоит при этом собирать большое количество характеристик респондента просто потому, что технически такая возможность есть. Каждый дополнительный вопрос должен быть связан с будущим анализом.
При подготовке исследования я обычно задаю себе вопрос: «Что мы будем делать по-разному, если ответы этих групп действительно окажутся разными?» Если понятного ответа нет, возможно, дополнительная сегментация не нужна.
Используйте количественные данные как проверку, а не замену UX-теста
Опрос не показывает взаимодействие с мобильным интерфейсом так же, как наблюдение за реальным пользователем.
Человек может правильно определить назначение кнопки на изображении, но не заметить ее во время выполнения задачи. Может выбрать ожидаемый раздел среди четырех предложенных вариантов, но в реальном приложении сначала искать функцию совершенно в другом месте.
Поэтому количественное исследование лучше использовать для проверки конкретных выводов, а не для полной замены тестирования прототипа.
С помощью онлайн-опроса Тестографа можно собрать данные у более широкой аудитории и сравнить ответы разных сегментов. После этого результаты стоит сопоставить с наблюдениями из мобильных тестов.
Так качественный этап отвечает преимущественно на вопросы «что происходит?» и «почему?», а количественный помогает понять «насколько это распространено?» и «для каких пользователей это характерно?».
В результате команда получает более надежную основу для решения. Не просто «три участника пытались сделать свайп», а, например: в качественных тестах мы обнаружили определенное ожидание, затем проверили его на более широкой аудитории и увидели, для какого сегмента оно действительно характерно.
Такой подход особенно полезен перед дорогостоящими изменениями мобильного продукта. Чем серьезнее предполагаемая переработка, тем важнее убедиться, что команда исправляет системную проблему, а не особенность поведения нескольких участников.
Мобильный прототип выполняет свою задачу не тогда, когда участникам нравится его внешний вид, а когда команда получает ответы на конкретные продуктовые вопросы. Может ли пользователь самостоятельно пройти сценарий? Понимает ли назначение элементов? Совпадают ли предусмотренные жесты с его ожиданиями? Может ли он восстановиться после ошибки и уверен ли в результате своего действия?
Именно поэтому тестирование стоит начинать не с демонстрации макета, а с гипотезы. Сначала определить, что именно мы хотим узнать, затем подготовить достаточный для этого прототип, подобрать релевантных участников и дать им реалистичные задания без подсказок.
Во время самого исследования я стараюсь смотреть на последовательность поведения: что пользователь ожидал → какое действие попробовал первым → что произошло → как он отреагировал → смог ли продолжить самостоятельно.
Для мобильного продукта эта последовательность особенно важна. Человек взаимодействует не с набором статичных экранов. Он нажимает, прокручивает, свайпает, меняет положение устройства, использует системные жесты и переносит в новый продукт привычки из других приложений. Иногда именно попытка выполнить действие, которого команда вообще не предусмотрела, дает наиболее полезный результат исследования.
При этом каждое затруднение нужно интерпретировать осторожно. Если пользователь не смог выполнить действие, причина может находиться в дизайне, логике сценария, формулировке задания или техническом ограничении прототипа. Поэтому я не рекомендую превращать запись теста непосредственно в список задач для дизайнера. Между наблюдением и изменением интерфейса должен появиться анализ причины.
Полезный рабочий цикл выглядит так: определить гипотезу → подготовить прототип → провести тест → зафиксировать поведение → найти причину затруднения → изменить решение → проверить новую версию.
Если качественного тестирования недостаточно для оценки масштаба проблемы, отдельные гипотезы можно проверить на более широкой аудитории с помощью Тестографа. В этом случае опрос дополняет наблюдение: тестирование помогает понять происхождение проблемы, а количественные данные — оценить, насколько обнаруженное ожидание или затруднение характерно для нужного сегмента пользователей.
Не стоит стремиться сделать прототип максимально похожим на готовое приложение перед первым исследованием. Детализация имеет смысл только тогда, когда она необходима для проверки конкретного вопроса. Иногда несколько связанных экранов позволяют обнаружить фундаментальную проблему в сценарии раньше, чем команда потратит время на визуальную проработку и разработку.
По этой же причине неудачное прохождение прототипа нельзя считать неудачным исследованием. Если участник не замечает действие, пытается использовать другой жест или идет по неожиданному маршруту, прототип дает команде информацию, ради которой его и тестировали.
Хороший результат такого исследования — не фраза «пользователям всё понравилось». Гораздо ценнее конкретный вывод: где ожидания пользователя расходятся с логикой продукта, почему это происходит и какое изменение мы собираемся проверить в следующей итерации.
Если мобильный прототип позволяет ответить на эти вопросы до разработки, он уже экономит команде значительно больше, чем время на исправление отдельных экранов. Он помогает проверить саму логику взаимодействия в тот момент, когда изменить ее еще относительно просто.