Дизайн чек-листа: 3–7 шагов, которые находят настоящие UX-баги

Сценарий: 40 отчётов, из которых полезны четыре

Артём — разработчик-одиночка, автор приложения для чтения книг с офлайн-синхронизацией. Он запустил первую кампанию на 40 тестов и написал чек-лист так, как ему казалось логично:

1. Проверьте приложение.
2. Оцените удобство интерфейса.
3. Напишите, что можно улучшить.

Через три дня Артём получил 40 отчётов. Вот типичные:

• «Всё работает нормально, приложение удобное. 4/5».
• «Дизайн современный, но можно добавить тёмную тему».
• «Не нашёл ошибок. Хорошее приложение».
• «Мне не хватило кнопки “поделиться”».

Полезных — четыре. Остальные формально соответствуют заданию: человека попросили «оценить удобство», он оценил. Претензий не предъявить, отклонять не за что. Артём заплатил почти полностью и узнал почти ничего.

Проблема не в тестировщиках. Проблема в чек-листе. Расплывчатый чек-лист получает расплывчатые ответы — это закономерность, а не случайность.

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

Почему чек-лист — это не список функций

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

Разница принципиальная.

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

Правило: если на шаг можно ответить одним словом, шаг сформулирован неправильно.

Анатомия одного шага

Хороший шаг чек-листа состоит из четырёх частей, даже если они уложены в одно предложение.

1. Действие. Конкретное, наблюдаемое, с точкой входа и точкой выхода. «Дойдите от главного экрана до оплаты подписки».

2. Условие или контекст. При каких обстоятельствах. «На мобильном интернете», «после перезапуска приложения», «в тёмной теме».

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

4. Доказательство. Скриншот, запись экрана, номер версии, модель устройства. Без этого отчёт нельзя проверить, а значит нельзя честно принять или отклонить.

Соберём вместе:

> «На мобильном интернете (не Wi-Fi) скачайте любую книгу в офлайн. Зафиксируйте, сколько секунд заняла загрузка и появлялся ли индикатор прогресса. Приложите скриншот экрана во время загрузки. Укажите модель устройства.»

Такой шаг невозможно закрыть фразой «всё хорошо».

Почему 3–7 шагов, а не 15

Соблазн понятен: раз платим за отчёт, попросим проверить побольше. На практике это снижает качество каждого пункта.

Что происходит при 15 шагах:

• Тестировщик распределяет усилие равномерно и делает всё поверхностно.
• Ответы становятся короче — физически тяжело писать подробно 15 раз.
• Появляется «усталость внимания»: к десятому пункту человек перестаёт замечать мелкие странности, а именно они и есть UX-проблемы.
• Растёт доля шаблонных ответов, потому что это единственный способ уложиться в разумное время.
• Модерация превращается в кошмар: нужно сверить 15 пунктов × 50 отчётов = 750 проверок.

Что происходит при 3–7 шагах:

• Каждый шаг получает осознанное внимание.
• Ответы длиннее и содержательнее.
• Легко проверять: пропущенный шаг виден сразу.
• Можно требовать доказательство по каждому пункту, не делая задание неподъёмным.

Логика простая: общий объём отчёта ограничен усилием, которое человек готов вложить за оговорённую оплату. Вы не увеличиваете объём усилия количеством пунктов — вы только дробите его на более мелкие и менее полезные части.

Если сценариев много — делайте несколько волн кампаний, а не один длинный чек-лист. Три кампании по 5 шагов дадут кардинально больше, чем одна по 15.

Сравнение двух подходов к заданию

Ключевое отличие в предпоследней строке. Когда тестировщик не понимает, чего от него хотят, он делает самое безопасное — пишет нейтральный positive-отчёт. Это рациональное поведение при неясном задании.

Восемь антипаттернов формулировок

1. «Оцените…» Оценка — это число или прилагательное. Вам нужен факт. Замените на «опишите» или «зафиксируйте».

2. «Проверьте, работает ли…» Подразумевает ответ «да/нет». Замените на «выполните X и опишите результат».

3. «Найдите баги». Перекладывает на тестировщика вашу работу по определению области поиска. Задайте конкретный сценарий — баги найдутся внутри него.

4. «Напишите ваше мнение о приложении». Мнение получите, пользу — нет. Если нужен субъективный отклик, спрашивайте узко: «Что, по вашему мнению, приложение обещает на первом экране? Сбылось ли это обещание к концу регистрации?»

5. Подсказка ответа в вопросе. «Удобно ли работает новая кнопка избранного?» — вы уже сказали, что она удобная. Нейтрально: «Добавьте книгу в избранное. Опишите путь, которым вы это сделали».

6. Шаг без точки завершения. «Полистайте приложение» — непонятно, когда шаг выполнен. Всегда задавайте финальное состояние: «до экрана X», «пока не увидите Y».

7. Требование, которое невозможно выполнить. «Протестируйте на iPhone 15 Pro и Android одновременно» — если вам нужны разные устройства, делайте отдельные кампании или указывайте требование к устройству в условиях.

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

Переписываем чек-лист Артёма

Вернёмся к сценарию. Артёму нужно понять, почему люди скачивают приложение, но не начинают читать. Вот новый чек-лист — пять шагов.

Шаг 1. Первое впечатление (без действий).

Откройте приложение. Не нажимая ничего, 10 секунд смотрите на экран. Затем напишите своими словами: что это за приложение и что оно вам предлагает сделать прямо сейчас? Приложите скриншот того, что видите.

Шаг 2. Дойдите до первой книги.

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

Шаг 3. Настройка под себя.

