Атрибут
Usability

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

Главный инструмент валидации Usability—это юзабилити-тестирование, позволяющее на практике изучить, как реальный пользователь взаимодействует с продуктом. Этот метод выявляет потенциальные барьеры, трудности и непредусмотренные сценарии, делая акцент на оптимизации интерфейса для легкости освоения и быстрого выполнения задач.

Чтобы понять, как проработать атрибут—то есть, протестировать, насколько удобно пользоваться продуктом—нужно придерживаться следующей последовательности шагов:

Атрибут Usability изучается в самую последнюю очередь, после проработки атрибута “Appearance”. Когда протитипы идей протестированы, и у вас есть подтверждение того, что пользовательская задача решается полноценно в сравнении с аналогами или конкурентами, вы отрисовываете финальные макеты и выносите их на юзабилити-тестирование.

Давайте подробнее разберем весь процесс.

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

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

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

Гипотеза в юзабилити-тестировании—это обоснованное предположение о том, как пользователь будет взаимодействовать с определенными элементами интерфейса для выполнения конкретной задачи.

Основные правила формулирования гипотезы:

После идентификации потенциальных проблем необходимо оценить, насколько серьезное влияние они могут оказать на пользователя и на бизнес. Это позволит отранжировать зоны для тестирования по приоритетам (самые важные выносим в начало теста, наименее важные—в конец). Если на последние не хватает времени, можно либо отказаться от их изучения, либо перенести на следующую сессию.

Для оценки серьезности потенциальных проблем для пользователя и для бизнеса я использую шкалу критериев от 1 до 5, где 1—проблема вызывает незначительные неудобства, которые не сильно влияют на общий опыт использования продукта, а 5—проблема препятствует основной функциональности продукта или вызывает значительные неудобства для пользователя.

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

Я использую сочетание методов наблюдений (observation) и размышлений вслух (think aloud). Суть заключается в том, что вы даете респонденту задание, просите его озвучивать весь мыслительный процесс, наблюдаете за тем, сталкивается ли он с теми проблемами, которые мы определили на этапе анализа, и, если да, то задаем уточняющие вопросы, чтобы выяснить причину сложностей, с которыми он сталкивается.

Формула для составления основного задания довольно простая: попросить выполнить конкретный этап в конкретном сценарии использования.

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

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

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

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

Для оценки восприятия сложности задания я использую SEQ-вопрос по 7-балльной шкале, задавая его респонденту после каждого задания. Основной акцент—на дополнительном вопросе: "Что еще было некомфортного?", который помогает выявить новые проблемы и инсайты, даже если респондент уже оценил сложность.

План сценария состоит из 3 элементов:

В большинстве случаев достаточно 5 участников. Якоб Нильсен, один из ведущих экспертов в области юзабилити, утверждает, что тестирование с пятью пользователями может выявить около 85% проблем юзабилити. Дополнительные пользователи после пятого обычно приносят убывающую отдачу в плане новых информационных взглядов.

Хорошо с этой задачей справляется и AI (chatGPT или DeepSeek). Попросите его сгенерировать разные источники поиска респондентов, а затем начинайте сам поиск нужных вам людей.

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

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

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

Процесс будет строиться так:

В итоге, получается отсортированный список проблем, который можно брать в работу. В дополнение, можно провести еще один раунд тестирования, чтобы убедиться, что все проблемы решены. Больше 2 циклов проводить не стоит—количество получаемой информации увеличиваться не будет.