Дизайн меню интернет-магазина КлиматПрофи | BRDN

Дизайн меню интернет-магазина КлиматПрофи

С любовью и заботой мы вносим свой вклад в развитие climatprofi.by с лета 2017 года.
В этой статье рассказываю о выпадающем меню: о причинах, проблемах, решениях и процессе, которые привели нас к текущему дизайну.

Дизайн-принципы

Дизайн-принципы — это набор слов, описывающих продукт (логотип, айдентику, бренд — что-угодно). Мы используем их, чтобы задать общий контекст, в котором создаётся продукт. Дизайн-принципы обозначают границы для принятия решений.

Дизайн-принципы КлиматПрофи:

  • Чистота. Мы стремимся к чистоте визуала, к ясности формулировок текста.
  • Функциональность. Каждый элемент обоснован, мы не делаем пустых украшательств.
  • Надёжность. Мы используем надёжные решения, а не экспериментируем.
  • Плотность. Мы не добавляем в элементы воздуха больше, чем нужно.
  • Спокойствие. Мир хаотичен. Мы спокойны, уверены в себе, не торопим.

Первое меню

В наброске первой версии сайта в 2017 году не было выпадающего меню. Перейти в каталог можно было по ссылке в шапке сайта. Каталог был отдельной страницей:
image
(Один из первых набросков первой версии сайта, 2017 год)

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

Меню с баннером

Для ускорения взаимодействия с каталогом появилась необходимость сделать выпадающее меню. Было реализовано такое решение:
image
(Меню на главной странице интернет-магазина)

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

На других страницах сайта меню превращается в кнопку. Изначально нам казалось хорошей идеей открывать меню при наведении. Мы чувствовали, что это может быть проблемой. Но решили попробовать, чтобы добиться более «плавного» взаимодействия с интерфейсом:
image
(Кнопка меню на остальных страницах интернет-магазина)

Это оказалось ошибкой из-за неоднородности работы интерфейса.

Открытие меню по наведению на кнопку на страницах сайта было однородно с открытием подкатегорий на главной странице. На главной странице при наведении на категорию происходит открытие подкатегорий, по клику – переход в категорию. То есть кнопка выполняет два действия. Кнопка меню на других страницах при наведении и клике выполняет только одно действие: открытие выпадайки меню. Это значит, что два действия приводили к одному результату. Из-за этого возникали ошибки.

Иногда меню не успевало загружаться и открывалось через секунду после наведения курсора. Особенно это было заметно при плохом интернете. Так как пользователи любят нажимать на кнопки, а меню при наведении не открывалось мговенно, пользователь кликал на кнопку. За доли секунды, пока он нажимал, меню с запозданием открывалось. И получалось так, что кликом пользователь закрывал меню. Это сбивало и раздражало.

Можно было пойти дальше, конкретнее прописать поведение элементов, отловить и исправить ошибки. Но мы посчитали это чрезмерным усложнением. Поэтому вернулись к простому и надёжному решению: открытию меню по клику на кнопку. Интерфейс стал более предсказуемый.

Открытое меню состоит из двух элементов: категорий и баннера. На момент дизайна этого меню каталог состоял из категорий первого и второго уровня, поэтому меню содержит две колонки:
image
(Открытое меню: две колонки категорий и баннер)

Меню состояло из двух уровней из-за неуверенности, как лучше упорядочить товары в этих категориях. Мы думали, что фильтры могут заменить подкатегории. Мы не хотели тратить лишние деньги на наполнение каталога: создавать категории, придумывать для них названия, раскидывать несколько тысяч товаров по этим категориям. С ростом каталога мы определили критерии. По этим критериям мы разделили категории и фильтры.

При открытии меню появляется синее тонирование фона: image
(Синее тонирование фона при открытии меню)

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

Структура каталога

