Как структурировать мобильное меню, чтобы гость быстрее заказал

Мобильное меню нужно строить вокруг задач гостя, а не копировать оглавление бумажной папки. Человек должен узнать раздел, найти позицию по названию или смыслу, понять карточку и перейти к выбору без помощи сотрудника.

Универсального числа категорий и секунд поиска нет. Структуру принимают через наблюдаемые задания: нашёл ли новый человек нужное блюдо, где свернул не туда и какую подпись понял иначе, чем команда.

Если читать 30 секунд

• Сначала выпишите задачи гостя, затем группируйте позиции; внутреннее устройство кухни не должно определять навигацию.
• Название раздела обязано предсказывать его содержимое без пояснения сотрудника.
• Карточка показывает различия, нужные до выбора: название, короткое описание, цену, фото, вес или объём и доступные варианты.
• Поиск и фильтр помогают внутри каталога, но не исправляют неправильные категории и названия.
• Проверьте структуру карточной сортировкой и пятью заданиями на обычном телефоне.

Опишите пять задач до создания разделов

Информационная архитектура начинается с вопроса «что человек хочет найти». Для кофейни это могут быть быстрый завтрак, напиток к еде, знакомый товар по названию, вариант без конкретного ингредиента и небольшой десерт. У ресторана задачи будут другими.

Запишите реальные формулировки гостей и наблюдения смены. Не превращайте догадку «все ищут фирменное» в факт. Если данных мало, используйте вопросы, которые сотрудники слышат у стойки, и проверьте их на тесте.

Для каждой задачи укажите:

• с какого слова гость начинает поиск;
• в каком разделе ожидает увидеть результат;
• какие две позиции будет сравнивать;
• какую деталь проверит перед добавлением;
• что заставит вернуться назад.

Если каталог переносится частично, сначала примените оценочную карту первой волны оцифровки. Сортировка карточек с неполным случайным набором проверит только этот набор, а не будущую архитектуру.

Разделы должны отвечать ожиданию гостя

Хороший раздел объединяет позиции по понятному сценарию: «Завтраки», «Кофе», «Холодные напитки», «Основные блюда», «Десерты». Название «Цех № 2» удобно сотрудникам, но ничего не говорит новому посетителю.

Используйте три правила:

1. Один принцип группировки на уровне. Не ставьте рядом категории по времени, технологии и маржинальности без явной причины.
2. Различимые названия. «Напитки» и «Бар» конкурируют, если гость не понимает границу.
3. Предсказуемый состав. Если десерт находится в «Рекомендациях шефа», человек может не найти его через обычный путь.

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

В «Умном кафе» каталог состоит из меню, разделов и позиций. Гость может переключать опубликованные меню, выбирать раздел, искать и сортировать позиции. Эта техническая возможность не решает, как назвать и наполнить структуру конкретной точки.

Порядок разделов зависит от сценария, а не от длины списка

Первый экран должен вести к частой задаче, но «частая» не равна «самая прибыльная». Утром кофейне может быть важен завтрак, днём — обеденное предложение. Если используются несколько меню, переключение должно быть понятнее, чем один бесконечный каталог.

Для ручного порядка разделов составьте таблицу:

Раздел	Главная задача	Когда нужен	Что идёт первым	Риск ошибки
Завтраки	собрать полноценный утренний заказ	утро или весь день по правилам точки	понятные базовые блюда	скрыть время доступности
Кофе	выбрать напиток и размер	весь рабочий период	знакомые основы	смешать горячие и холодные варианты
Основные блюда	найти формат приёма пищи	обед и вечер	группы по типу блюда	повторить кухонные станции
Десерты	завершить заказ или выбрать перекус	весь день	позиции, которые легко сравнить	спрятать размер и состав

Таблица условна. Используйте свои задачи и часы. Проверяйте изменение порядка на сопоставимых гостях; не считайте собственную скорость навигации доказательством, потому что команда знает меню наизусть.

Карточка должна помогать различить соседей

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

Проверьте соседние карточки парами:

• отличаются ли названия без внутренних кодов;
• объясняют ли короткие описания вкус или формат;
• сопоставимы ли фотографии по масштабу и подаче;
• видна ли базовая цена до открытия;
• понятно ли, что позиция недоступна;
• не скрыт ли обязательный выбор варианта.

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

Поиск, фильтр и сортировка — запасные маршруты

