Юзабилити-специалист: кто это, как проходит юзабилити-тестирование и как стать специалистом

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

Юзабилити (usability) по ISO 9241-11:2018 — степень, в которой система, продукт или услуга могут использоваться определенными пользователями для достижения определенных целей с результативностью, эффективностью и удовлетворенностью в определенном контексте использования. Важная часть определения — «конкретные пользователи и цели»: удобство не бывает «вообще», оно всегда для кого-то и для чего-то.

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

Кто это и чем отличается от соседних ролей

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

Разница с тестировщиком принципиальная. Ошибка для QA — несоответствие требованиям: кнопка «Оплатить» не списывает деньги. Проблема для юзабилити-специалиста — кнопка работает, но трое из пяти участников ее не нашли. Продукт может пройти все тест-кейсы и все равно быть неудобным.

Как проходит модерируемое юзабилити-тестирование

Самый показательный формат — модерируемый тест: модератор ведет сессию лично или по видеосвязи и может задавать уточняющие вопросы. Шаги:

1. Цели и гипотезы. С продуктовой командой формулируют, что проверяем: например, «пользователи не понимают, где изменить адрес доставки».
2. Сценарий. Задачи пишут как жизненные ситуации, без подсказок в формулировке: «вы переезжаете, сделайте так, чтобы заказ приехал на новый адрес», а не «нажмите «Профиль» -> «Адреса»».
3. Рекрутинг. Участников подбирают по признакам целевой аудитории (скринер-анкета). Коллеги и друзья команды подходят только для черновой проверки.
4. Пилотная сессия. Один прогон на «своем» человеке, чтобы поймать непонятные задачи и технические сбои.
5. Сессии. Обычно 45-90 минут: вводная, задачи, вопросы после каждой задачи, итоговая анкета. Участника просят думать вслух (think-aloud), модератор не подсказывает.
6. Анализ. Каждую проблему фиксируют с частотой (сколько участников столкнулось) и критичностью (блокирует задачу или только замедляет).
7. Отчет и приоритизация. Итог — не пересказ сессий, а список проблем с доказательствами (цитата, фрагмент записи) и рекомендациями.

Типичные метрики: доля успешно выполненных задач, время на задачу, число ошибок, субъективная оценка сложности после задачи и итоговый опросник вроде SUS.

Методы: что выбрать под задачу

Ни один метод не отвечает на все вопросы. Выбор начинается с того, что нужно узнать: «почему неудобно» (качественные методы) или «насколько лучше / хуже» (количественные).

Коридорное тестирование (hallway testing) — упрощенная форма: пять-шесть случайных людей «из коридора» проходят задачу на прототипе. Метод хорош для раннего отсева грубых ошибок, но не заменяет тест с целевой аудиторией.

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

Практика: как посчитать SUS

SUS (System Usability Scale) — анкета из 10 утверждений, предложенная Джоном Бруком. Участник оценивает каждое по шкале от 1 («совершенно не согласен») до 5 («полностью согласен»). Нечетные утверждения позитивные («я бы хотел пользоваться системой часто»), четные — негативные («система неоправданно сложна»), поэтому их вклад считают по-разному.

Правило подсчета: для нечетных вопросов берется оценка минус 1, для четных — 5 минус оценка; сумма умножается на 2,5. Получается балл от 0 до 100. Это не процент и не процентиль, а условная шкала.

Минимальный рабочий пример на Python (проверено на Python 3.14):

def sus_score(answers):
    """SUS одного участника: 10 оценок по шкале 1..5 -> балл 0..100."""
    if not isinstance(answers, (list, tuple)) or len(answers) != 10:
        raise ValueError("нужен список из 10 оценок")
    total = 0
    for i, a in enumerate(answers, start=1):
        if isinstance(a, bool) or not isinstance(a, int) or not 1 <= a <= 5:
            raise ValueError(f"вопрос {i}: ожидается целое 1..5, получено {a!r}")
        # нечетные утверждения позитивные, четные - негативные
        total += (a - 1) if i % 2 == 1 else (5 - a)
    return total * 2.5


respondents = {
    "P1": [4, 2, 4, 1, 5, 2, 4, 2, 4, 2],
    "P2": [3, 3, 4, 2, 3, 3, 4, 3, 3, 2],
    "P3": [5, 1, 5, 1, 4, 1, 5, 1, 5, 2],
    "P4": [2, 4, 3, 3, 3, 4, 2, 4, 2, 3],
    "P5": [4, 2, 4, 2, 4, 2, 4, 2, 4, 1],
}

if __name__ == "__main__":
    scores = [sus_score(a) for a in respondents.values()]
    for name, s in zip(respondents, scores):
        print(f"{name}: {s}")
    print(f"Среднее SUS: {sum(scores) / len(scores):.1f}")

Сохраните код как sus.py и запустите python3 sus.py. В консоли появится:

P1: 80.0
P2: 60.0
P3: 95.0
P4: 35.0
P5: 77.5
Среднее SUS: 69.5

Как читать: в литературе по SUS (Сауро, Льюис) средним ориентиром считают около 68 баллов, так что 69,5 — «на уровне среднего». Но разброс от 35 до 95 важнее среднего: участник P4 явно застрял, и его запись стоит пересмотреть первой. На пяти участниках SUS — грубый ориентир, а не точная оценка.

