Как сделать тестирование частью работы команды

Чему научитесь

Встраивать тест в рабочий цикл — когда, на чём, кто участвуетконструктор ритма
Вести базу участников и не звать одних и тех жетренажёр
Разбирать спорный результат: пятеро споткнулись, а метрика не проселатренажёр
Оценивать последствия и стоимость проблем, и объяснять основания для приоритетакалькулятор
Видеть границу метода — где тест не ответиттренажёр

1Что меняется на этой ступени

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

	Middle	Senior
Повод	появился спорный экран	есть регулярное время для проверки важных вопросов
Кто проводит	вы	подготовленные коллеги; вы помогаете поддерживать качество
Участники	ищете под конкретную задачу	база с ротацией, рекрутинг заранее
Спорный результат	объясняете основания вывода	разбираете вместе с менеджером продукта и аналитиком
Язык	находки и серьёзность	риск, стоимость, вероятность
Куда попадают находки	в макет и план изменений	в бэклог и в документ решений команды
Что мешает практике	отчёт без решений по находкам	результаты тестов не учитываются при принятии решений

Две ловушки ступени

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

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

2Ритм: когда тестируем, на чём, кто участвует

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

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

Конструктор ритма · пример плана на 12 недель

Н1 ●

Н2 ●

Н3 ●

Н4 ●

Н5 ●

Н6 ●

Н7 ●

Н8 ●

Н9 ●

Н10 ●

Н11 ●

Н12 ◆

Еженедельно · 12 слотов за квартал

Кому подходитКомандам, которые выпускают изменения каждую неделю и у которых есть поток вопросов

НагрузкаВремя сессий, подготовки, поиска участников и разбора; посчитайте нагрузку каждой роли

ПлюсКороткий промежуток между вопросом и проверкой, если участники и задания готовы

РискПлотный график может перегрузить команду. Нужны подготовленные ведущие и план поиска участников

Участников за квартал38 — 11 серий по 3 и одна серия из 5 в этом плане

Н1 ·

Н2 ●

Н3 ·

Н4 ●

Н5 ·

Н6 ●

Н7 ·

Н8 ●

Н9 ·

Н10 ●

Н11 ·

Н12 ◆

Раз в спринт · 6 слотов за квартал

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

НагрузкаЗависит от числа сессий, поиска участников и объёма разбора; учтите работу всех ролей

ПлюсСовпадает с планированием: результат теста успевает попасть в решение о следующем спринте

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

Участников за квартал20 — 5 серий по 3 и одна серия из 5 в этом плане

Н1 ·

Н2 ·

Н3 ●

Н4 ●

Н5 ·

Н6 ·

Н7 ·

Н8 ●

Н9 ●

Н10 ·

Н11 ·

Н12 ◆

Волнами · две серии плюс финальная

Кому подходитПроектной работе, агентствам, командам с редкими крупными релизами

НагрузкаНагрузка сосредоточена в неделях 3–4, 8–9 и 12

ПлюсМожно организовать поиск участников под отдельные этапы проекта

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

Участников за квартал17 — 4 серии по 3 и одна серия из 5 в этом плане

Значки: ● серия из 3 участников · ◆ серия из 5 участников · пусто — недели без тестов. Выбор между режимами — это выбор между скоростью обратной связи и нагрузкой на команду, и он зависит от того, как часто команда выпускает изменения и принимает решения.

На чём тестировать: что кладём в слот

На планировании выберите вопросы для ближайшей серии. Возможные приоритеты:

Решения перед разработкой. Пока изменения существуют в макете, их часто проще пересмотреть.
Вопросы, по которым команда не согласна. Уточните, какие наблюдения помогут выбрать решение и подходит ли для этого тест.
Сценарии, где изменилась метрика. Наблюдение за действиями может помочь найти возможные причины; их ещё нужно проверить.
Повторная проверка правок. Сохраните сопоставимые условия и подбери число участников под исходный вопрос.
Если нового вопроса нет, проверьте, осталась ли неопределённость в главных сценариях. Если проверять пока нечего, используйте слот для разбора данных, подготовки или обучения коллег.