За 4 года наполнения каталога товаров стало в несколько раз больше. Появилилась проблема: на сайте нет единой точки просмотра всего каталога. Каталог увеличился, мы решили завести категории третьего и четвертого уровня. Так как в меню есть категории только первого и второго уровня, новые подкатегории в меню не видны. Это затрудняет навигацию.

Зеленым выделена часть каталога, которая есть в меню. Красным – новые категории, которых в меню нет.
image
(Структура каталога)

Требования к новому меню

Мы сформулировали требования к новому меню:

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

Процесс дизайна компьютерной версии меню

Добавление новой колонки

Так как в меню с баннером не хватало категорий третьего и четвертого уровня, первая идея – добавить недостающие колонки с категориями в меню. Взаимодействие пользователей с меню остается прежним, принцип его работы привычен, увеличивается только глубина.
image
(Меню с минимальными изменениями. Добавили 2 новые колонки)

Но есть серьезная проблема: размер баннера зависит от количества колонок. Когда в меню всегда две колонки, размер баннера фиксирван. При добавлении новых колонок про-во для баннера сжимается по ширине: image
(Ширина баннера сильно меняется при переходе вглубь меню)

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

При дизайне этого решения мы нашли новую проблему. Так как меню определенной высоты, в колонку помещается ограниченное число карточек категорий. В категории «комплектующие для отопитлей» 12 подкатегорий. Все подкатегории не помещаются в блок, пользователю придется листать список: image
(Пользователю придется листать, так как все карточки категорий не помещаются в меню)

Вывод: нужно показать максимально возможное количество карточек категорий.

Мегаменю

Мегаменю — это тип расширяемого меню. Мегаменю позволяет показать все категории и подкатегории каталога на одной странице. Мегаменю является хорошим выбором для большого каталога, так как вмещает в себя большое количество категорий и подкатегорий. Мы решили попробовать сделать мегаменю для нашего сайта.
image
(Структура нашего каталога)

Такие проблемы увидели:

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

image
(Набросок мегаменю. Вкладка запчастей заполнена, а вкладка рефрижераторов пустая)

Мегаменю нам не подходит.

Плюсы:

  • Мегаменю показывает весь каталог сразу;
  • Подходит для больших каталогов.

Минусы:

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

Так как мегаменю нам не подошло, мы сделали шаг назад. Проблемы, которые не решены: в меню помещается мало карточек категорий, баннер зависит от количества колонок.

Чтобы вместить больше категорий, мы попробовали убрать изображения. Получаются списки подкатегорий:
image
(Меню без изображений)

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

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

Плюсы:

  • Список занимает меньше места. В меню помещается больше карточек, поэтому пользователь видит больше информации;

Минусы:

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

Отказываемся от списка. Ищем другое решение.

Вертикальные карточки

Так как изображения важны для навигации, возвращаем их. Чтобы вместить больше карточек, можно сделать их вертикальными:
image
(Меню с вертикальными карточками)

Такой вариант меню решает проблему с баннером, карточек помещается больше. Но проблема в том, что карточки категорий сливаются с карточками подкатегорий. Попытка решения – изображения и текст в карточках категорий разместить горизонтально:
image

Теперь карточки не сливаются, но есть проблемы:

  • Меню получается эклектичным: текстовые карточки, горизонтальные карточки с изображениями, вертикальные карточки с изображениями.
  • В некоторых категориях, из-за неравномерного распределения подкатегорий, будет много белого пространства.
  • Непонятно, что делать с категориями четвертого уровня.

Резюмируя: меню выглядит хаотично, слишком много воздуха и незадействованного пространства. Это противоречит дизайн-принципам. Мы не добавляем в элементы воздуха больше, чем нужно. Такое меню нам не подходит.

Меню на всю страницу

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

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

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

Меню на весь экран – плохая идея.

Итоговое решение

В итоге мы пришли к меню с выпадайками.

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

Уровней вложенности в таком решении может быть более четырех. При расширении каталога добавление категории пятого уровня не будет проблемой.
image

