Как часто должен реагировать цифровой питомец? Практическое руководство по поведению в режиме ожидания и уведомлениям
Для цифрового питомца, рассчитанного на короткие, необязательные визиты, используйте спокойный режим ожидания по умолчанию и позвольте людям самим выбирать, хотят ли они получать напоминания и когда. Настройте обычное поведение питомца так, чтобы ощущалось его присутствие без навязчивого требования внимания; уведомления оставьте для выбранного пользователем окна и предусмотрите четкую возможность их отключения. Универсального правильного интервала посещений не существует: подходящая частота зависит от того, чем питомец занят без присмотра и как часто человек на самом деле хочет взаимодействовать с ним.
Начните с разделения поведения питомца и уведомлений
«Частота отклика» может означать две разные вещи: как часто питомец меняется или реагирует, пока приложение открыто, и как часто приложение обращается к пользователю, когда оно закрыто. Проектируйте их как отдельные элементы управления. Питомец может моргать, оглядываться по сторонам или переходить в новую анимацию ожидания без отправки оповещения. Уведомление, напротив, переносит опыт за пределы приложения и конкурирует за внимание с другими задачами.
Это различие имеет значение, поскольку в инкрементальных (idle) играх опыт формируется за счет коротких сессий и фоновой активности между ними. Опрос 1972 игроков в Neko Atsume выявил несколько аспектов вовлеченности, включая частоту проверок, время, проведенное в игре, и распространение информации в социальных сетях. В исследовании Neko Atsume описывается как игра, прогресс в которой может продолжаться и в закрытом состоянии, а игровые сессии могут длиться всего несколько секунд. Эти выводы касаются одной конкретной игры и выборки пользователей-добровольцев, а не универсального расписания для цифровых питомцев; но они наглядно показывают, почему одна лишь частота проверок — плохой ориентир для дизайна. «Busy doing nothing? What do players do in idle games?»
При принятии дизайнерского решения задайте два вопроса: «Что должен делать питомец, когда с ним никто не взаимодействует?» и «Просил ли пользователь о напоминаниях?» На первый вопрос можно ответить с помощью анимации и смены состояний. На второй вопрос должен отвечать явный выбор пользователя, а не предположение о том, что каждый момент бездействия — это повод вернуть человека обратно.
Сделайте так, чтобы поведение в режиме ожидания несло в себе основной опыт
Питомцу в режиме ожидания требуется понятное состояние по умолчанию. Он может отдыхать, исследовать небольшое пространство, осматривать предмет или время от времени менять позу. Цель состоит в том, чтобы питомец органично смотрелся в своей обстановке и радовал глаз, а не создавал скрытые задачи, за которыми пользователь обязан успевать. Сделайте эти изменения заметными к моменту возвращения человека и не привязывайте их к необходимости поймать короткий момент в реальном времени.
В классической статье о виртуальных персонажах Petz они описываются как автономные сущности, способные использовать предметы в своем окружении и инициировать игру, позволяя пользователям взаимодействовать в удобном для них темпе. Это скорее ранний пример дизайна, чем современный стандарт юзабилити, но он иллюстрирует полезный выбор: персонаж может вести собственную жизнь, поэтому человеку не нужно генерировать каждое действие за него. «Socially Intelligent Virtual Petz»
Практичный цикл ожидания может время от времени менять анимацию питомца, а затем снова затихать. Позвольте пользователю замечать эти моменты при открытии приложения или используйте их в виде необязательных, ненавязчивых сводок. Не ставьте базовое благополучие или дальнейшую жизнь питомца в зависимость от реакции на таймер. Возвращение должно показывать, что изменилось (если изменилось хоть что-то), и предлагать простое последующее действие, например, выбрать игрушку или поприветствовать питомца.
Относитесь к уведомлениям как к расписанию по выбору пользователя
Начните с отключенных уведомлений или предложите четкий выбор во время первоначальной настройки. Предоставьте небольшой набор понятных вариантов, таких как «Без напоминаний», «Раз в день» или «Выбрать время», и сделайте так, чтобы эту настройку можно было легко изменить позже. Функция «тихих часов» или возможность паузы помогут подстроиться под временные изменения в распорядке дня. Конкретный вид меню — это продуктовое решение; его цель — дать человеку реальный контроль, не заставляя его управлять сложным расписанием.
В руководстве Apple для разработчиков указано, что приложениям требуется разрешение перед отправкой уведомлений, и рекомендуется объяснять, какие типы оповещений приложение планирует отправлять, предоставлять возможность подписки или отказа, а также позволять управлять настройками внутри приложения. В нем также разделяются пассивная информация и оповещения, оправдывающие прерывание пользователя, и рекомендуется сопоставлять уровень срочности с реальной важностью сообщения. Обычное обновление статуса питомца, как правило, не является срочным событием. Apple, «Managing notifications»
Избегайте отправки нового оповещения каждый раз, когда у питомца незначительно меняется состояние. Вместо этого объединяйте низкоприоритетные обновления в одно выбранное пользователем окно или показывайте их при следующем открытии приложения. В документации Apple по планированию уведомлений локальные уведомления описываются как способ привлечь внимание человека в указанное время, и рекомендуется использовать их для важной информации, которую пользователь сам хочет получить. Apple, «Scheduling a notification locally from your app»
Проектируйте короткое окно взаимодействия
Напоминание должно вести к действию, которое можно завершить быстро. Например, оповещение может сообщать, что питомец нашел новый предмет для изучения, а открытие приложения покажет этот момент вместе с одним или двумя необязательными действиями. Сохраняйте доступ к основному действию, не требуя долгой сессии, череды экранов или немедленного продолжения.
Это рекомендация по дизайну, выведенная из исследований мобильных уведомлений: полевое исследование, в ходе которого было собрано 10 372 уведомления и 474 ответа на анкеты от 20 человек, показало, что воспринимаемое отвлечение и время отклика варьировались в зависимости от таких факторов, как способ подачи оповещения и задача, которой был занят человек. Небольшое число участников ограничивает широту применения выводов, но подтверждает необходимость осторожного подхода: приложение не может предполагать, что удобный момент для него удобен и для пользователя. Mehrotra et al., «My Phone and Me: Understanding People’s Receptivity to Mobile Notifications»
Удачно спроектированное окно взаимодействия имеет четкое начало и завершение: обратить внимание на питомца, сделать выбор и вернуться к своим делам. Если напоминание отклонено, пусть на этом все и закончится. Избегайте повторного навязывания одного и того же запроса и не вызывайте у пользователя ощущения, что пропущенное окно привело к потере. Если в игре есть необязательные длительные активности, сделайте их доступными после короткого визита, а не превращайте их в обязательную плату за возможность увидеть питомца.
Выберите начальный ритм, затем наблюдайте
Разумной отправной точкой для дизайна на основе напоминаний является максимум одно необязательное напоминание в день, в выбранное пользователем время. Рассматривайте это как консервативную настройку для прототипа, а не как научно подтвержденный оптимум. Для питомца, чья анимация ожидания и экран возвращения уже дают достаточно поводов для открытий, отсутствие напоминаний может быть лучшим выбором по умолчанию. Фактические данные не определяют единого идеального интервала для оповещений цифровых питомцев.
Оценивайте график по поведению, отражающему выбор и пользу для пользователя: как часто люди открывают напоминания, как часто они отключают звук или выключают напоминания вовсе, возвращаются ли они в приложение без оповещений и кажется ли сеанс завершенным без перехода к новому запросу. Сравнивайте эти показатели в зависимости от выбранного режима уведомлений. Высокий показатель открытий сам по себе не говорит о том, что время было выбрано удачно, точно так же как частые проверки сами по себе не свидетельствуют о том, что игрок получает удовольствие от процесса.
Исследование Neko Atsume показало, что частота проверок была лишь одним из нескольких факторов долгосрочной вовлеченности, и его авторы подчеркивают, что эти показатели не заменяют друг друга напрямую. Используйте это как методологический урок: анализируйте повторные визиты наряду с продолжительностью сессий, использованием элементов управления и отзывами об опыте. Не оптимизируйте систему исключительно ради увеличения количества проверок. «Busy doing nothing? What do players do in idle games?»
Простое правило принятия решений
Используйте эту последовательность при выборе частоты отклика:
Если поведение питомца в режиме ожидания создает ощущение живого приложения и нет событий, критичных ко времени, позвольте питомцу ждать без оповещений.
Если напоминание предлагает конкретный, стоящий момент, попросите пользователя дать согласие на получение уведомлений и позвольте ему выбрать или изменить их время.
Делайте визит коротким и самодостаточным; пропущенное напоминание не должно создавать новую проблему, требующую исправления.
Оценивайте отказы от подписки, открытия напоминаний и самостоятельные возвращения в совокупности. Сокращайте или удаляйте напоминания, если они приносят мало пользы.
Руководящий принцип заключается в том, чтобы сделать питомца отзывчивым внутри приложения, а само расписание — чутким к потребностям человека. Поведение в режиме ожидания может обеспечивать непрерывность между визитами; уведомления должны быть редкими, контролируемыми пользователем приглашениями вернуться. В таком случае короткое окно взаимодействия позволяет легко принять, завершить или пропустить каждый визит.