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