Кто участвует и с какой ролью

Роль	Что делает	Примерная нагрузка на серию
Ведущий	модерирует сессии; меняется по очереди между дизайнерами	3–4 часа
Записывающий	ведёт протокол; хорошая роль для новичка и для разработчика	2–3 часа
Наблюдатели	смотрят живьём, молча, в отдельном канале; по одному от продукта и разработки	1 час
Разбор	30 минут после серии: что видели, что с этим делаем	30 минут
Ответственный за практику	ревью сценария до, разбор находок после, ведение базы участников	2–3 часа

Приглашайте коллег наблюдать за сессиями. Им будет проще понять находку, если они увидят действия участника. Заранее объясните участнику, кто присутствует и зачем. Наблюдатели не подсказывают и передают вопросы ведущему; общий разбор проходит после сессии.

Начните с посильного объёма. Три сессии по 40 минут и полуторачасовой разбор — это уже 3,5 часа, без подготовки, поиска участников и оформления результатов. Посчитайте всю нагрузку и выберите ритм, который команда сможет поддерживать. После нескольких циклов скорректируйте план.

3База участников

База участников помогает планировать поиск людей и учитывать их прошлый опыт в исследованиях.

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

Поле	Зачем
Код участника	П-041 вместо имени; имена и контакты — в отдельном закрытом файле
Сегмент по поведению	новый / регулярный / вернувшийся; с мобильного / с десктопа — критерии, по которым отбираете участников
Последнее участие	главное поле: по нему работает правило ротации
В каких тестах был	чтобы не звать человека повторно на тот же сценарий
Согласия	на запись, на хранение, на повторные приглашения — и срок действия
Организационная заметка	предпочтительный способ связи, нужные условия участия, прошлые договорённости — без оценок личности

Правила ротации

Договоритесь о паузе между приглашениями. Она зависит от задачи, частоты исследований и опыта аудитории. Три месяца можно взять как правило конкретной команды, но это не универсальная граница.
Для проверки первого знакомства приглашайте новых людей. Повторное участие в том же сценарии может повлиять на результат. Если изучаете обучение или изменение опыта со временем, повторные сессии, наоборот, могут быть нужны.
Учитывайте историю участия. Число прошлых тестов само по себе не делает человека неподходящим. Проверьте, что он уже видел и насколько его опыт соответствует аудитории.
Пополняйте базу заранее: например, через анкету в продукте или приглашение от поддержки. Объясните, для чего собираются контакты и как отказаться от приглашений.
Планируйте резерв. Заранее договоритесь с резервным участником об условиях ожидания, отмены и вознаграждения. Не приглашайте лишнего человека без объяснения его роли.
Регулярно пересматривайте базу: проверяйте актуальность данных, договорённости о контактах и сроки хранения.

Тренажёр 1 · кого можно звать на тест 12 марта0 из 6

Тест про первое знакомство с оформлением возврата с телефона. Нужны люди, покупавшие с телефона за последние два месяца. Для упражнения команда установила паузу три месяца и лимит три участия. Также нужно действующее согласие на приглашения.

П-018Покупала в феврале с телефона · последнее участие: ноябрь · 1 участие · согласие действуетПо данным карточки человек подходит: нужный опыт есть, пауза выдержана, лимит учебной команды не достигнут.
П-023Покупал в марте с телефона · последнее участие: январь · 2 участия · согласие действуетНе соблюдена трёхмесячная пауза, принятая в этом упражнении. Для будущего приглашения проверьте точную дату предыдущего участия.
П-031Покупала в феврале с телефона · последнее участие: сентябрь · 3 участия · согласие действуетДостигнут лимит, заданный учебной командой. В реальном исследовании пригодность зависит от нужного опыта и содержания прошлых сессий.
П-044Покупал в марте с десктопа, приложением не пользуется · последнее участие: не было · согласие действуетНет нужного опыта покупки с телефона. Для этой серии не подходит; можно рассмотреть для исследования компьютерного сценария.
П-052Покупала в марте с телефона · последнее участие: июль · 1 участие · участвовала в тесте про возвратЗдесь изучают первое знакомство с возвратом, а человек уже видел этот сценарий в тесте. Для этой задачи нужен другой участник.
П-067Покупал в феврале с телефона · последнее участие: не было · согласие на приглашения истекло в декабреПо условиям упражнения нет действующего согласия на приглашения. Не используйте этот контакт для нового приглашения; дальнейшие действия определите по согласованным правилам команды.

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