Типичная ошибка — сложить оценки без инверсии четных вопросов:

from sus import respondents

def sus_wrong(answers):
    return sum(answers) * 2.5  # ошибка: четные вопросы не инвертированы

print(sus_wrong(respondents["P4"]))

Результат — 75.0 вместо правильных 35.0: самый недовольный участник выглядит довольным, потому что его высокие оценки негативных утверждений («система сложна») пошли в плюс. Исправление — формула из sus_score выше.

Функция отклоняет некорректные анкеты, а не считает мусор. Проверка злыми входами:

from sus import sus_score

for bad in ([4] * 9, [4] * 9 + [6], [True] * 10, [4] * 9 + ["2"], "4242424242"):
    try:
        sus_score(bad)
    except ValueError as e:
        print("ValueError:", e)

ValueError: нужен список из 10 оценок
ValueError: вопрос 10: ожидается целое 1..5, получено 6
ValueError: вопрос 1: ожидается целое 1..5, получено True
ValueError: вопрос 10: ожидается целое 1..5, получено '2'
ValueError: нужен список из 10 оценок

True отсекается отдельно: в Python bool — подкласс int, и без проверки True прошел бы как оценка 1.

Сколько участников нужно

Популярное правило «пяти пользователей» идет от модели Нильсена и Ландауэра: доля найденных проблем равна 1 — (1 — p)^n, где p — вероятность, что один участник встретит проблему (в их данных в среднем около 0,31).

p = 0.31  # средняя доля участников, встречающих проблему (оценка Nielsen/Landauer)
for n in (1, 3, 5, 8, 12):
    print(f"{n:>2} участн.: найдено ~{1 - (1 - p) ** n:.0%} проблем")

 1 участн.: найдено ~31% проблем
 3 участн.: найдено ~67% проблем
 5 участн.: найдено ~84% проблем
 8 участн.: найдено ~95% проблем
12 участн.: найдено ~99% проблем

Это упрощенная модель: она считает, что все проблемы одинаково частые. Редкие проблемы (p около 0,1) пять человек чаще всего пропустят. Поэтому «пять участников» — правило для качественного теста одной группы пользователей в итеративном цикле. Для сравнения версий по метрикам, для нескольких сегментов аудитории и для A/B выборка нужна намного больше.

Как стать юзабилити-специалистом

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

1. База. ISO 9241-11, 10 эвристик Нильсена, разница между качественными и количественными методами, этика работы с участниками (согласие на запись, хранение персональных данных).
2. Эвристический аудит. Выберите знакомый сервис и разберите один сценарий (регистрация, оформление заказа) по эвристикам: 10-15 находок со скриншотами.
3. Свой первый тест. Сценарий на 3-4 задачи, 5 участников из подходящей аудитории, запись экрана с их согласия.
4. Отчет. Проблемы с частотой, критичностью, доказательствами и рекомендациями; SUS по анкетам.
5. Портфолио. Кейс «задача -> метод -> находки -> что бы изменилось» — главный аргумент на собеседовании для этой роли.

Реалистичный срок до портфолио из двух-трех кейсов — несколько месяцев регулярной практики, в зависимости от стартовой базы.

Частый вход — через тестирование. Тестировщик уже умеет искать дефекты, писать воспроизводимые описания и думать сценариями пользователя. О самой профессии QA подробнее — в статье кто такой тестировщик.

Если не получилось

• Участники выполняют все задачи без проблем. Скорее всего, в формулировке задачи есть подсказка (слова из интерфейса) или участники не из целевой аудитории. Перепишите задачу через жизненную цель.
• Участник молчит. Напомните про думание вслух нейтральным вопросом: «что вы сейчас ищете?». Не спрашивайте «вам удобно?» — это наводящий вопрос.
• Отчет не читают. Сократите до топ-5 проблем с видеофрагментами и оценкой критичности; полный список — в приложение.
• Результаты противоречат аналитике. Качественный тест показывает причины на малой выборке, аналитика — масштаб. Сверьте, на каком шаге воронки отваливаются пользователи, и проверьте именно этот шаг.

Выводы

• Юзабилити-специалист проверяет, могут ли реальные пользователи выполнить задачи в продукте, и объясняет, где и почему они ошибаются.
• Отличие от QA: тестировщик проверяет соответствие требованиям, юзабилити-специалист — удобство для конкретных людей и целей.
• Методы выбирают по вопросу: модерируемый тест и коридорный отвечают «почему», A/B и SUS — «насколько лучше».
• SUS считается с инверсией четных вопросов; без нее результат искажается до противоположного.
• «Пять участников» — правило для качественного теста одной аудитории, а не для сравнения метрик.

Где применяется / связь с практикой

Юзабилити-тестирование нужно везде, где у продукта есть живой пользователь: интернет-магазины, банковские приложения, внутренние корпоративные системы. Сильнее всего работает связка с QA: тестировщик ловит функциональные дефекты, юзабилити-проверка — сценарии, где продукт формально работает, но людям неудобно.

Смежная тема: тестировщик — описание специальности и ее особенности.

FAQ

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

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

Нужно ли юзабилити-специалисту уметь программировать?
Для основной работы — нет. Полезны базовый SQL или Python для анализа данных и понимание, как устроен фронтенд, чтобы рекомендации были реализуемыми.