Surf 
Тендеры и лиды
Информация
Разбираем, как проверить понятность интерфейса на живых пользователях, в идеале на прототипе до написания кода: какими методами это делают, какие метрики смотреть и с чем их сравнивать, сколько нужно людей и как провести сессию, чтобы получить правду, а не вежливые «всё удобно».
Типичный спор в команде звучит так: «эта кнопка же очевидная» — «нет, её никто не заметит». Обе стороны уверены в своей правоте, обе опираются на интуицию, и выигрывает тот, кто громче или старше по должности. Проблема в том, что интуиция дизайнера и продакта — это интуиция людей, которые видели интерфейс сто раз и знают, где что лежит. Обычный пользователь видит его впервые. UX-тестирование заменяет спор о вкусах фактом: сажаешь пять человек из целевой аудитории, даёшь им реальную задачу и смотришь, справятся или нет.
Сразу разграничим три темы, которые постоянно путают. UX-исследования — это discovery до дизайна: интервью и изучение аудитории, чтобы понять, что вообще строить. Юзабилити сайта касается оптимизации уже готового и работающего сайта ради конверсии. А UX-тестирование, о котором эта статья, проверяет понятность конкретного интерфейса на пользователях, причём лучше всего проводить его на прототипе, пока продукт ещё не написан. Мы в Surf проводим UX/UI-аудит и юзабилити-тестирование на проектах постоянно, вместе с дизайном приложений и проектированием продукта; ниже практический разбор. Если нужен полный перечень методов, у нас есть подробный справочник по UX-тестированию.
У теста одна задача — увидеть, справится ли реальный человек с реальной задачей в вашем интерфейсе и где именно спотыкается. Не «нравится ли ему дизайн»: вкусовые оценки бесполезны, потому что люди хвалят из вежливости и часто хвалят то, чем не могут пользоваться. И не «нужен ли продукт вообще» — на этот вопрос отвечают раньше, на этапе исследований и анализа рынка.
Разница принципиальная. Когда вы спрашиваете «удобно ли вам?», человек отвечает мнением. Когда вы просите «оформите заказ» и молча смотрите, вы получаете поведение. Поведение не врёт: если пять человек подряд не находят корзину, значит, корзину не находят, что бы они потом ни говорили о «приятном дизайне».
Методов много, и выбор зависит от того, что проверяете и сколько у вас времени. Крупно они делятся на модерируемые, где рядом есть ведущий, и немодерируемые, где человек проходит тест сам через сервис. Первые дают ответ на вопрос «почему», вторые — «где» и на масштабе.
Модерируемый тест
Что проверяет: Почему человек спотыкается
Когда применять: Глубокая диагностика
Людей: 5–8
Инструмент: Zoom, Figma
Немодерируемый тест
Что проверяет: Где спотыкаются, на масштабе
Когда применять: Быстро и дёшево
Людей: 15–30
Инструмент: Maze, UsabilityHub
Коридорный тест
Что проверяет: Грубые проблемы на лету
Когда применять: Ранний прототип
Людей: 5
Инструмент: Живьём, прототип
First-click
Что проверяет: Куда нажмут первым
Когда применять: Навигация, поиск
Людей: 20+
Инструмент: Maze
5-секундный тест
Что проверяет: Что запоминается с первого взгляда
Когда применять: Первое впечатление
Людей: 15+
Инструмент: UsabilityHub
Tree testing
Что проверяет: Понятна ли структура меню
Когда применять: Информационная архитектура
Людей: 20+
Инструмент: Optimal Workshop
Три последних метода недооценены, а зря: это быстрые немодерируемые тесты, которые можно запустить за день без UX-команды. First-click показывает, туда ли люди кликают в первую очередь, пятисекундный тест — что вообще считывается с экрана за первые секунды, а tree testing проверяет понятность структуры разделов ещё до того, как нарисован дизайн. Если полноценный тест кажется дорогим, начните с них.
Самый частый вопрос заказчика — «пяти человек разве достаточно, это же не статистика». Для качественного юзабилити-теста — достаточно, и за этим стоит логика, а не экономия. Исследования Nielsen Norman Group показывают, что примерно пять пользователей выявляют около 85% проблем юзабилити. Дальше кривая выходит на плато: шестой и седьмой человек чаще всего спотыкаются о то, что вы уже видели.
Поэтому выгоднее не звать пятнадцать человек сразу, а протестировать на пяти, починить найденное и прогнать тест заново на новых пяти — так за те же деньги вы поймаете больше проблем в нескольких итерациях. Больше пяти нужно в других случаях: когда вы снимаете количественные метрики и нужна статистическая достоверность, когда сравниваете два варианта в A/B-тесте или когда у продукта несколько разных сегментов аудитории — тогда пятёрку берут на каждый сегмент.
Наблюдение отвечает на вопрос «где проблема», а метрики — «насколько всё плохо» и «стало ли лучше после правок». Их не обязательно снимать все сразу, но полезно знать, с чем сравнивать результат.
Успешность задачи — Как считать: Доля пользователей, выполнивших задачу; Ориентир: Средний уровень около 78%; ниже — есть проблема
Время на задачу — Как считать: Сколько времени ушло на выполнение; Ориентир: Сравнивают между версиями и с ожидаемым
Число ошибок — Как считать: Сколько неверных действий на задаче; Ориентир: Повторяющаяся у всех ошибка — это дефект
SUS — Как считать: Опросник из 10 вопросов, балл 0–100; Ориентир: Около 68 — средний уровень, выше — хорошо
SEQ — Как считать: Оценка сложности задачи по шкале 1–7 после неё; Ориентир: Ближе к 7 — задача далась легко
Главная ценность метрик — в сравнении. Один замер сам по себе мало что значит, но если после переделки экрана успешность задачи выросла с 60 до 90%, а среднее время упало вдвое, у вас есть доказательство, что изменения сработали, а не «стало красивее».
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13703 тендера
проведено за восемь лет работы нашего сайта.
Вот главный практический вывод, который экономит больше всего денег: тестировать интерфейс нужно как можно раньше, а не после того, как его написали. Интерактивный прототип в Figma можно дать пользователям и прогнать через Maze или UsabilityHub ещё до того, как разработчики начали работу. Человек кликает по макету так же, как кликал бы по готовому приложению, и спотыкается ровно в тех же местах.
Разница в цене ошибки огромна. Переставить кнопку или переписать формулировку в макете — работа на час. Та же правка в готовом продукте превращается в новую задачу разработчику, повторное тестирование и релиз, то есть в дни и деньги. Команды, которые тестируют прототипы, приходят в разработку с проверенным интерфейсом и не переделывают экраны по три раза уже в коде. Поэтому первый тест уместнее проводить не когда продукт готов, а когда готов кликабельный макет.
Тест легко испортить неправильной постановкой задачи. Главное правило — просить сделать, а не показывать как. «Найдите и закажите красное платье 46 размера с доставкой на завтра» — это задача. «Нажмите на кнопку каталога, потом на фильтр» — это уже инструкция, которая проверяет память, а не интерфейс. Для каждой задачи в сценарии удобно держать четыре вещи.
Задача — что попросить сделать, словами пользователя и без подсказок, как именно.
Контекст — в какой ситуации человек это делает, чтобы он вошёл в роль.
Критерий успеха — что именно считаем выполнением: товар в корзине, форма отправлена.
Вопросы после — что было непонятно, где он ожидал другого, а не «понравилось ли».
Во время сессии ведущий молчит и не помогает, даже когда очень хочется, — просит человека думать вслух и просто фиксирует, где тот застревает. Типичные способы получить бесполезный результат: подсказывать, задавать наводящие вопросы, тестировать на коллегах и друзьях вместо целевой аудитории и спрашивать про эмоции вместо наблюдения за действиями. Как только вы начали помогать, тест закончился — дальше вы проверяете себя, а не интерфейс.
Ценность выверенного интерфейса хорошо видна на продуктах, где от понятности напрямую зависят продажи. Для бренда Love Republic мы делали мобильное приложение, в котором проверяли интерфейсные решения на пользователях, а не полагались на догадки о том, что им удобно.
По данным кейса Love Republic, понятный интерфейс вместе с продуманными функциями (умный поиск, видеопримерка, персональные рекомендации) помог поднять конверсию в 2 раза при рейтинге приложения 4,9. Честно говоря, такой рост — вклад и функций, и UX сразу, но именно проверка понятности на реальных людях помогает не выкатывать в продакшн решения, которые кажутся удобными команде и оказываются неудобными покупателю.
Тест обесценивается не сложностью, а типовыми промахами в организации. Вот что встречается чаще всего.
Тест на своих. Проверяют на коллегах и знакомых, которые уже видели продукт или боятся вас расстроить. Нужны незнакомые люди из целевой аудитории.
Вопросы вместо наблюдения. «Вам удобно?» вместо «сделайте». Мнение врёт, поведение — нет.
Тест в самом конце. Проверяют готовый продукт, когда переделывать дорого. Правильный момент — прототип.
Собрали и забыли. Нашли проблемы, но не приоритизировали и не починили. Тест без исправлений — потраченное время.
UX-тестирование проверяет, справится ли человек с задачей в интерфейсе, а не нравится ли ему дизайн.
Для качественного теста хватает пяти пользователей — они находят около 85% проблем; больше нужно для количественных замеров и A/B.
Понятность измеряют метриками: успешность задачи, время, ошибки, SUS, SEQ — и главное сравнивают их до и после правок.
Тестировать выгоднее прототип, а не готовый продукт: правка в макете стоит часа, в коде — дней.
Сессию проводят на реальных задачах, ведущий молчит и наблюдает, а не подсказывает и не спрашивает про эмоции.
UX-тестирование — это способ заменить бесконечные споры о том, «очевидна ли кнопка», простым фактом: очевидна, если люди её находят. Несколько дней на проверку прототипа почти всегда дешевле, чем переделка готового интерфейса и потерянные из-за него клиенты. Поэтому проверять понятность стоит рано и на живых людях, а не на совещаниях.
Владимир Макеев, генеральный директор Surf — компании по разработке и дизайну цифровых продуктов для крупного и среднего бизнеса.
