CV (резюме)

Написать мне

Ели Пили — мобильное приложение для заказа еды из московских ресторанов
Ели Пили — мобильное приложение для заказа еды из московских ресторанов
«Ели Пили» — мобильное приложение, которое объединяет восемь ресторанов под управлением одной ресторанной группы. Среди них — пять итальянских ресторанов Florentini и два грузинских ресторана: «Чичико» и «Чё Хотэли». У каждого бренда своя концепция, своя аудитория и свой характер, но всех их объединяет общая программа лояльности.
Мы стремились сделать не агрегатор, а платформу «для своих» — с понятной структурой и тёплым, дружелюбным интерфейсом. Важно было также заложить возможность масштабирования, чтобы в будущем легко подключать новые рестораны.

К моменту старта проекта сеть уже использовала коробочное мобильное приложение, разработанное несколько лет назад. Оно плохо интегрировалось с CRM, не позволяло объединить онлайн- и офлайн-клиентов в единую базу, ограничивало развитие программы лояльности и усложняло масштабирование бизнеса. Дополнительно рестораны теряли часть онлайн-выручки из-за неудобного сценария оформления заказов.

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

🥈Проект занял 2 место на Workspace Digital Awards 2026, уступив только Surf — одной из крупнейших студий мобильной разработки в России.

Приложение уже доступно в App Store
Моя роль
На проекте я выступала в роли лид-дизайнера и отвечала за дизайн-направление продукта, качество итогового решения и взаимодействие с клиентом.

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

Разработку дизайн-концепций вела самостоятельно: подготовила несколько вариантов, защищала их перед клиентом и развивала выбранное решение через последующие итерации. Также в моей зоне ответственности были коммуникация с клиентом, защита дизайн-решений и передача макетов в разработку.
Функционал приложения
  • просмотр меню и подробностей по каждому ресторану
  • оформление доставки или самовывоза
  • бронирование стола
  • просмотр новостей и акций
  • хранение истории онлайн и офлайн заказов
  • участие в программе лояльности – накапление бонусов и использование скидочной карты в ресторанах
Исследование и проектирование
Работу начали с разбора существующего приложения поэкранно: прошли все возможные пользовательские пути, зафиксировали где возникает трение, чего не хватает, что работает. Это дало базу — от чего отталкиваться.

Как мы подходили к задаче

Изучили больше десяти конкурентов: от Яндекс. Еды и Delivery Club до приложений отдельных ресторанных сетей. Проходили полный путь — от выбора блюда до получения заказа, смотрели на навигацию, программы лояльности, бронирование, отзывы. Смотрели не за тем, чтобы скопировать, а чтобы понять где у рынка пробелы и какие решения уже проверены конверсией.

На основе этого сформулировали три основных пути пользователя — они стали основой для проектирования сценариев.

  • Новый гость — хочет изучить меню и оформить первый заказ. Авторизация на этом этапе только мешает.
  • Гость, который присматривается — просматривает рестораны, контакты, акции, новости. Ему нужна информация, а не воронка.
  • Лояльный гость — знает что хочет, следит за бонусами и статусом. Для него важна скорость.

Для каждого сценария проработали детальный пользовательский путь, включая пограничные состояния: что происходит, если блюдо на стопе, если адрес вне зоны доставки, если оплата не прошла.
Прототипы
Прототипы собирали итерационно — несколько десятков, каждая механика тестировалась отдельно и в связке. Такой подход позволил согласовать логику всех экранов с клиентом до того, как мы ушли в визуал, и не накапливать расхождений между тем, что проектировали, и тем, что ждал клиент.
Как искали визуальный язык
Это был один из самых нетривиальных этапов. Три ресторана — три разных характера, три разных аудитории. И ещё пять точек Флорентини внутри одного бренда, каждая со своим управляющим и своим видением.
 
Чтобы не угадывать, организовали встречу со всеми управляющими — порядка десяти человек. Показали три пула референсов.

  1. Эмоциональный, кастомный дизайн с ярким визуальным стилем, в котором характер считывается мгновенно (Burger King, Даблби)
  2. Минимализм и изящество с лёгкой кастомизацией (Золотое Яблоко, Эконика)
  3. Агрегаторный дизайн, в котором основное внимание отводится контенту и ничего не отвлекает (Яндекс.Еда, Delivery Club)