Не выходя из книги, измените размер шрифта. Опишите, как вы искали эту настройку и сколько времени потратили. Приложите скриншот экрана настроек.

Шаг 4. Офлайн-сценарий.

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

Шаг 5. Возврат.

Полностью закройте приложение и откройте снова. Вы оказались на том же месте в книге или нет? Опишите первый экран после повторного запуска.

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

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

Что Артём получил после переписывания

Из следующих 40 отчётов:

• 22 человека на шаге 1 описали приложение как «библиотека книг», и ни один не упомянул офлайн-синхронизацию — главную ценность продукта. Это сказало Артёму, что первый экран не передаёт позиционирование.
• Среднее число нажатий до текста книги — 6, при задуманных 3. Люди заходили через каталог, потом в категорию, потом обратно, потому что кнопка «Читать» на карточке была ниже сгиба экрана.
• 14 человек искали настройку шрифта дольше 30 секунд: она была спрятана за долгим нажатием на текст, о чём никто не догадался.
• 9 человек на шаге 4 сообщили, что книга открылась, но перелистывание за 7-ю страницу выдало пустой экран — баг предзагрузки, который не воспроизводился на быстром интернете команды.
• 31 человек на шаге 5 попал на главный экран, а не в книгу. Артём считал, что сохранение позиции работает; оказалось, оно работало только при «мягком» закрытии.

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

Критерии приёмки: пишите их заранее и открыто

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

Формулируйте так:

> Отчёт принимается, если: выполнены все 5 шагов; к шагам 1, 3, 4 приложены скриншоты; указаны модель устройства и версия ОС; ответы описывают ваши действия, а не общее мнение о приложении.

>

> Отчёт отклоняется, если: пропущен шаг; нет обязательного скриншота; ответы вида «всё хорошо / всё работает» без описания действий; скриншот не соответствует описанному шагу.

Обратите внимание: критерии проверяемые. «Отчёт недостаточно подробный» — не критерий, это вкус. «Нет скриншота на шаге 3» — критерий.

Как проектировать серию чек-листов

Один чек-лист — один вопрос к продукту. Серия чек-листов — карта продукта.

Волна 1: вход. Первое впечатление, регистрация, первое ключевое действие. Здесь живёт большинство потерь.

Волна 2: ядро. Основной повторяющийся сценарий — то, ради чего человек вернётся. Для читалки это чтение и синхронизация, для трекера тренировок — создание и выполнение тренировки.

Волна 3: деньги. Экран подписки, оплата, восстановление покупки, отмена. Самая дорогая область для ошибок.

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

Волна 5: повторный прогон после правок. Тот же чек-лист, что в волне 1, чтобы увидеть динамику. Это единственный способ честно проверить, что правка помогла.

Пятая волна — то, что чаще всего забывают. Без неё вы не знаете, стало лучше или просто изменилось.

Как формулировать шаги для качественной, а не количественной обратной связи

Некоторые вопросы нельзя свести к «посчитайте нажатия». Например, вы хотите понять, доверяют ли люди приложению с доступом к их данным. Здесь работают формулировки-проекции:

• «Перед тем как нажать “Разрешить уведомления”, напишите, чего вы ожидаете получать. Затем разрешите и опишите, совпало ли».
• «Опишите одним предложением, кому бы вы порекомендовали это приложение и почему именно ему».
• «Если бы вы объясняли другу, чем это приложение отличается от встроенной читалки, что бы вы сказали?»
• «На каком шаге вы впервые почувствовали, что приложение делает то, что вам нужно? Если такого момента не было — напишите об этом прямо».

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

FAQ

Сколько времени должен занимать чек-лист из 5 шагов?

Ориентир — 10–20 минут внимательной работы, включая написание отчёта и скриншоты. Если по вашей оценке выходит больше 30 минут, сокращайте шаги или повышайте оплату — иначе получите поверхностные ответы.

Нужно ли давать тестировщику тестовый аккаунт?

Если регистрация не входит в проверяемый сценарий — да, обязательно. Если входит — наоборот, пусть проходит сам, это и есть предмет исследования. Просто не смешивайте оба варианта в одной волне.

Можно ли просить записать видео экрана?

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

Что делать, если все 40 отчётов сообщают одно и то же?

Это хороший результат: вы нашли доминирующую проблему и подтвердили её частотность. Исправляйте и запускайте повторную волну с тем же чек-листом.

Как понять, что чек-лист плохой, до запуска кампании?

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

Можно ли включать в чек-лист вопросы о конкурентах?

Можно, если они сформулированы как опыт, а не как оценка: «Если вы пользовались похожими приложениями, что здесь показалось непривычным?» Просить сравнивать «что лучше» бессмысленно — получите вкусовщину.

Итоги

• Расплывчатый чек-лист гарантированно даёт расплывчатые отчёты. Качество входа определяет качество выхода.
• Каждый шаг = действие + условие + что зафиксировать + доказательство.
• Если на шаг можно ответить одним словом, он сформулирован неправильно.
• Оптимум 3–7 шагов: больше шагов не увеличивают усилие тестировщика, а дробят его.
• Критерии приёмки должны быть проверяемыми и опубликованными заранее.
• Серия волн по областям продукта работает лучше одного длинного чек-листа, а повторная волна после правок — единственный честный способ проверить улучшение.
• Просьбы поставить оценку или отзыв в сторе недопустимы: это нарушение правил платформ и порча собственных данных.

Заключение

Артём потратил на переписывание чек-листа полтора часа. Эффект оказался больше, чем от удвоения бюджета кампании: доля отчётов с конкретной находкой выросла с 10 % до 78 %.

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