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