4Спорный результат: тест против метрики

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

На тесте пять человек затруднились, а конверсия не изменилась. Это ещё не делает тест или метрику неверными. Сначала проверьте, сопоставимы ли данные: кто участвовал, какое задание выполнял, что именно измеряет метрика и за какой период. Затем выдвигайте и проверяйте объяснения.

Возможная причина	Как проверить
Люди достигают цели, но тратят больше усилий	Посмотреть время прохождения шага и число возвратов назад. Рост времени при той же конверсии — повод подробнее разобрать шаг
Метрика слишком крупная	Общая конверсия покупки размывает шаг. Смотреть метрику именно этого шага и именно этого сегмента
Проблема у сегмента, который мал в цифрах	Разбить метрику по новым и опытным, по устройствам. Небольшой сегмент может затеряться в общей картине
Отвал случается позже	Смотреть не шаг, а возвраты, обращения в поддержку, повторные покупки. Человек дошёл, но больше не вернулся
Проблема есть, но её обходят вне продукта	Смотреть обращения в поддержку и звонки. Проверить, помогают ли операторы завершить этот сценарий
Условия теста повлияли на результат	Перечитать задание: не было ли в нём слов из интерфейса, не подсказывал ли ведущий, годился ли прототип
Выборка не та	Проверить, кого звали. Пять новичков против метрики по всей базе — сравниваются разные группы
Метрика считается неверно	Спросить аналитика, что именно попадает в числитель. Бывает, что шаг засчитывается по загрузке экрана, а не по действию

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

Как вести такой разговор

Начните с того, что известно. «В тестах было затруднение, а в этой метрике изменения не видно. Проверим, что именно мы сравниваем».
Сформулируйте вопрос для разбора. Какие различия в условиях или измерениях могут объяснить две картины?
Сформулируйте конкретный запрос к аналитике: шаг, сегмент, период и нужный показатель. Например, время прохождения и число обращений по теме.
Покажите фрагмент записи вместе с контекстом. Добавьте задание, условия и количество похожих случаев. Яркий эпизод не заменяет всей картины.
Проверьте ограничения самого теста. Если задание подсказывало путь или прототип был упрощён, объясните влияние этого на выводы.
Договоритесь о следующем шаге: изменить, оставить как есть или проверить дополнительно. Укажите ответственного и срок.

Тренажёр 2 · что здесь происходит

