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