Это решение мы посчитали наилучшим.

В таком меню баннер не зависит от размера окна браузера и количества колонок. Мы добавили баннер под категории: он привлекает взгляд, но при этом не перетягивает все внимание с категорий.

Нет ощущения перехода на новую страницу, нет пустого пространства. Колонка «обнимает контент». Не имеет значение неравномерность распределения подкатегорий. Меню одинаково удобно как при двух уровнях вложенности, так и при четырех или пяти. Если в категории много подкатегорий, колонка вытягивается по высоте экрана – настолько, насколько это вообще возможно. Пространство использовано с максимальной эффективностью.

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

Меню позволяет изучить весь асортимент каталога, при этом пользователь получает информацию последовательно.

Процесс дизайна мобильной версии меню

При дизайне мобильной версии мы пришли к двум вариантам:

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

Ниже рассказываю о преимуществах и недостатках обоих решений, и какое решение мы в итоге выбрали.

Меню со всеми подкатегориями

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

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

В мобильной версии не получится вставить изображения в карточки категорий: изображения слишком мелкие для распознавания. А в качестве иконок изображения не подходят – слишком деализированные.

Также есть проблема с переходом во все товары категории. В компьютерной версии карточка категории выполняет два действия: при наведении открываются подкатегории, при клике происходит переход в категорию. В мобильной версии это невозможно, так как нет hover-state. Поэтому кнопка категории выполняет только одно действие, в данном случае открытие подкатегории. Варианты решения проблемы:

  • Сделать отдельную кнопку для перехода во все товары раздела. Эта кнопка размещается наравне с подкатегориями. С точки зрения здравого смысла это не верно: кнопка «Все товары раздела» включает в себя эти подкатегории – диссонанс.
  • Не использовать кнопку перехода во все товары. Пользователь может перейти только в конечную подкатегорию раздела. Такое решение заставляет пользователя выбрать подкатегорию, даже если он этого не хочет. А если пользователь не знает, какая подкатегория ему нужна, он будет в ступоре. Такой вариант ухудшает навигацию.

image

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

Меню без подкатегорий

Меню содержит только главные категории. Переход в подкатегории осуществляется внутри страниц категорий.

На страницах каталога у нас есть карточки подкатегорий с горизонтальным скроллом: image

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

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

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

Решение

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

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

Передача макетов в разработку

В макетах, подготовленных к вёрстке:

  • В макетах порядок: родственные объекты сгруппированы, расположение фреймов чем-либо обусловлено.
  • Отступы однородны, не скачут.
  • Ассеты загружены в облако, соблюдают правила именования и структуру проекта. (или соблюдают студийные правила именования и структуру проекта)
  • В макете используется именно та графика, которая будет в продукте. Другими словами: графика в макетах соответствует ассетам.
  • Все состояния каждого элемента изображены либо описаны: анимации, переходы, CSS-состояния (псевдоклассы), большое / малое кол-во данных, многострочные / однострочные заголовки и тд.
  • Нет экспериментов, набросков для обсуждения с клиентом (и клиент в курсе, какие решения используются).
  • Особо важные и потенциально непонятные моменты описаны в описании задачи.
  • Спросить у разработчика, есть ли у него какие-либо вопросы, видит ли он потенциальные проблемы с реализацией макетов.
  • Названия элементов, стилей и компонентов соответствуют тому, как их будет называть разработка.
  • (если проект достаточно большой) Элементы вынесены в компоненты.
  • Заданы текстовые стили (шрифты, размеры, названия CSS-переменных и тд). Указаные стили по умолчанию для деск, таб, моб.
  • Заданы цветовые стили (в том числения названия CSS-переменных цветов).

Разработка

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

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

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

В процессе дизайна мы общаемся с разработчиком. Дизайнер не знает все тонкости разработки, поэтому обращается к разработчику с вопросами.

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