Трое из пяти не нашли отмену и открыли поддержку. Число завершённых отмен в продукте не изменилось. По журналу обращений видно: операторы стали чаще отменять заказы по просьбе клиентов.
Помогает поддержкаДанные обращений показывают, что часть действий выполняют операторы. Следующий шаг — оценить объём такой помощи и выяснить, почему люди к ней прибегают.
Пять новых пользователей не нашли фильтр. Общая доля использующих его — 40 %. Разбивка показывает: среди новичков фильтр почти не используют, большинство применений приходится на опытных.
Проблема у сегментаРазбивка выявила разные сценарии у новичков и опытных пользователей. Общая доля не описывает отдельно группу, которая участвовала в тесте.
В тесте все пятеро легко оформили заказ. На реальном шаге часть людей уходит. При разборе выяснилось: в прототипе адрес был заполнен заранее, а в продукте его нужно вводить.
Повлияли условия тестаУсловия различаются: тест не проверил ручной ввод адреса. Это ограничение результата; чтобы разобраться с этим шагом, нужен соответствующий сценарий.
Двое не заметили, что подписались на рассылку. Продукт говорит: «Зато отписок мало, значит, всё нормально».
Показатель не отвечает на вопросМалое число отписок не показывает, осознанно ли люди подписались. Проверьте понятность согласия и последующее поведение; жалобы на спам и открытия могут дополнить картину, но не заменяют этот вопрос.
Тест показал затруднение при вводе адреса. Конверсия шага 96 %, не падала год. Аналитик уточняет: шаг засчитывается по загрузке экрана.
Показатель не отвечает на вопросЗагрузка экрана не равна успешному заполнению адреса. Нужно выбрать событие, которое соответствует вопросу, и проверить корректность его регистрации.
Все пятеро опытных пользователей с компьютера справились за 20 секунд. По аналитике этот сегмент тоже проходит быстро, а среднее 2:40 по всей аудитории связано главным образом с новыми пользователями телефона.
Проблема у сегментаОбщее среднее объединило разные группы. Тест описывает опытных пользователей компьютера; для разбора мобильного сценария нужны данные соответствующего сегмента.

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

5Язык риска и стоимости

Опишите последствия проблемы и покажите, какие данные есть для оценки её масштаба.

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

Калькулятор · оценка по заданным предположениям

Сколько человек в месяц проходят этот сценарийиз аналитики; в примере все значения условные

Предполагаемая доля столкнувшихся с проблемойнаблюдение 3 из 5 не задаёт эту долю; укажите источник или предположение 30 %

Какое последствие оцениваем

Стоимость одного обращения, ₽

—

Условный расчёт за месяц по введённым предположениям.

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

Как описывать последствия конкретнее

Вместо этого	Возможная формулировка
«Пользователям неудобно отменять заказ»	«Трое из пяти не нашли отмену и открыли поддержку. Проверим, сколько обращений связано с отменой и какую часть можно сократить правкой»
«Форма перегружена»	«В форме девять полей. Проверим, какие нужны для первой покупки и на каких у участников возникают трудности»
«Непонятный статус заказа»	«Участники спрашивали, что означает статус. Проверим обращения по этой теме и сопоставим их с наблюдениями»
«Это плохая практика»	«После этого действия данные нельзя восстановить, а предупреждение участник не заметил. Нужно проверить риск потери и способы его снизить»

Когда можно отложить правку

Последствия ограничены и обратимы. Оцените, кому мешает проблема и как её обходят. Запишите причину отсрочки и условия пересмотра.
Стоимость изменения пока выше ожидаемой пользы. Сравните варианты, включая небольшую временную правку. Укажите неопределённость оценки.
Проблему уже учитывает запланированная переделка. Проверьте, что она действительно включена в план, и оцените последствия ожидания.
Риск потери денег или данных требует отдельного решения. Не откладывайте его только из-за малого числа случаев. Обсудите срочные меры, которые снизят риск до полноценного исправления.

6Граница метода

Выбирайте метод под вопрос и заранее объясняйте границы выводов.

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

Вопрос	Тест не ответит, потому что	Что использовать
Какой из двух вариантов даст больше конверсии	по пяти участникам нельзя надёжно сравнить конверсию аудитории	A/B-тест
Сколько людей сталкивается с проблемой	небольшая качественная серия не оценивает долю во всей аудитории	Аналитика, подходящий опрос или количественное исследование
Нужна ли эта функция вообще	участник выполняет заданный сценарий, а не выбирает функцию в жизни	Проблемное интервью, анализ спроса
Будут ли этим пользоваться через месяц	первое впечатление не предсказывает привычку	Дневниковое исследование, когортный анализ
Готов ли человек за это платить	выполнение заданного действия не доказывает готовность купить	Продажи, предзаказы, эксперимент с ценой
Какой текст лучше продаёт	обсуждение текста и действия в тесте не измеряют реальные продажи	A/B-тест на живом трафике
Соответствует ли экран стандартам доступности	пользовательские сессии не заменяют проверку требований стандарта	Аудит требований доступности и тесты с людьми с разными ограничениями
Что сломается при 10 000 записей в таблице	результат на трёх строках не показывает работу с большим объёмом	Тест на реальных данных, нагрузочный прогон

