Фраза «давайте сделаем квест по территории» ещё не объясняет, зачем он нужен гостю. Можно написать десятки загадок и обнаружить, что люди хотели короткую прогулку, а обязательное прохождение им мешает.
Я столкнулся с этим вопросом, когда показал городскую платформу большим площадкам. Запрос на знакомство с территорией оказался шире игры. Поэтому на первом разговоре я рассматриваю и сценарный квест, и навигатор с самостоятельным выбором мест.
Выбрать одно действие, которое стоит проверить
Показать гостю всё сразу — слишком расплывчатая цель. Для пилота лучше выбрать понятное действие: дойти до незаметной зоны, познакомиться с несколькими местами или открыть для себя отдельную услугу.
Дальше нужен мотив самого человека. Например, у него есть полчаса, он хочет красивое место для прогулки или занятие вместе с ребёнком. Это примеры сценариев проектирования, а не обещание одинакового поведения всех гостей.
Сначала разбираем существующий путь: откуда человек начинает, что уже знает, где принимает решение и почему разворачивается. После этого выбираем цифровую механику.
Квест или свободный навигатор
| Условие | Что проверять первым |
|---|---|
| Гости приходят именно за игрой и готовы принять её правила | Последовательный квест с понятной длительностью и финалом |
| У гостей разное свободное время и интересы | Каталог впечатлений со свободным выбором следующего места |
| Нужно короткое знакомство с несколькими объектами | Небольшой самостоятельный маршрут без обязательства пройти всю территорию |
Форматы могут сочетаться. На одной территории можно предложить игру тем, кто за ней пришёл, и спокойный выбор мест остальным. Но в первом пилоте лучше проверить одну основную задачу и понять, почему люди пользуются решением.
История изменения самого продукта описана в статье «Как городской квест превратился в навигатор впечатлений».
Подготовить содержание и реальные условия
Нужны точные объекты и входы, фотографии, описания, время посещения и ограничения. Метка посередине здания не помогает человеку понять, с какой стороны подойти. Красивое место может быть недоступно в плохую погоду или в определённое время.
Со стороны площадки нужен человек, который знает территорию и сможет обновлять сведения. Редактор полезен только тогда, когда за содержание кто-то отвечает.
Сценарий проверяется на месте. В браузере можно отладить интерфейс, но невозможно доказать, что дорожка удобна, ориентир заметен, а связь работает на всём пути.
Запустить небольшой пилот и разобрать поведение
Для пилота выбираем ограниченный набор мест и понятную аудиторию. Человек открывает ссылку или QR-код, получает первый полезный результат и решает, продолжать ли. Длинная регистрация до знакомства с продуктом затрудняет эту проверку.
В городской игре мы уже смотрим на прохождения, ошибки и подсказки. Для территории заранее определяем свои события: открытие, выбор места, следующее действие и подтверждение посещения. Продажи можно оценивать лишь при наличии соответствующего подтверждения.
После пилота решаем, что менять: содержание, вход в интерфейс, длину пути или сам формат. Рост числа кликов без полезного действия гостя не является достаточным результатом.
С чем прийти на первый разговор
- Схема территории и несколько мест, которые гости плохо замечают.
- Кто приезжает, сколько времени проводит и как передвигается.
- Какое действие гостя вы хотите проверить.
- Фотографии, правила посещения и доступный контент.
- Ограничения связи, сезонности и работы персонала.
- Бюджет пилота и критерий, по которому решим, стоит ли продолжать.
Стоимость зависит от объёма территории, сценария, новых механик и интеграций. Разработка навигатора с актуальными статусами отличается от переноса готового маршрута в существующий редактор. Эти задачи нужно оценивать раздельно.
Начать можно с демонстрации городского квеста, затем сверить состав услуги со своей задачей.