FoodTechB2BCRM

Hammersmith — a large CRM system for restaurant chains

Я работал над большой CRM системой для крупной сети ресторанов. Со мной в команде были менеджер из ресторана, проджект менеджер и команда разработчиков

Role: Product Designer
Team: DesignerDevelopersManager

01 — Контекст и проблема

HammerSmith — ресторанная POS/back-office система, рассчитанная на двух разных пользователей: менеджера (десктоп, мышь, плотные данные) и кассира (тач-экран, минимум когнитивной нагрузки, работа под давлением потока гостей). Параллельно разрабатывается и мобильное приложение для гостей ресторана. Одна система — два разных режима и в этом главный дизайн-вызов проекта.

02 — Задача

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

03 — Выбор визуального направления

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

04 — Процесс и решения

До контента экран нёс три служебных строки подряд: заголовок с поиском, табы категорий и полноширинный баннер о блюдах без кода ИКПУ — многовато для плотного менеджерского экрана. Объединили заголовок с поиском и табы в одну строку, а баннер заменили на компактный кликабельный чип-предупреждение («17 без ИКПУ») в той же строке, что и табы, плюс перевели табы с touch- на mouse-размерность.

Заказы

Список получил свой скролл, панель — естественную высоту с закреплённым снизу блоком действий. Конструктор нового заказа был одноколоночным — блюда добавлялись кликом «+» без видимой корзины и итога. Заменили на двухпанельный: слева каталог с категориями и поиском, справа живая корзина с количеством и суммой.

Продумали матрицу статус → действия: «Готовится» остаётся редактируемым, «Выполнен»/«Отменён» — терминальные состояния с кнопкой «Повторить заказ» вместо редактирования. И вынесли отмену заказа в отдельное модальное подтверждение со структурированной причиной — раньше инлайн-поле причины конфликтовало визуально с крестиками удаления позиций.

Столы

Самый запутанный раздел. Создание зала следовало паттерну «сначала создать, потом назвать». Плюс рассинхрон данных (бейдж «1», а внутри зала — «0 столов») и дублирование инструментов внутри canvas-редактора: удаление и выравнивание были и в левой панели, и в правой, без привязки к выбранному объекту.

Решение: naming-модалка вместо create-before-name; статичную левую панель заменил плавающий тулбар, зависящий от выделения; выравнивание и действия с объектом (Копировать/Удалить) собраны в правой панели свойств, левая — только под canvas-уровневые инструменты.

Клиенты, Официанты

Спроектировали сегментацию клиентов (VIP / Постоянный / Новый), сводный блок метрик, слайд-панель для быстрого просмотра клиента и отдельную полную карточку клиента для работы с полной записью.

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

Отзывы, Филиалы, QR меню

Отзывы — редизайн со сводным блоком (средний рейтинг + распределение по звёздам), компактной таблицей вместо перегруженной, обрезкой длинных комментариев и слайд-панелью для ответа.

Филиалы — блок со списком всех филиалов сети.

QR меню — генерируемые отдельно под каждый филиал.

Категории, Бронирование

Категории — категории блюд, на которые опирается навигация в разделе Меню.

Бронирование — модуль брони столов для гостей на конкретное время.

05 — Результат

На данный момент в кейсе описана только часть проделанной работы — меньше половины. Помимо разобранных разделов, в работе ещё три больших блока системы (Кадры, Склад, Охрана), которые сейчас находятся на стадии уточнения требований и дизайн-решений.

Проект живой и продолжает развиваться: часть решений, описанных выше, уже закреплена как паттерн для всей системы (naming-модалки вместо create-before-name, плавающие property-панели вместо статичных, разделение canvas- и object-уровня инструментов) — и будет применяться при доработке оставшихся разделов, а не изобретаться заново под каждый из них.