Тренажёр 3 · чем это проверять

Найдут ли люди новую кнопку отмены на переделанном экране?
Юзабилити-тестНаблюдение покажет, как участники ищут кнопку. Число сессий зависит от аудитории и задачи; универсального числа для такой проверки нет.
Какой из двух вариантов заголовка даст больше регистраций?
A/B-тестВопрос про конверсию и сравнение вариантов. Пять человек не дают статистики, а разница может быть в доли процента.
Как часто наши пользователи вообще отменяют заказы?
Аналитика или опросЧастоту отмен удобнее оценивать по корректно зарегистрированным событиям продукта. Небольшая качественная серия для этого недостаточна.
Почему люди вообще отменяют заказы — что происходит у них в жизни?
ИнтервьюПричины и контекст за пределами интерфейса. На тесте участник отменяет заказ по заданию ведущего.
Понятно ли из нового статуса заказа, что будет дальше?
Юзабилити-тестПопросите участника объяснить статус своими словами и выполнить связанное задание. Так можно проверить его понимание в контексте.
Будут ли люди пользоваться этим разделом через месяц после релиза?
Аналитика или опросПервое впечатление не предсказывает привычку. Нужен когортный анализ после релиза или дневниковое исследование.
Стоит ли нам вообще делать функцию подписки на товар?
ИнтервьюИнтервью поможет разобраться в опыте и потребностях. Для решения о функции его стоит дополнить данными о спросе; одни рассказы не подтверждают будущие покупки или использование.

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

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

7Порядок тестирования на квартал

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

Порядок тестирования · шаблон

Порядок юзабилити-тестирования · квартал [ ]

Зачем

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

Ритм

Пример ритма: каждый второй четверг, 3 участника по 40 минут, с перерывами между сессиями.
Разбор — в тот же день, 30 минут, сразу после последней сессии.
Перед крупным релизом — отдельный план исследования под его вопросы и аудиторию.
Если подходящего вопроса для теста нет, используем слот для разбора данных, подготовки или обучения. Изменение плана фиксируем.

Что попадает в слот

Решается на планировании спринта, в таком порядке приоритета:

То, что уходит в разработку в следующем спринте.
Место, где команда разошлась во мнениях.
Сценарий, где просела метрика.
Повторная проверка правок прошлого цикла.

Роли

Ведущий — подготовленные коллеги по очереди. Новые ведущие сначала проводят сессию вместе с опытным.
Записывающий — коллега, знакомый с протоколом и правилами отделения наблюдений от выводов.
Наблюдатели — согласованные коллеги из продукта и разработки. Участник знает об их присутствии; они не вмешиваются в задания.
Ответственный за метод — [имя]: ревью сценария до, разбор находок после, ведение базы участников.

Обязательные шаги

Бриф на полстраницы: какое решение проверяем, критерий успеха и провала, три задания.
Ревью сценария — до первого участника, у любого коллеги с опытом.
Проверка прототипа по чек-листу.
До сессии объясняем условия участия и записи: доступ [кто], хранение [срок], удаление [порядок]. Фиксируем согласие предусмотренным в команде способом; запись без него не включаем.
Разбор в тот же день: находки с серьёзностью.
Находки — в общий список в течение суток. Для значимых случаев фиксируем решение и следующий шаг.

Куда попадают находки и как принимаются решения

Маршрут находки

Критичные — сразу сообщаем ответственному и согласуем меры снижения риска, срок и способ проверки.
Высокие — задача в бэклог, приоритет обсуждается на планировании.
Низкие и мелочи — в общий список наблюдений, без задач.
У каждой задачи — наблюдение, число случаев и ссылка на соответствующий момент записи, если она есть. Цитату добавляем, когда она поясняет находку.

