Как провести плейтест: сценарий, вопросы, сигнал и шум

Плейтест-сессия длится сорок пять минут, и все они расписаны: двухминутный бриф, полчаса наблюдения за одним тестером, который играет и думает вслух, и десять минут вопросов о только что произошедшем. Дисциплина ведущего по большей части запрещающая. Не объясняйте игру. Не защищайте свои решения. Не помогайте, когда тестер застрял в первый раз. Вы записываете, что игрок делает; рассказы о том, что он сделал бы, это другая валюта, и стоит она куда дешевле.

С поиском тестеров мы разобрались отдельно: см. как найти плейтестеров для своей игры. Чаще проваливается следующий шаг. В еженедельных обсуждениях, которые мы читаем, раз за разом одна и та же картина: разработчик собрал пятерых незнакомцев, сборку и созвон, а потом весь созвон рассказывает им о своих дизайн-решениях, и незнакомцы вежливо кивают. Сессия работает как измерительный прибор, и у неё есть инструкция: подготовка, сценарий, вопросы, после которых появляются исправления, и фильтры, отделяющие находку от мнения. Оговорка до начала: этот блог принадлежит Egmatic, no-code-редактору двухмерных игр в стадии пре-альфы; при чём здесь плейтестинг, рассказано ближе к концу.

Короткий ответ#

Что такое сессия и с чем её путают#

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

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

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

До сессии: одна страница подготовки#

Всё, что ниже, умещается на одной странице, и существовать она должна до прихода первого тестера.

1. Две-три цели, сформулированные как вопросы. «Дойдёт ли новый игрок до первого босса без подсказок?» — цель, и «Где игроки впервые спотыкаются в меню крафта?» тоже. «Собрать фидбэк» не цель. Если в сборке нет ничего настолько неопределённого, чтобы это можно было оформить вопросом, сессии нечего собирать.
2. Замороженная сборка. Заморозьте её накануне вечером и проверьте заморозку на своей машине. Сессия, умершая от вылета на третьей минуте, уже не оживает: вместе с данными вы теряете терпение тестера.
3. Задачи, записанные заранее. Одна стартовая («запустите игру и играйте, как дома») плюс одна-две конкретные, привязанные к целям. Задачи удерживают сессию в движении, когда тестер ищет у вас направления.
4. Лист заметок. Одна строка на событие: примерный таймкод, что тестер пытался сделать, что сделал, что сказал. Пустые колонки готовьте заранее, потому что писать придётся во время сессии, а не после.
5. Вознаграждение и канал. Заранее решите, что получает тестер: ключ, строчку в титрах или деньги. И куда уйдут уточняющие вопросы, если они появятся.

Сборке нужен путь до тестера. Веб-сборка за одной ссылкой требует от незнакомца меньше всего действий, и как её подготовить, разобрано в статье о размещении веб-демо игры; дисциплина самой сессии не зависит от того, чем сборка добралась.

Сценарий: поминутно#

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

Ценность сценария не в ритуале. Тестер, услышавший на первой минуте «здесь нельзя сделать что-то неправильно», расслабляется, а расслабленный тестер честно пользуется игрой не так, как вы задумали. Ведущий с распечатанным сценарием не начинает импровизировать объяснения на четвёртой минуте, а именно так сессии гибнут чаще всего.

Во время сессии: молчание как метод#

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

Чтобы монолог не прерывался, хватает трёх нейтральных вопросов, и только их:

• «Что вы сейчас пытаетесь сделать?»
• «Расскажите, о чём вы сейчас думаете»
• «Чего вы ожидали только что?»

Каждый такой вопрос возвращает внимание к игре, не подкладывая свою интерпретацию. Опасен другой, наводящий: «А кнопку вы заметили?» Он сам содержит ответ и превращает наблюдение в подсказку. К любительскому ведению метод в целом снисходителен; непростителен один ход: вложить слова в рот тестеру. Всё, что произойдёт после этого момента, уже не в счёт.

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

Вопросы, которые себя оправдывают#

Вопросы о прошедшем получасе дают исправления. Вопросы об игре вообще дают мнения. Таблица держит их порознь.

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

Сигнал и шум: три фильтра#

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

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