Уходить в агрегаторную историю не хотелось, поэтому остановились на синергии первого и второго: нужен характер, но без перегруза.
Три концепции
Я разработала три варианта дизайн-концепции. Два из них — принципиально разные подходы, третий — вариация утверждённого.
Рукописная концепция казалась самой точной метафорически — такие детали есть буквально во всех трёх ресторанах. Но аудитория взрослая, рестораны работают больше десяти лет. Лёгкий визуал не считывался бы как продолжение этих мест.

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

Офлайн-карта — накопительная скидка в самих ресторанах: потратил 100 000 рублей — получаешь скидку 10% на все визиты. Кэшбэк — работает только в приложении: базовые 3% за онлайн-заказы, и по мере роста суммы заказов процент увеличивается. Разные механики, разные мотивации, разные сценарии использования.

Разделили их визуально и архитектурно. На главном экране — карточка, которая выглядит как настоящая физическая карта лояльности. При открытии приложение генерирует динамический код, который пользователь показывает официанту в ресторане.

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

Онлайн-бонусы — отдельный экран с прогресс-баром, историей начислений и разделом «Как выгодно потратить бонусы». На экране с картой лояльности — прогресс до следующего уровня скидки, а как только уровень достигнут, появляется кнопка «Узнать, как повысить уровень» с деталями условий.
Личный кабинет
ЛК собирает всю важную информацию в одном месте. История заказов — онлайн и офлайн вместе, разделены визуально. Внутри каждого заказа — состав, стоимость, детали, контакт ресторана.
 
Для онлайн-заказа доступна функция повтора: автоматически формируется корзина с тем же адресом доставки, что был в прошлый раз. Если какие-то блюда стали недоступны или изменилась цена — пользователь видит это до оформления, может принять изменения или заменить позиции.
 
Оценка заказа — не звёзды, а раздельные критерии: качество блюд, упаковка, доставка или сервис и атмосфера (для офлайн). Плюс поле для комментария и возможность попросить ресторан связаться — это убирает ситуацию, когда отзывы используются как форма обратной связи вместо реального канала поддержки.
 
В блоке данных — возможность добавить детей с именем и датой рождения. В будущем это позволит показывать персональные предложения на дни рождения прямо на главном экране.
Бронирование
Пользователь выбирает ресторан — можно найти его в списке или на карте, сразу построить маршрут. Заполняет дату, время, количество гостей и контактные данные. После отправки получает SMS и пуш с деталями брони и сообщением, что менеджер свяжется в течение 15 минут.
 
Электронного подтверждения на старте нет — брони обрабатываются менеджером вручную. Это честно обозначено в интерфейсе: не «бронь подтверждена», а «запрос отправлен, скоро свяжемся». Автоматизация этого шага — в беклоге.
Сториз и главный экран
Главный экран живой — новости и акции ресторанов подаются в формате сториз. Каждая история привязана к конкретному ресторану, может содержать несколько экранов и вести напрямую на блюдо, категорию или ресторан. Если у пользователя есть активный заказ, он сразу видит его статус вверху экрана.
 
На главном экране также быстрый доступ к карте лояльности и к корзине — если корзин несколько (из разных ресторанов), при нажатии открывается выбор.
Дизайн-система
Параллельно с экранами собирала UI-библиотеку. Приложение с несколькими ресторанами, двумя программами лояльности и разветвлёнными сценариями доставки — это много состояний компонентов, которые нужно держать консистентными: блюдо на стопе, бонусы скоро сгорят, корзина из другого ресторана, заказ с изменившейся ценой.
 
Все edge-кейсы спроектированы и задокументированы — в первую очередь для разработчика, чтобы не изобретать поведение компонентов на ходу. Библиотека охватывает навигацию, карточки товаров, формы, статусные бейджи, модальные окна, экраны лояльности и пустые состояния.
Результат
Приложение запустили в июле 2025. По словам клиента — гости довольны, рестораны тоже. Сразу после запуска пришли с запросом на анимацию сплэш-экрана: хороший знак того, что продукт живёт и развивается.
 
Кейс участвовал в Workspace Digital Awards 2026 — заняли второе место в номинации «Мобильные приложения для HoReCa». В том же рейтинге студия Артемия Лебедева забрала третье место, на первом месте — Surf с пятнадцатилетней специализацией именно на мобильных приложениях.
 
Кейс также получил награду Best UI на площадке DProfile. Количественные метрики — в процессе сбора.
© 2026, Мария Лавренова
© 2026, Мария Лавренова