Документ решений

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

Дата · что решили · на основании чего · кто участвовал в решении.
Указываем, как результаты повлияли на решение: изменить, сохранить или проверить дополнительно.
Журнал живёт там же, где команда принимает решения (планирование, вики продукта), а не в папке дизайна.

Участники

За базу отвечает [имя]. Контакты хранятся отдельно; доступ имеют [роли].
Правила повторных приглашений: [пауза, ограничения, причины и исключения для повторных исследований].
Для проверки первого знакомства зовём новых участников; для исследования изменений опыта повторное участие планируем отдельно.
Резерв планируем заранее, сообщаем условия ожидания, отмены и вознаграждения.
Сроки хранения записей [срок] и других данных [срок], доступ [кто], ответственный за удаление [имя]. Условия сообщаем участникам.

Спорные результаты

Если тест и метрика расходятся — это не спор, а отдельная задача на разбор:

Запрос к аналитике: время шага, разбивка по сегментам, обращения в поддержку по теме.
Разбор вместе с продуктом, 30 минут, с показом записи.
Итог фиксируется в журнале решений, даже если решение — «ничего не меняем».

Что мы не тестируем этим методом

Выбор между вариантами по конверсии — A/B-тест.
Распространённость проблемы — аналитика или спланированное количественное исследование.
Нужность функции — интервью и анализ спроса.
Доступность — аудит требований и исследования с людьми с разными ограничениями.

Как поймём, что порядок работает

План на квартал: [число] циклов. В конце проверяем объём работы и причины отклонений.
В журнале видно, как команда использовала результаты при принятии решений.
Есть несколько подготовленных ведущих; проведение тестов не зависит от одного человека.
Команда регулярно пересматривает нагрузку, полезность исследований и выполнение решений по находкам.

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

8Задание

Порядок на квартал, один проведённый цикл и разбор одного спорного результата.

Часть 1 · Порядок

Возьмите шаблон из раздела 7 и перепишите под свою команду (2 ч). Ритм привяжи к своим спринтам, а не к идеальному расписанию.
Согласуйте с командой ритм, нагрузку, роли наблюдателей и порядок работы с находками. Назначьте ответственных за участников и данные.
Заведите базу участников и наполните её хотя бы на две серии вперёд.
Заведите журнал решений там, где команда уже принимает решения. Не в папке дизайна.

Часть 2 · Один цикл

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

Часть 3 · Разбор спорного результата

Выберите результат, который требует разбора. Например, на тесте есть затруднение, а в метрике его не видно. Если такого случая нет, возьмите прошлый или учебный пример и обозначьте это.
Проверьте возможные причины по разделу 4. Выберите подходящие объяснения и запишите, какими данными их можно проверить.
Сформулируйте запрос к аналитике и получите ответ.
Проведите разбор вместе с продуктом, с показом записи.
Зафиксируйте итог в журнале решений и переведите находку в язык риска и стоимости по разделу 5.

Ориентир: 4–6 часов на документ, один рабочий день на цикл, 3–4 часа на разбор расхождения.

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

Что стоит сохранить для портфолио

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

9Чек-листы и ошибки ступени

Практика работает, если

Результаты приходят к моменту принятия решений
Наблюдения доступны команде; по значимым находкам согласованы действия
Журнал решений живёт там, где команда принимает решения
В журнале есть решения с явной опорой на результаты исследований
Проводить тесты умеет несколько подготовленных коллег
На каждой серии был наблюдатель от продукта или разработки
База пополняется постоянно, ротация соблюдается
Метод выбирается под вопрос; при необходимости команда использует другие способы проверки

Разбор расхождения проведён правильно, если

Проверили условия теста и определение метрики
Запрос к аналитике был конкретным: шаг, сегмент, период
Показали запись, а не пересказ
Итог зафиксирован, даже если это «ничего не меняем»
Причина расхождения обоснована данными или явно указано, что ещё неизвестно