Второй: повторяемость сильнее громкости. Страстная критика одного тестера остаётся гипотезой; трое, упирающиеся в одну стену, — уже находка. Арифметику за вас сделали исследования малых выборок: один тестер находит около 31% проблем юзабилити продукта, пятеро примерно 85%, и рекомендация там не «один большой заход», а три раунда по пять с исправлениями между ними. Следствие для соло-разработчика простое: не действуйте по мнениям одной сессии. Запишите их, исправьте первые три, а следующую сессию потратьте на новых людей; здесь же окупается и совет о небольших подобранных группах из материала о наборе плейтестеров. Тестеры, вернувшиеся на второй раунд, это сложный процент всей практики, и как удержать маленькую комнату, которая возвращается, разобрано в статье о сообществе вокруг игры до релиза.

Третий: запрос новой функции это симптом. «Надо добавить кнопку рывка» не вклад в дизайн; так игрок решает испытанную им проблему трения теми средствами, что у него есть. Ищите трение, лежащее под запросом: спросите, что тестер пытался сделать в момент, когда возникло пожелание, а решение принимайте сами. Исполнение просьб в исходной формулировке назначает дизайнером самого громкого тестера и молча вычёркивает четверых, которые ударились в ту же стену без слов.

Удалённые и записываемые сессии#

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

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

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

Частые ошибки#

• Объяснение игры до начала. Каждое предложение вводной стирает кусок проверочных данных туториала. Бриф настраивает ожидания, он не учит.
• Помощь при первом застревании. Момент, когда тестер застрял, и есть продукт. Выдержите эти десять секунд.
• Вопрос «весело ли?». Веселье выводят из наблюдений: продолжил ли тестер играть, вернулся ли после паузы, спросил ли, когда можно сыграть ещё. Прямой вопрос схлопывает его в вежливость.
• Незамороженная сборка. Утренний фикс становится дневным вылетом, и сессия сгорает на этом.
• Одна сессия и всё. Редизайн привозит собственные новые проблемы; второй раунд существует, чтобы их поймать.
• Заметки только о жалобах. То, что тестер пропустил без слов, это данные об интересе; записывайте и это.

Как здесь Egmatic#

Работа вокруг сессии по большей части относится к публикации: заморозить сборку, привести её в один клик от незнакомца, собрать произошедшее и выпустить исправление следующей сборкой, доступной тестерам. Эта дорога от сцены до релизного билда и есть слой, вокруг которого построен Egmatic: no-code-редактор и движок двухмерных игр, чей корабельный слой доводит игру до игроков, а не обрывается на холсте. ИИ внутри работает как усилитель ремесла под вашим руководством: после раунда сессий вы решаете, что меняется, он исполняет, и каждый файл остаётся вашим; это важно, когда исправление должно быть у тестеров на той же неделе.

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

Заключение#

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

Источники#

1. Nielsen Norman Group — Thinking Aloud: The #1 Usability Tool, Якоб Нильсен, 15 января 2012: «thinking aloud may be the single most valuable usability engineering method» (из книги Usability Engineering, 1993); три шага метода: набрать представителей аудитории, дать им типичные задачи, молчать и дать говорить участникам; нейтральные вопросы ведущего для поддержки монолога; устойчивость результатов к несовершённому ведению, кроме случая, когда ведущий вкладывает слова в рот участнику.
2. Nielsen Norman Group — First Rule of Usability? Don't Listen to Users, Якоб Нильсен, 4 августа 2001: смотрите, что люди делают на самом деле; не верьте их рассказам о том, что они делают; и особенно не верьте предсказаниям будущего поведения; предпочтение, высказанное без реального использования, отражает лишь поверхностные черты.
3. Nielsen Norman Group — Why You Only Need to Test with 5 Users, Якоб Нильсен: около 31% проблем, находимых одним тестером; примерно 85% при пяти тестерах; рекомендация трёх раундов по пять вместо одного исследования на пятнадцать.
4. Nielsen Norman Group — Usability (User) Testing 101, Кейт Моран, 1 декабря 2019, последний обзор 15 июля 2026: анатомия сессии из ведущего, задач и участника; ведущий наблюдает поведение, слушает фидбэк и задаёт уточняющие вопросы.
5. Games User Research — How To Run A Games User Research Playtest, Стив Бромли, обновлено 5 июня 2024: сквозной процесс плейтеста от целей через незашумлённый сбор данных до отчёта; команды проводят плейтесты слишком поздно и получают исследования с низкой отдачей.
6. PlaytestCloud — Pricing: бесплатный триал, одна сессия с двумя игроками, запись каждого до 60 минут.
7. Чтения сообществ, которые проводит наша команда, сентябрь 2026: еженедельные плейтест-треды r/gamedev и r/playmygame, включая «What did your first real playtest reveal»; повторяющиеся рассказы о сессиях, потраченных на объяснение дизайн-решений вместо наблюдения за игрой.