CV (резюме)
Написать мне
В периоды высокой нагрузки именно операционные процессы становились узким местом бизнеса.
У компании уже был сайт, но фактически он не участвовал в работе с клиентами. Решение на базе конструктора не учитывало реальные бизнес-процессы, плохо подходило для автоматизации и ограничивало дальнейшее развитие продукта.
Задача выходила далеко за рамки редизайна. Нужно было спроектировать новую цифровую платформу, которая сократила бы объём ручной работы, объединила ключевые процессы в одном интерфейсе и создала фундамент для дальнейшего роста компании. Дополнительным ограничением стало то, что архитектуру продукта нужно было сразу закладывать с учётом будущего выхода компании в B2C-сегмент.
К моменту старта проекта мы уже несколько лет сотрудничали с Архитектор Групп и ранее разработали для компании логотип, логобук, корпоративную презентацию и фирменное оформление транспорта. Базовая визуальная система была сформирована заранее, поэтому на этом проекте основной фокус сместился на продуктовую логику, пользовательские сценарии и проектирование внутренних процессов.
На старте вместе со стейкхолдерами анализировала существующие процессы, выявляла точки потерь времени и определяла целевую модель сервиса. На основе исследований проектировала пользовательские сценарии, информационную архитектуру и ключевые продуктовые механики. Также разработала дизайн-концепцию платформы, согласовывала решения с бизнесом и сопровождала проект на этапе реализации.
Бизнес-задачи и ограничения
В результате сформировали три ключевых направления работы:
- снизить нагрузку на менеджеров за счёт автоматизации заказов, статусов и документооборота;
- создать единое рабочее пространство для клиентов, где можно управлять заказами, документами и сотрудниками компании;
- заложить масштабируемую архитектуру, которую можно развивать сначала внутри B2B-направления, а затем адаптировать для выхода в B2C.
Сроки и бюджет проекта были фиксированными. Дополнительным ограничением стали интеграции с 1С, которые напрямую влияли на состав MVP и определяли, какие сценарии можно реализовать на первом этапе, а какие необходимо переносить в последующие итерации.
Исследование и формирование гипотез
Исследование состояло из трёх частей:
- сегментация пользователей и формулировка JTBD;
- анализ текущих бизнес-процессов;
- конкурентный анализ и определение состава MVP.
На выходе мы получили карту пользовательских сценариев, список продуктовых гипотез и понимание того, какие функции критичны для первой версии продукта, а какие можно перенести на следующие итерации.
Ключевым открытием стало то, что мы проектируем не инструмент для одного человека, а рабочую среду для целой команды.
Основной пользователь платформы. Отвечает за снабжение объектов и ежедневно работает с заказами.
Основные задачи:
- быстро оформлять заказы без участия менеджера поставщика;
- понимать сроки поставки и наличие товаров до оформления заказа;
- разделять заказы по объектам и контролировать их статус;
- оперативно вносить изменения в уже созданные заказы.
- большинство действий требовали звонка менеджеру;
- заказы не были привязаны к объектам строительства;
- информация о сроках поставки была непрозрачной;
- любые изменения приходилось согласовывать вручную.
Контролирует бюджеты и согласовывает крупные закупки, не участвуя в операционной работе.
Основные задачи:
- видеть, кто из сотрудников оформляет заказы;
- контролировать расходы по объектам;
- управлять доступами сотрудников;
- разделять работу по разным юридическим лицам.
- все сотрудники работали под одним аккаунтом;
- отсутствовало разграничение прав доступа;
- заказы и документы по разным компаниям смешивались между собой.
Сегмент появился в процессе исследования по инициативе клиента. Прямые интервью провести не удалось, поэтому гипотезы формировались на основе существующих процессов документооборота и экспертных знаний сотрудников компании.
Основная задача — быстро находить документы по конкретному поставщику, заказу или периоду.
Главная боль— документы Архитектор Групп были распределены между ЭДО, электронной почтой и внутренними системами компании.
Компания, которая раньше не работала с Архитектор Групп и привыкла решать все вопросы через персонального менеджера.
Основные задачи:
- понять условия сотрудничества без необходимости звонить;
- быстро пройти регистрацию и начать работу.
- непрозрачные условия до первого контакта;
- непонятная логика B2B-регистрации и работы с ЭДО.
Основным источником информации стали интервью с владельцем бизнеса, сотрудниками компании и представителями ключевых подразделений. Доступ к экспертам был ограничен, поэтому каждая встреча проходила по заранее подготовленному сценарию с конкретными вопросами и гипотезами.
Исследование показало, что большая часть информации уже существовала внутри компании, но была распределена между людьми, 1С, электронной почтой и ЭДО.
Практически каждый важный шаг клиента зависел от менеджера:
- уточнение наличия товара;
- получение персональных условий;
- формирование счёта;
- контроль статусов заказа;
- поиск документов.
1. Объект строительства важнее отдельного заказа
Пользователи мыслят не заказами, а объектами. Поэтому вся структура платформы должна строиться вокруг объектов и связанных с ними поставок.
2. Платформой пользуется команда, а не один человек
Внутри одной компании работают закупщики, руководители и бухгалтеры. Продукт должен учитывать разные роли, права доступа и сценарии взаимодействия.
3. Главная ценность платформы — прозрачность
Клиенты хотели получать доступ к информации, которая раньше была доступна только через менеджера: наличие товаров, персональные условия, статусы заказов и документы.
Эти выводы стали основой для формирования MVP и дальнейшего проектирования пользовательских сценариев.
1. Объект строительства важнее отдельного заказа
Пользователи мыслят не заказами, а объектами. Поэтому вся структура платформы должна строиться вокруг объектов и связанных с ними поставок.
2. Платформой пользуется команда, а не один человек
Внутри одной компании работают закупщики, руководители и бухгалтеры. Продукт должен учитывать разные роли, права доступа и сценарии взаимодействия.
3. Главная ценность платформы — прозрачность
Клиенты хотели получать доступ к информации, которая раньше была доступна только через менеджера: наличие товаров, персональные условия, статусы заказов и документы.
Эти выводы стали основой для формирования MVP и дальнейшего проектирования пользовательских сценариев.
Сервис доставки Florentini — это сеть из 5 ресторанов в разных локациях Москвы, с отличиями в меню, доступности блюд и условиях доставки. Один и тот же пользователь может заказывать еду из разных ресторанов, каждый раз сталкиваясь с разными ограничениями и сценариями.
Чтобы сохранить эту логику и не усложнить пользовательский путь, проектирование начали с карты сайта и декомпозиции сервиса. Мы зафиксировали ключевые сценарии заказа, точки входа и минимально необходимый набор экранов — от первого касания до повторного заказа. Это позволило заранее договориться о структуре продукта и функционале, не распыляясь на второстепенные решения.
Далее мы собрали user flow для основных сценариев: доставка, самовывоз, выбор ресторана, работа с корзиной и повторные заказы. Особое внимание уделяли моментам, где логика могла «ломаться» — смене ресторана, недоступности блюд, изменению адреса доставки. Эти сценарии сразу учитывались в архитектуре, а не решались на этапе визуала.
Проектирование велось в тесной связке со стейкхолдерами: мы регулярно синхронизировались по бизнес-механикам, быстро вносили правки и уточняли требования. Такой формат позволил держать высокий темп и принимать решения без затягивания сроков.
На основе согласованной структуры были собраны мобильные прототипы — mobile first, так как основной сценарий заказа происходит со смартфона. Прототипы использовались как рабочий инструмент: для обсуждения логики, навигации и взаимодействий, а не для финальной эстетики. Это помогло выровнять ожидания команды ещё до этапа дизайн-концепции и снизить количество изменений на поздних стадиях.
Визуальная концепция
Florentini — это сеть из пяти итальянских ресторанов в разных районах Москвы. Они отличаются по локации, аудитории и атмосфере: где-то это семейный ресторан для завтраков и обедов, где-то — место для деловых встреч и ужинов. При этом все рестораны объединяет общее ощущение — аутентичная итальянская кухня, спокойный уровень «выше среднего» и внимание к деталям.
Задача визуального концепта заключалась в создании единого цифрового образа бренда, который:
- передаёт атмосферу Florentini независимо от локации,
- вызывает доверие к качеству еды,
- ощущается тёплым, спокойным и «своим»,
- не спорит с интерфейсом и не усложняет пользовательский путь.
Важно было сохранить баланс между эмоцией и функциональностью: сайт должен работать как сервис доставки, но по ощущению — быть продолжением опыта ресторана.
Итальянская культура без клише
Вместо этого мы опирались на атмосферу самих пространств Florentini:
- тёплые оттенки,
- натуральные материалы,
- светлое дерево,
- арочные формы,
- мягкий свет,
- внимание к деталям и фактурам.
Для фона и текстового контента были выбраны контрастные светлые и тёмные оттенки — это обеспечило хорошую читаемость и не перегружало восприятие, особенно на мобильных устройствах.
Типографика также поддерживает баланс эстетики и удобства:
- для заголовков выбран шрифт Angst — декоративный, изящный и при этом хорошо читаемый, который подчёркивает характер бренда и ассоциируется с изысканной кухней;
- для основного текстового контента использован Manrope — нейтральный и устойчивый шрифт, обеспечивающий комфортное чтение важной информации.
Финальный дизайн и ключевые решения
Навигация и сценарии заказа
Меню с категориями и подкатегориями «закрепили» вверху экрана, чтобы оно оставалось доступным на протяжении всего взаимодействия с каталогом. Это позволило быстро переключаться между разделами, не терять контекст и собирать заказ без лишних возвратов и скролла.
Такой подход помог сохранить ощущение «приложения», даже несмотря на формат сайта, и сократить путь пользователя от выбора блюд до оформления заказа — особенно на мобильных устройствах.
Карточка блюда
Карточка блюда стала ключевой точкой принятия решения. Мы уделили особое внимание визуалу и структуре информации: крупные фотографии, понятный состав, возможность выбрать дополнительные опции или особенности блюда.
За счёт этого карточка не выглядит как обычная строка в меню, а воспринимается как полноценное описание ресторанного блюда — с ощущением качества, прозрачности и индивидуального выбора. Это способствовало усилению доверия к продукту и снижало количество сомнений на этапе добавления в корзину.
Корзина и оформление заказа
Корзина была спроектирована как часть единого сценария заказа, без резких переключений между экранами. Пользователь мог редактировать состав заказа, менять опции и сразу видеть итоговую стоимость, не выпадая из основного потока взаимодействия.
Такой формат снижал фрустрацию на финальном этапе и делал оформление заказа быстрым и предсказуемым — по тем же принципам, к которым пользователи привыкли в мобильных приложениях доставки.
UI-библиотека и демонстрация взаимодействий
Параллельно с проектированием мы собрали UI-библиотеку ключевых компонентов: навигация, карточки блюд, состояния элементов, корзина, формы и служебные экраны. Это позволило удерживать единый визуальный язык, быстрее вносить изменения и упростить передачу макетов в разработку.
Для наглядности сложных сценариев и взаимодействий ещё до запуска мы дополнительно делали моушен-ролики с ключевыми пользовательскими потоками.
Такой формат помог:
- согласовать логику работы интерфейса со стейкхолдерами без долгих объяснений,
- снять вопросы у разработки по поведению элементов и переходам,
- минимизировать расхождения между задуманным UX и реализованным интерфейсом.
Реализация и дизайн-контроль
Бэк и фронт находились на стороне клиента. Я сопровождала проект на этапе разработки: объясняла логику интерфейсов и механик, давала комментарии по реализации и отвечала на вопросы команды.
Детальное дизайн-ревью всех экранов вел другой дизайнер, а финальное утверждение решений было на стороне арт-директора. Моя зона ответственности — сохранение продуктовой логики и соответствие ключевых сценариев исходным макетам.
Отдельное внимание уделили навигации: на этапе разработки команда предлагала отказаться от закреплённого меню категорий как от более сложного в реализации. Я отстояла это решение, аргументировав его значимостью для пользовательского опыта и соответствием привычным food-tech паттернам.
Результаты и эффект
🍒 Ключевые цифры и награды я вынесла в начало кейса — там как раз та самая вишенка на торте: метрики, рост и профессиональные награды.
Фотографии с офлайн-награждений можно посмотреть на главной странице.
Если коротко про эффект от запуска:
- сайт стал заметно лучше работать на продажу — выручка по ключевым целям выросла на +13,2%
- пользователи стали чаще возвращаться и делать повторные заказы
- проект получил несколько профессиональных наград, включая золото Tagline Awards 2025 и призовые места на Workspace Digital Awards
Что было дальше
После запуска команда Florentini вернулась к нам уже с новыми задачами — за пределами сайта. Мы начали работать над элементами айдентики для доставки: брендирование машин, коробки для пиццы, стаканчики для кофе.