Ошибки, характерные для этой ступени

Исследования проводятся, но их результаты не используются. По журналу должно быть понятно, какое решение помог принять каждый цикл.
Результаты трудно найти. Команда не видит находок при планировании. Свяжите их с рабочими задачами и журналом решений.
Опыт повторных участников не учтён. Если проверяете первое знакомство, знание прошлой версии может повлиять на результат.
Разбор начинается с обвинений. Вместо «аналитика врёт» проверьте определение показателя, аудиторию и условия теста.
Результат пяти сессий перенесён на всю аудиторию. Пишите «трое из пяти участников теста», а не «60 % пользователей».
Последствия не описаны. Фразы «неудобно» недостаточно: уточните, какое действие затруднено и к чему это приводит. Денежная оценка нужна не всегда.
Метод выбран до вопроса. Сначала определите, какие данные нужны для решения, затем планируйте проверку.
Практика зависит от одного человека. Подготовьте коллег к ведению сессий, протоколированию и разбору, чтобы работа могла продолжаться без вас.
Наблюдатель подсказывает участнику. Отметьте вмешательство и его влияние. Перед следующей сессией напомните правила участия.
План не учитывает нагрузку. Если команда регулярно пропускает слоты, пересмотрите объём, роли или частоту, сохранив связь с нужными решениями.

10Три ступени темы целиком

Как меняется ответственность от Junior к Senior.

Уровень	Зона ответственности	Признак, что уровень взят
Junior	Провести тест по готовому сценарию, не подсказывая; отличать задание от инструкции; вести протокол с действиями, репликами и остановками; отличать «не смог» от «неудобно»; готовить прототип	В протоколе видно место остановки и что участник пытался сделать
Middle	Сформулировать проверяемое решение и критерий провала; писать понятные задания без подсказок; выбрать формат; разложить находки по серьёзности; принять решения по значимым находкам и проверить правки	Есть «до и после» и строка про каждую правку
Senior — этот урок	Встроить тест в рабочий цикл команды; держать базу участников с ротацией; разбирать расхождения теста и метрики вместе с продуктом; говорить на языке риска и стоимости; знать границу метода и уметь сказать «здесь тест не нужен»	Команда использует результаты тестов при принятии решений и фиксирует основания в общем журнале

Что почитать дальше

Rocket Surgery Made EasyСтив Круг, 2010 · книга на английском · платнаяРитм «одно утро в месяц»: три сессии, наблюдатели из команды выписывают по три главные проблемы, разбор за обедом в тот же день. Памятки для наблюдателей и чек-листы подготовки — бесплатно на сайте автора.
Just Enough ResearchЭрика Холл, издание 2024 · книга на английском · платнаяКак выбрать метод под вопрос и уложить исследование в сроки команды; отдельная глава — про оценочные исследования, в том числе тесты. Издание 2024 года; открыто только начало главы про опросы.
Continuous Discovery HabitsТереза Торрес, 2021 · книга на английском · платнаяКак сделать общение с пользователями еженедельной привычкой: менеджер, дизайнер и разработчик вместе говорят с людьми каждую неделю, а набор участников автоматизирован. Отдельной главы про юзабилити-тесты нет, книга про ритм, интервью и проверку предположений; открыты только оглавление и описание.
Accounting for User Research in AgileNielsen Norman Group, Рейчел Краузе · на английском · бесплатноКак вести исследование в бэклоге, если оно длится несколько спринтов, и как находки становятся задачами. Статья 2021 года зовёт исследовать каждый спринт; урок сначала требует вопроса, под который нужен слот.
Interpreting Contradictory UX Research FindingsNielsen Norman Group, Кейт Моран · на английском · бесплатноКогда цифры и наблюдения расходятся: по каким четырём пунктам проверить оба исследования и почему количественные данные не отменяют качественные автоматически. Разбор случая 2019 года.