Explore
Уложитесь в мой дедлайн?
Oops! Something went wrong while submitting the form.
«Богатство Сибири» — сеть пельменных в Омске. Сеть работает с 2023 года. В меню — фирменные пельмени и вареники ручной лепки, а также другие классические сибирские и русские блюда.
Проект, с которым к нам обратились, начался не с боли, а с возможности: клиент захотел добавить в залы интерактивные столы. Оставить всё как есть было можно, но такой стол давал то, чего не добиться ни меню, ни интерьером.
Ставка была маркетинговой, а не операционной: инфоповод, приток гостей и узнаваемость бренда — стол задумывался как точка притяжения.
Мы увидели за задачей и больший масштаб: превращение работающей сети в место, о котором рассказывает город, — почти в достопримечательность.
Для кого делается стол, было ясно уже на старте: туристы, которым после обеда нужно чем заняться в городе, и семьи с детьми. Отсюда и требование к интерфейсу — не строгий ресторанный, а семейный, дружелюбный по тону.
По оценке клиента, такого формата в городе не было, а в России интерактивные столы в ресторанах встречаются крайне редко. Под запуск готовили и продвижение: открытие столов собирались освещать блогеры и городские афиши — продвигали не меню и не скидку, а сам факт их появления.
Клиент пришёл подготовленным:
Формулировку задачи за весь проект не пришлось переписывать: сложность лежала не в постановке, а в её исполнении.
Гость садится за сенсорную столешницу и выбирает число гостей — стол рассчитан максимум на четверых.
В своей секции гость смотрит меню и собирает заказ; счёт формируется отдельно на каждую секцию.
Пока кухня готовит, гость занимает себя контентом стола: играет, листает карту города, знакомится с брендом.
Гости уходят — стол по таймауту неактивности сам сбрасывает сессию и готов к следующей компании.
Если ваша задача похожа, посмотрите наш кейс для ресторанного бизнеса.
Стол должен был давать вау-эффект — гость с ним взаимодействует. Но придумывать интерфейс с нуля было нельзя: у клиента уже существовали брендбук и маскот, и стол обязан был выглядеть продолжением бренда. При этом бизнес-логика была понятна, а вот внешний вид продукта мог оказаться очень разным — поэтому работу начали не с макетов экранов, а с концепций.
Мы проработали три концепции:
Все три концепции строились на одном маскоте и одной идее — «богатство Сибири», которое медведь показывает гостю. Различалась роль, которую получал гость: путешественник, которого ведут по краю; случайный свидетель за окном чужой избушки; или желанный гость, которого ждут за столом.
Выбрали «Семейный обед» и определились быстро: это единственная концепция, где гость не наблюдает за медведем со стороны, а оказывается принят в дом. А метафора накрытого стола совпадает с физикой: человек и правда сидит за столом в гостях, и интерфейс ведёт себя как этот стол — салфетка, тарелка, меню.
Объём графики при этом был большим — весь интерфейс, иллюстрации и игровая графика, а требование «должно быть красиво» никуда не девалось. Рисовать всё руками — дорого и долго, поэтому основную графику мы генерировали с помощью ИИ. Не с чистого листа, а от готового персонажа и материалов клиента. Так удалось существенно сэкономить на графическом дизайнере, сохранив узнаваемость бренда.
Больше о том, как мы выстраиваем дизайн продукта, — в разборе нашего дизайн-процесса.
Третья развилка — карта города для туристов. Очевидный путь — встроить Яндекс.Карты или 2GIS: расставить метки достопримечательностей и по тапу открывать карточку с фотографиями. Мы от этого отказались: чужая картография со своими цветами, типографикой и фотографиями выпадала бы из продукта, а стол продаётся впечатлением — любой экран, похожий на обычный сервис, ломает его.
Мы сами отобрали показательные места города и собрали карту в стиле приложения, с уникальной иконкой для каждого места. Ручной эта работа была лишь отчасти: ИИ карты не понимает — не отличает, что можно стилизовать, а что искажать нельзя, поэтому работали гибридом: упрощали скриншот реальной карты до чертежа, стилизовали генерацией, а пропорции, границы и дороги восстанавливали вручную.
Изначально рисовали одну карту города с зумом, но задача оказалась непомерной: главные достопримечательности стоят плотно в центре, парки и набережная — далеко, а огромный векторный файл тяжёл и для отрисовки, и для интерфейса.
Карту разложили на пять маршрутов — от исторической прогулки по центру до «Птичьей гавани»; у каждого — анимированная линия от старта до финиша и QR-код: маршрут со всеми точками открывается в Яндекс Картах уже на телефоне гостя. Эту идею мы предложили клиенту сами.
В карте нет поиска и автообновления — только отобранные и отрисованные объекты, зато пользоваться ей интересно как ещё одной частью развлекательного контента.
.svg)
От внешнего вида — к физике. Каждый стол — это сенсорный экран, врезанный в столешницу, и компьютер с Windows под ним: приложение для стола — обычная программа на Electron, и живёт она на этом компьютере. Закупать такие комплекты нужно было заранее, до того как приложение будет готово. И ошибка здесь была бы необратимой: недобор по мощности означал бы купленные и уже смонтированные в столы машины, на которых продукт тормозит. А приложение заведомо не было лёгким — анимации, собственные игры плюс внешний игровой каталог.
Пути было два: оценить требования «по документации» и заказать с запасом или проверить всё на практике до закупки. Мы пошли вторым путём:
Минимально допустимая планка зафиксировалась быстро, и клиент заказывал компьютеры не наугад, а по проверенной границе.
Но у главной механики стола оставалась вторая половина — сам сенсор. И его у клиента ещё не было на руках.
Ключевая механика продукта — четыре гостя одновременно работают каждый в своей секции. На обычном мониторе её не проверить, а целевых сенсорных экранов у клиента на момент разработки не было вовсе — ни установленных столов, ни даже выставочного образца. Формально можно было разрабатывать на мониторе и сдать работу: экраны были зоной клиента.
Мы не стали ждать монтажа. Нашли на Avito сенсорный экран, близкий по характеристикам к тому, который клиент собирался заказывать, и с самых ранних этапов тестировали приложение на настоящем сенсоре. Устройство формально не входило в скоуп — это наши деньги и время, потраченные на то, чтобы не откладывать проверку главной механики. И проверка себя оправдала.
Первая реализация касаний работала по логике браузера: пока один гость листал меню, трое других фактически не могли ничего нажать — система считала их зоны «спящими». А ведь физически экран один, и вести себя он должен как несколько независимых устройств. Мы переработали обработку касаний так, что у каждой секции появился собственный поток событий: активность в одной зоне больше не усыпляет соседние.
Так дефект параллельных касаний был найден и починен до монтажа, а не после установки столов в работающем зале.
Меню — не единственное, что происходит на столе. Яндекс Игры работают на столе через веб-вью; к ним мы добавили шесть собственных игр:
Во всех играх гость может играть против приложения, либо с соседом, но «на одной салфетке», а не против соседа напротив. Полноценный мультиплеер решили пока что вынести за рамки первой версии, чтобы не раздувать бюджет. Рядом на экране — рисованная карта города и блок «О компании».
Собственные игры — не значит написанные с нуля: под каждую мы подобрали готовую библиотеку. Какие-то достаточно было переодеть в стиль продукта, какие-то дописывали под свои механики.
Самая объёмная из собственных игр — тамагочи «Медвежонок». Это не одна игра, а набор встроенных мини-игр: медвежонка можно покормить, приготовить с ним еду, пойти гулять, искупать и уложить спать.
Первый медвежонок вышел классическим пиксельным тамагочи — и не подошёл: клиенту от жанра нужна была только механика заботы, а персонаж должен был жить в том же мире, что и весь продукт. Собрали несколько новых мини-концептов, клиент выбрал «игрушечного» — меньше и милее взрослого медведя с главного экрана.
Вышло так мило, что игра умиляет даже тех, кто её делал, — но у этой милоты огромная цена: анимации нужно очень много.
Технически всё собрано на спрайт-шитах: каждое движение персонажа — последовательность кадров, которая проигрывается покадрово. Жёсткий потолок задавал движок тамагочи — готовая библиотека, рассчитанная на 8-битные игры: на одно движение персонажа в нём предусмотрено от 3 до 24 кадров.
Другие движки под задачу не подходили, поэтому работали внутри потолка кадров. Кадры не рисовали вручную: под каждое движение генерировали отдельное видео и из него нарезали на кадры — семисекундная пробежка разворачивается примерно в 32 кадра.
Чем больше кадров, тем плавнее движение, но каждый кадр нагружает процессор, и перебирать было нельзя. Поэтому каждый кадр вырезали так, чтобы не появлялось рывков, количество подбирали вручную, а последовательности доводили до зацикливания без видимого шва.
Заметнее всего это было в мини-играх «Прогулка» и «Купание» — там много состояний и частиц, которые должны выглядеть органично прямо в момент игры. «Прогулка» устроена как динозаврик в Chrome при отключённом интернете.
Падение в овраг не может длиться пять секунд: движение обязано быть быстрым, а на быстрое движение набирается считанное число кадров — и все они должны быть выверены так, чтобы мишка падал, а не «улетал». Один только прыжок генерировали 30–40 раз.
Но даже идеально плавный контент не гарантировал главного: удобен ли сам стол как физический предмет.
Навигацию приложения мы продумали на этапе дизайна и утвердили с клиентом: на макете, в масштабе монитора, она выглядела логично. Когда у клиента появились целевые экраны и компьютеры, команда поехала тестировать на место: группу людей, которые ни разу не видели приложение, собрали уже там и снимали обратную связь на настоящем столе.
Выяснилось: навигация неудобна, и причина физическая, а не интерфейсная — экран размером с обеденный стол. До кнопок вроде «закрыть» и «заблокировать» приходилось привставать со стула. Мы быстро починили это, переработав навигацию.
Последний большой вопрос проекта — как заказ со стола попадает в кассу. SalesKit — облачная платформа для ресторанов: онлайн-меню, приём заказов, оплата. Клиент уже использует её на сайте — там оформляют доставку и самовывоз. Поэтому на старте вариант был один: переиспользовать готовое решение и в столе. Но при переносе на стол вылезли чужие для ресторана шаги: гость в зале попадал в сценарий онлайн-заказа — регистрация на сайте, выбор между доставкой и самовывозом.
Убрать эти шаги можно было только доработкой на стороне SalesKit — то есть зависимостью от чужой команды и чужих сроков. Дальше мы перебрали три варианта.
Пока мы готовили релиз, SalesKit стал недоступен из-за проблем на стороне провайдера — и для запуска пришлось оперативно искать замену. Ею стало QR-меню Carbis: заказ со стола уходит в кассу без лишних шагов, с ним и выходим в релиз. Вариант с собственным меню и прямой отправкой в R-Keeper остаётся открытым как следующий шаг.
Ключевое решение здесь — не блокировать запуск идеальным вариантом: всё, что мы контролируем сами, — дизайн, игры, карту, сценарий стола — мы сделали, а скорость решения зависит от кассовой экосистемы клиента.
А если после прочтения кейса захотелось отведать пельменей, велком: Макс, Сайт.