Поиск полезен для гостя, который знает название или часть описания. В текущем интерфейсе он сопоставляет запрос с названием, SKU, коротким и полным описанием. Значит, внутренний артикул не заменяет человеческое название, а ключевые различия нельзя прятать только в изображении.

Фильтр «только доступные» исключает позиции с признаком недоступности. Сортировка поддерживает ручной порядок, название, SKU и цену в обе стороны. Эти инструменты помогают сузить список, но не являются персональной рекомендацией или диетическим фильтром.

Не обещайте поиск по ингредиенту, если его нет в описании, и не называйте фильтром аллергенов обычный текстовый запрос. Для важных ограничений гость всё равно должен открыть карточку и при необходимости уточнить безопасность у сотрудника.

Сортировка карточек: как собрать черновую архитектуру

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

Проведите упражнение с людьми, которые не составляли меню. Один сотрудник зала полезен как источник вопросов, но не должен быть единственным участником: он уже знает внутреннюю логику.

Этапы:

1. участник раскладывает позиции по своим группам;
2. даёт группам короткие названия;
3. отмечает карточки, которые подходят в два места;
4. называет позиции, которые никуда не попали;
5. объясняет, чем соседние группы отличаются.

Сравнивайте не только совпадение названий. Важнее места устойчивого расхождения. Если половина участников кладёт лимонад к «Кофе», проблема может быть в карточке или в слишком широком разделе напитков.

Пять заданий для проверки на телефоне

После карточной сортировки соберите кликабельную или рабочую версию каталога. Дайте пять заданий без подсказки пути:

1. Найти быстрый завтрак. Проверяет название и порядок раздела.
2. Найти конкретную известную позицию. Проверяет поиск и качество названия.
3. Сравнить два похожих напитка. Проверяет карточки, фото, объём и описание.
4. Выбрать только доступную позицию и предусмотренный вариант. Проверяет фильтр, состояние карточки и детали.
5. Добавить позицию в корзину и вернуться за дополнением. Проверяет, сохраняется ли понимание структуры после первого выбора.

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

Проверить полный контекст от входа до заказа помогает статья о пути гостя после сканирования. Здесь фокус уже: как устроен каталог между входом и корзиной.

Как разбирать ошибки теста

Если позицию ищут не там, не переносите её сразу. Сначала уточните, ошибся один человек или название раздела системно обещает другое. Если поиск находит товар, а навигация нет, проблема чаще в архитектуре. Если не помогает и поиск, проверьте лексику карточки.

Симптом	Возможная причина	Следующее действие
участник открывает два соседних раздела	граница категорий неясна	переименовать или объединить группы
поиск не находит знакомое слово	слово отсутствует в названии и описании	добавить естественную формулировку
похожие карточки невозможно сравнить	одинаковые описания или несопоставимые фото	переписать различия и выровнять подачу
недоступное блюдо выбирают снова	состояние плохо заметно или не обновлено	проверить доступность и гостевой вид
участник бросает обязательный вариант	группа появляется неожиданно	объяснить выбор в карточке и сократить варианты

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

Протокол принятия структуры

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

Решение	Наблюдение	Что меняется	Кто проверяет после правки
объединить разделы	участники одинаково называют две соседние группы	одно название и общий порядок карточек	владелец каталога
переименовать раздел	люди находят нужные позиции, но ожидают другое слово	короткое гостевое название	сотрудник, не участвовавший в сборке
переписать карточку	раздел выбран верно, но позиции невозможно различить	название, описание, фото или объём	кухня и редактор каталога
оставить как есть	сбой единичный и не повторился	ничего	менеджер фиксирует решение

Схема готова к публикации, когда участник без подсказки выполняет ключевые задания, повторяющиеся ошибки устранены, а у спорных карточек назначен владелец. Это не универсальный норматив конверсии. Приёмка отвечает на более узкий вопрос: можно ли объяснить текущую архитектуру наблюдаемыми действиями, а не мнением автора меню.

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

Что можно проверить в публичной демоверсии

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

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

Меню становится быстрым, когда его понимает новый человек

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

Проведите сортировку карточек и пять заданий, затем исправьте повторяющиеся сбои. Когда черновик разделов готов, обсудите структуру каталога своей точки через форму. Принимайте архитектуру по действиям нового пользователя, а не по тому, насколько привычно она выглядит составителю меню.