От переводчика
Решила сделать перевод одной интересной статьи по упрощению навигационной системы сайта. Это только первая часть про структурирование контента на сайте. Она достаточно объемная, но от этого не менее интересная, надеюсь Вы не устанете читать. Здесь содержаться достаточно подробные пояснения как сделать информационную архитектуру проще и понятней, особенно для крупных сайтов с большим количеством контента, вроде интернет-магазинов.
Если найдете какие-то ошибки, пожалуйста, напишите в лс, я исправлю.
Поехали!
Навигация – одна из наиболее важных составляющих опыта взаимодействия пользователя (UX). Для пользователя это всего лишь способ достижения конечной цели, а конечная цель – это потребление контента. Поэтому пользователи имеют достаточно противоречивые ожидания относительно контента и навигации. Если предполагается, что контент должен быть уникальным, непредсказуемым и захватывающим, то навигация должна быть как можно более простой и предсказуемой.
Четыре шага к идеальной навигационной системе
Для создания удобной навигационной системы, дизайнер веб-сайта должен ответить на четыре вопроса в определённом порядке:
1. Как лучше всего структурировать контент?
2. Как лучше всего пояснить варианты выбора в навигации?
3. Какой тип навигационного меню больше всего подходит для вмещения всех вариантов выбора?
4. Как лучше всего разработать меню?
Первые два вопроса касаются структурирования и обозначения контента, которые обычно относятся к информационной архитектуре. Информационные архитекторы обычно визуализируют результаты своей работы на диаграмме карты сайта.
Диаграмма карты сайта даёт представление о навигационной структуре сайта.
Тем не менее, по причинам, которые будут объяснены в деталях в этой серии статей, карта сайта в качестве навигации не будет способствовать лучшему возможному опыту взаимодействия пользователя. Не менее важно создание пользовательского навигационного меню, которое правильно вмещает, организует и постепенно раскрывает все опции. Оно позволяет пользователям комфортно искать, просматривать и пропускать возможные варианты выбора.
Разработка такого меню навигации может быть достигнута ответом на третий и четвертый вопросы, упомянутые выше, относящиеся к проектированию взаимодействия с навигацией. Первые два вопроса будут рассмотрены в первой части, вторые два во второй части статьи.
Структурирование контента
Для правильного структурирования содержимого веб-сайта, во-первых, нужно рассмотреть, как пользователи ищут информацию, затем структурировать контент таким образом, чтобы он в лучшем виде соответствовал этим предпочтениям.
Как пользователи ищут информацию
Когда пользователь ищет что-либо, будь то автомобиль, рецепт, финансовая услуга, предмет одежды, новостная статья, фитнес-упражнение, развлекательное видео или любой другой объект или информация, они могут знать и не знать точное название того, что они ищут. Если мы предположим, что пользователи всегда знают точное название того, что они ищут, лучшим способом помочь им найти это, было бы предоставление большого перечня от А до Я или простого ввода через поисковое поле.
Конечно, всё не так просто. Как будет показано во второй части, даже если пользователи знают точное название того, что они ищут, то как списку от А до Я, так и поиску присущи некоторые проблемы взаимодействия, которые делают их неподходящими средствами навигации в качестве основных или единственных. Кроме того, пользователи зачастую не знают точное название или даже не интересуются вещью или её точным названием; скорее, у них есть ключевое слово или отличительная черта, связанная с тем, что они ищут.
Первый шаг на пути направления пользователя на необходимый контент – это агрегирование или категоризация видов товаров или информации на сайте.
Метаданные как основа навигационной системы
Информация, собранная о конкретном предмете или части контента, обычно относится к метаданным – это информация об информации.
Не вдаваясь в подробности, предметы могут принадлежать определенным категориям метаданных, будь то категория политического фокуса новостной статьи, размера экрана монитора, режиссер фильма, типа воротника рубашки или уровня сложности фитнес-упражнения. Конечно, категории могут сами делится на подкатегории, по таким показателям как цена, популярность или дата публикации.
Пользователи могут искать контент через эти категории метаданных. Тем не менее, как мы увидим, предоставлять пользователям все возможные варианты поиска контента вовсе не обязательно. В лучшем случае это просто бы загромоздило интерфейс, замедлило и усложнило бы процесс навигации, а в худшем – сбило бы столку, утомило и раздражило пользователей до такой степени, что они бы ушли с сайта.
Нужно тщательно продумать какие и на какой стадии показывать категории пользователям.
Три типа категорий метаданных
Чтобы решить какие и когда показывать категории метаданных, разделите Ваши категории на три группы: ключевые, дополнительные и несущественные.
Проблема информационной архитектуры в том, что классификация категорий на ключевые, дополнительные и несущественные во многом зависит от предпочтений целевой аудитории, цели веб-сайта и даже объёма контента. Так или иначе, сформировав группы категорий единожды, простые правила помогут Вам решить, когда показывать какую категорию.
Ключевые категории
К ключевым категориям относятся такие, которые будут важны для всех целевых пользователей. Таких категорий обычно немного, но любой элемент должен принадлежать хотя бы к одной такой категории, что упростит как работу дизайнера, так и навигацию для пользователей.
Выделение ключевых категорий
Небольшая подборка категорий метаданных для рецептов пищи может включать «блюдо», «основной ингредиент», «специальная диета», «торжественное событие», «кухня» и «время приготовления». Для всех этих категорий единственной ключевой будет «блюдо». Не каждый сидит на специальной диете и не каждое блюдо должно подходить под какое-нибудь торжественное событие, но почти все каждый день разделяют блюда на закуски, завтрак, основное блюдо, гарнир, салат, десерт и т.д.
Так как деление на блюда будет важно для всех целевых пользователей, то это должна быть первая группа категорий, которая будет представлена пользователям.
«Блюдо» — ключевая группа категорий метаданных для рецептов.
Однако, как упоминалось выше, целевая аудитория или цели веб-сайта могут влиять на классификацию категорий, особенно на тематических сайтах.
Например, деление на «блюда» может быть не совсем актуально для всех пользователей, которые посещают сайты о рецептах. Но, если сайт собирает лучшие рецепты популярных кухонь со всего мира, тогда «кухня» может стать ключевой группой категорий для целевой аудитории, либо в дополнение к «блюдам», либо заменяя их. В любом случае, так как «кухня» является ключевой для тематического сайта, показывать её первой (вместо «блюда») будет более уместно.
Тематические веб-сайты имеют отличные ключевые категории метаданных.
Организация ключевых категорий
Примеры выше относятся только к единственной группе ключевых категорий. Однако, набор товаров или услуг может охватывать несколько ключевых категорий.
Возьмём, например, одежду. Одной из ключевых групп категорий может стать деление на типы одежды, такие как «рубашки», «брюки», «обувь» и «кофты». Другой ключевой и взаимоисключающей категорией будет разделение по полу: «мужской» и «женский». Третей категорией может стать деление на обстоятельства, вроде «повседневная», «рабочая» и «торжественная». Можно конечно придумать ещё больше ключевых категорий, но остановимся пока на этом.
Тогда возникает вопрос, как лучше разместить категории и разрешить потенциальные конфликты между несколькими ключевыми категориями.
Сперва расположение всех ключевых категорий на одном уровне в верхнем меню может показаться логичным. В конце концов они же все ключевые. Тем не менее, лучше сделать наоборот. Ключевые категории лучше всего работают одна за другой, на последующих уровнях. Для лучшего понимания, давайте посмотрим на информационную архитектуру веб-сайта, представленного ниже.
Горизонтальное меню чаще всего используется для продуктов, которые предлагают сайты.
Горизонтальное навигационное меню перечисляет доступные продукты LL Bean, такие как «аксессуары для дома», «охота и рыбалка», «оборудование для улицы», «обувь» и «одежда». Однако, дизайнер сделал нечто отличное для «одежды». Одежда подразделяется на «мужскую», «женскую» и «детскую», но вместо перечня десятков типов одежды в горизонтальном меню дизайнеры решили сделать ключевые категории с меньшим весом. Пользователь просто начинает с категорий «мужское» и «женское», а затем в раскрывающемся меню может увидеть все типы одежды, что дает больше возможностей, чем одно горизонтальное меню.
Использование ключевых категорий с меньшим весам в основном навигационном меню, освобождает пространство.
Здесь возникает небольшое несоответствие в информационной архитектуре, но дизайнеры решили освободить пространство в горизонтальном меню. Такое решение является приемлемым, пока несоответствие не путает пользователей, что вряд ли произойдет в этом случае. Тем не менее, расположение категории «обувь» (которую, по понятным причинам, разделяют на мужскую и женскую) в том же горизонтальном меню – уже не такое хорошее решение.
Ключевые категории должны быть расположены одна за другой, а не одна рядом с другой.
Проблема в таком решении такая, что две ключевые категории были расположены на одном и том же уровне. Оба «Обувь – Мужская» и «Мужская – Обувь» прямые пути к одним и тем же товарам. Тем не менее, раз обе категории ключевые, пользователь в любом случае должен посмотреть через оба пути. Но так как они расположены на одном уровне, пользователь должен выбрать между ними, что размывает предположение, что обе категории ключевые. Следовательно, один из путей может быть убран, например, «Обувь – Мужская».
Дополнительные категории
Если уже есть несколько ключевых категорий, то в зависимости от количества товаров и услуг дополнительные могут не потребоваться. Если на веб-сайте есть не более десятка предметов одежды, то дизайнер может предоставить пользователям выбор, посмотреть мужскую или женскую одежду, и остановиться на этом.
Однако во многих случаях бывает обратное. Даже после того, как все ключевые категории были исчерпаны, изобилие предметов может доставлять неудобства навигации. Поэтому должны быть введены дополнительные категории, которые позволят пользователю фильтровать контент дальше.
Дополнительные категории важны для некоторых пользователей, но не для всех. Например, две дополнительные категории метаданных для «автомобилей» могут быть «количество дверей» и «тип топлива». Некоторые люди очень фанатичны по поводу типа топлива, но меньше заботятся о количестве дверей. Другие – с точностью до наоборот.
Приоритет ключевых над дополнительными категориями
Как правило, дополнительные категории должны быть показаны посетителю после того, как он прошёл через ключевые.
Однако, множество торговых сайтов, вроде сайтов одежды или электроники, перечисляет бренды (дополнительные категории) на том же уровне, что и типы продуктов (ключевые категории).
Ключевые и дополнительные категории должны находиться на разных уровнях.
Проблема в таком подходе в том, что даже если посетитель выбирает какой-либо бренд, скажем из одежды, он столкнется с сотнями или тысячами различных товаров, и ему всё равно потребуется выбрать тип одежды, чтобы ограничить поиск. Таким образом, расположение дополнительных категорий на уровне ключевых создает лишние обходные пути, усложняя выбор и захламляя навигацию.
Вместо показа множества навигационных опций одновременно с самого начала, покажите пользователям сначала несколько ключевых категорий, а затем представьте дополнительные.
Итак, в примере выше, было бы лучше убрать бренды из ключевых категорий и предоставить пользователям сначала выбирать только типы одежды. И только потом, на следующем уровне, предоставить пользователям варианты выбора бренда.
Дополнительные категории должны быть представлены только тогда, когда пользователь уже выбрал ключевую.
Динамические фильтры
Как уже было отмечено, ключевые категории должны быть представлены одна за другой на соответствующих уровнях. Все дополнительные категории лучше представить на одном уровне.
Единственное исключение, когда дополнительные категории являются взаимоисключающими, в таком случае они должны быть показаны на следующем уровне в том же меню, что и ключевые категории. Если дополнительные категории могут быть объединены, то тогда их лучше реализовать в качестве динамических фильтров.
На скриншоте ниже, отметьте как Sears показывает ключевые категории в виде навигационной цепочки или «хлебных крошек», в то время как дополнительные категории представлены в виде динамических фильтров.
Дополнительные категории, которые можно объединить, следует показывать в виде динамических фильтров.
Различие между ключевыми и дополнительными категориями можно объяснить, как следующее. Каждая категория – это фильтр доступного контента, а динамические фильтры называются динамическими, потому что они позволяют пользователям выбирать и изменять значения непрерывно. В отличие от этого, в традиционной основанной на уровнях навигационной системе, пользователь должен двигаться от одного уровня к другому, чтобы выбрать необходимое значение. Если это ключевые категории, то проблем возникнуть не должно. А вот с дополнительными категориями, ситуация отлична.
Когда пользователь ищет рубашку, множество дополнительных категорий могут иметь значение для него: «бренд», «тип воротника», «длина рукава», «ткань», «рисунок», «карманы», «скидка», «цена», «рейтинг», «популярность» и т.д. Точно понять какие именно категории его будут интересовать достаточно сложно. Кого-то не заинтересует ни одна, кого-то несколько, а кого-то все.
Вместо того, чтобы вести пользователя через все дополнительные категории, одна за другой, независимо от того, интересны ли они ему или нет, дизайнер может сделать динамические фильтры на одном уровне. Тогда пользователи смогут выбрать только категории, которые предпочтут.
С другой стороны, давайте посмотрим на сайт, показанный ниже, на котором нет явных различий между ключевыми и дополнительными категориями. Вместо этого, на нём представлены все категории в качестве динамических фильтров, включая ключевые категории.
Ключевые категории не следует представлять в качестве динамических фильтров.
Такое отсутствие различия ведет к нескольким проблемам. Во-первых, это занимает вертикальное пространство и двигает дополнительные категории вниз, требуя от пользователя чаще прокручивать вниз, чтобы менять значения.
Во-вторых, динамические фильтры известны как «тяжёлые» виджеты: они мощные, но затратные на ресурсы. Всякий раз, когда пользователь выбирает одно значение, весь перечень результатов обновляется, чтобы подойти под фильтр. Тот же результат может быть достигнут куда быстрее с помощью выбора тех же ключевых категорий из традиционного меню.
Фактически, дизайнеры Nike сделали обычное меню, позволяя нам проверить предположения и сравнить скорость и эффективность обеих моделей взаимодействия с тем же интерфейсом. (Они также предоставили возможность удалять ключевые категории из динамических фильтров. Прим. перевод.).
Ключевые категории лучше всего представлены в традиционном навигационном меню.
Взаимоисключающие категории
Динамические фильтры необходимы только если дополнительные категории можно объединить. Если дополнительные категории взаимоисключающие, тогда они должны быть представлены на следующем уровне основного навигационного меню.
На скриншоте ниже Daily Express спрашивает у пользователей ключевой вопрос на первом уровне: выбрать тему новостей, таких как «финансы», «развлечения» или «образ жизни». Затем, на главной странице выбранной секции представлен дайджест последних новостей по теме. Большинство пользователей хотят проверить три или четыре последних статьи. Для тех, кто хочет углубиться в выбранную тему, подкатегории перечислены ниже первого уровня.
Взаимоисключающие дополнительные категории лучше всего показывать на дополнительном уровне в основном навигационном меню.
Подкатегории, на показанном выше изображении, можно рассматривать как взаимоисключающие, так как развлечения обычно выделяются либо в виде книг, либо в виде фильмов, либо как ТВ-шоу и т.д. Конечно, комбинации также возможны; по книге может быть сделан фильм или театральная постановка. Но захотели бы пользователи увидеть дайджест из таких комбинаций? Если да, то имеет смысл применить динамические фильтры.
Имейте в виду, что ответ на этот вопрос будет зависеть в меньшей степени от типа элементов (предметов на сайте), чем от объема и разнообразия элементов, также, как и от специфических интересов целевой аудитории.
Например, пользователи скорее всего не будут искать рецепт завтрака, такой чтобы он был и китайским, и низкокалорийным, и рождественским. Наоборот, они будут искать завтрак, который был бы либо китайским, либо низкокалорийным, либо рождественским. Поэтому, дополнительные категории рецептов скорее всего не будут объединены в общее. Тем не менее, если на сайте тысячи рецептов, а целевая аудитория имеет достаточно специфические предпочтения, предоставление им более многочисленных динамических фильтров может принести пользу.
Большой и разнообразный объем содержимого, а также специфические интересы пользователей, могут послужить основанием для применения разнообразных динамических фильтров.
Наконец, рассмотрим третью группу категорий метаданных.
Несущественные категории
Несущественные категории – это такие категории с помощью которых нецелевой посетитель, вероятно, захочет поискать контент. Однако, такие категории вовсе не являются несущественными для общего опыта взаимодействия пользователя.
Две категории метаданных для поиска статей могут быть «количество слов» и «количество изображений». Если эти категории были реализованы как столбцы в базе данных, стратег по контенту может посмотреть значения по этим категориям и выявить, что большинство статьей слишком длинные и без картинок, что может стать причиной для множества посетителей покинуть сайт, прежде чем закончить чтение статей. Стратег по контенту в таком случае может обсудить этот вопрос с дизайнером или клиентом, что поможет улучшить контент. Тем не менее, даже если эти категории могут предоставить ценную информацию для дизайнера, пользователи вряд ли захотят искать статьи по «количеству слов» или «количеству изображений».
Вкратце, несущественные категории не должны быть видны на сайте. Они будут игнорироваться, захламлять интерфейс и могут даже смутить пользователей. Хотя, большое количество элементов может сделать несущественные категории дополнительными.
Например, «количество слов» обычно будет несущественной категорией с помощью которой можно искать статьи. Однако на сайте, показанном ниже, накопилось такое количество статей за много лет, что дизайнеры решили, что необходимо добавить длину статьи в качестве дополнительной категории для фильтрации контента.
Большой объем контента может сделать несущественные категории дополнительными.
Веб-сайты выше, с рецептами и одеждой, подходят для пояснения важности приоритетности категорий, так как обычно для них необходимо большое количество категорий метаданных. Но они не показывают одну проблему, с которой дизайнеры сталкиваются в какой-то момент, особенно при проектировании для корпорации.
Классификация корпоративных продуктов
Большинство сайтов с рецептами собирают рецепты без разбора и оставляют на дизайнера их классификацию. Но у корпораций часто бывает свой собственный внутренний способ классификации продуктов, что может привести к противоречивым требованиям.
Рассмотрим первую ключевую категорию для машин. Вы бы выбрали категория в зависимости от размера или образа жизни, со значениями такими как «малолитражка», «фургон», «спортивные машины», «седан», «лимузин» и т.д. Такие категории являются ключевыми, так как каждый тип машины учитывает частный образ жизни, что является важным почти для всех водителей машин. Например, малолитражка – маленькая, дешевая, легкая для вождения и с ней легко припарковаться в городе. Фургон имеет большой багажник и отлично подходит для семьи. Спортивные машины для совершенно другого образа жизни. И так далее.
Однако, большинство автокомпаний классифицируют свои модели по-своему. BMV, ниже, следует классификации по цифрам (1, 3, 5, 7 и т.д.).
Иногда корпоративная классификация хорошо работает.
В то время как схемы внутренней классификации могут вызвать проблемы с юзабилити, классификация BMV на самом деле делает информационную архитектуру более удобной. Несмотря на то, что такая схема является корпоративной, она достаточно хорошо известна широкой публике, и номера машин увеличиваются логически с увеличением размера машины, более или менее совпадая с распространенной классификацией на малолитражки, седаны, лимузины и т.д. В таком случае, что-либо другое помимо корпоративной классификации может скорее оттолкнуть, нежели помочь пользователю.
Следующий пример не так прост. Opel подобным образом перечисляет свои модели машин согласно своим собственным внутренним наименованиям.
Внутренняя классификация не всегда понятна внешним пользователям.
Проблема в том, что структура этих продуктовых линеек не очень ясна, и это не облегчается тем, что пользователи должны взаимодействовать со слайдером, чтобы увидеть все модели. У пользователей нет простого способа понимания, как продукты взаимосвязаны друг с другом и, следовательно, продукты невозможно отфильтровать в соответствии с предпочтениями.
Если внутренняя схема классификации не работает для пользователей, тогда широко известная внешняя должна иметь приоритет над внутренней.
Отметьте как Volkswagen (ниже) применил свой собственный путь в названии и классификации моделей машин: «Jetta», «Passat», «Touareg» и т.д. Но компания сделала приоритетной общую внешнюю классификацию над своей корпоративной. Результатом стало меню, которое легко понять, и которое позволяет пользователям сфокусироваться на том, в чем они заинтересованы.
Приоритет общей схемы классификации над корпоративной может сделать навигационное меню проще для понимания.
Конечно, клиент может не захотеть увидеть свою корпоративную классификацию на втором плане. Тем не менее, следует подробно объяснить клиенту эту необходимость.
Пояснения вариантов выбора в навигации
Структурирование навигационных вариантов выбора в соответствии с предпочтениями пользователей – важный шаг в упрощении информационной архитектуры сайта. Но если пользователи не могут понять навигационные функции в первую очередь, то даже самые продвинутые структуры будут напрасны. Поэтому уделите минуту для обдумывания, как лучше всего объяснить пользователю возможности выбора.
Показывайте пользователям столько информации, сколько им необходимо, чтобы понять свои варианты выбора. При внесении чего-либо сверх необходимого может возникнуть риск утомить пользователей, захламить интерфейс и замедлить навигацию, вплоть до отказа.
С другой стороны, не стоит им давать слишком мало информации. Если пользователям придётся угадывать куда ведут ссылки, а потом огорчаться тем, где они оказались, они в скором времени утратят доверие к интерфейсу и покинут веб-сайт.
Дизайнеры могут выбрать один из трёх методов, чтобы пояснить варианты выбора:
1. Простые названия;
2. Названия и изображения;
3. Названия, изображения и описания.
Чтобы выбрать правильный способ, оцените на сколько понятны простые названия для целевой аудитории.
Простые названия
Если названия, которые Вы используете достаточно хорошо узнаваемы, то их будет достаточно. Большие изображения и длинные описания не нужны для пояснения что такое «джинсы», «шорты», «рубашки» и «пиджаки».
Простых обозначений достаточно для привычных вещей.
Желательно, чтобы названия были как можно более краткими, в то же время, краткость не должна быть достигнута за счет ясности. Акронимы и жаргонизмы, такие как UX и BMI (body mass index), могут работать только в том случае, если они знакомы и удобны для целевой аудитории.
Впрочем, иногда термин сам по себе может быть ясным, но контекст в котором он появляется делает его неоднозначным. Множество сайтов крупных организаций содержат постоянную горизонтальную навигацию, которая указывает на аспекты основной деятельности организации, а также контекстно-зависимую вертикальную навигацию, которая показывает подразделы. Такой подход может привести к повторяющимся обозначениям. The University of Bath (представленный ниже) включает обозначение «Исследования» («Research») в общее горизонтальное навигационное меню вверху и в вертикальном подменю слева.
Крупные организации с большим количеством подразделов склонны дублировать названия.
Это может немного смутить пользователей, однако тщательный дизайн может помочь избежать двусмысленности. На скриншоте сверху, заголовок меню «Рассмотреть отдел» («Explore the Department») — хороший намёк на то, что обозначение «Исследования» относится к отделу, а не к целому университету. На всякий случай, мы могли бы удлинить обозначение «О нас», скажем, «Об этом отделе».
Другой вариант показать контекст названий с помощью цифр, обозначающих сколько предметов находится в данной категории.
В некоторых меню, количество предметов в категории отображается рядом с названием.
Такие цифры часто включаются в динамические фильтры.
В множестве интерфейсов с динамическими фильтрами, количество предметов в категории отображается вместе с названием.
Хотя большинству пользователей нравится видеть эти цифры, нужно внимательно подойти к тому, когда их нужно действительно показывать. Например, угадать сколько контента содержится на сайте, посмотрев на главную страницу, достаточно трудно. Поэтому, показывая ясно сколько контента содержит сайт, Вы можете завоевать пользователя, так как он может подумать: «Наверняка на сайте найдется что-то и для меня».
Количественная оценка объема содержания сайта может привлечь посетителя.
Конечно, Вы бы вероятно не захотели раскрывать эту цифру, если на Вашем веб-сайте пока недостаточно контента.
Подобным образом, когда пользователь смотрит категории и заинтересован в определённой теме, он бы хотел изучить соответствующую категорию, даже если она содержит меньше объектов, чем другая менее значимая для него. Возможно даже отображение чисел в таком случае может замедлить поиск и захламить интерфейс.
В некоторых ситуациях, статистика может препятствовать пользователям.
Такое же возможно и для динамических фильтров. Будут ли пользователи выбирать категорию, основываясь на количестве объектов, которые она содержит? Если да, то отображение чисел имеет место быть. Если нет, лучше сделать значения серыми или удалить вообще.
В любом случае, после того как пользователь уже сделал выбор, отображение количества объектов в категории, или после применения динамических фильтров, может дать полезную информацию пользователю.
Иконки – другой тип элементов, которые иногда добавляются к обозначениям. Они могут стать полезным дополнением, если они хорошо сделаны и легко узнаваемы. Не обязательно, что они будут объяснять пользователю возможности выбора, тем не менее иконки позволят проще обрабатывать и разделять варианты выбора. На скриншоте ниже, я удалил иконки из пунктов меню. Отметьте, что названий всё ещё достаточно, чтобы объяснить альтернативы. Все знают, что «машины», «мотоциклы» и «грузовики» значат.
Самих по себе названий часто достаточно, но требуется немного больше времени для обработки.
Однако, добавление иконок рядом с названиями позволит пользователям проще распознавать и разделять варианты выбора.
Добавление иконок рядом с названиями позволит пользователям проще распознавать и разделять варианты выбора.
Иконки без названий, могут привести к путанице. Даже если значок знаком, пользователь может быть не уверен в том, что он означает в определённом контексте.
Названия и изображения
Обозначения и иконки хорошо работают с легкоузнаваемыми объектами. Для менее же распространённых, необходимы изображения. Рассмотрим названия брэндов. На скриншоте ниже, модели машин представлены как обычный текст в меню.
Названия брэндов требуют больше, чем просто названия для понимания.
На самом деле я не знаю, что значат «Tribeca» и «Legacy». Поэтому названий недостаточно, чтобы мне решить какой продукт посмотреть. Названия с изображениями, как показано ниже, лучшее решение.
Названия и изображения – лучший способ объяснить незнакомые термины
Когда лучше использовать изображения или иконки в навигационном меню – это интересный вопрос. Очевидно, для объяснения весьма специфичного объекта, например, «13-дюймового Macbook Pro» или «Samsung Galaxy Note 3», ничего кроме соответствующего изображения не поможет.
Объяснить категорию продукта не так то просто. В некоторых меню, категории объясняются с помощью иконок.
В некоторых меню используются иконки для пояснения категорий.
В других меню, такие же категории поясняются с помощью изображений соответствующих продуктов в категориях.
В некоторых меню категории поясняются с помощью изображений соответствующих продуктов в категориях.
Для категорий продуктов, иконки более подходят нежели изображения. Меню будет выглядеть более профессионально с хорошо сделанными иконками, чем с реалистичными изображениями продуктов.
Более того, использование изображений продукта из соответствующей категории может подсознательно вызвать вопросы среди пользователей. «Почему именно данный продукт представляет эту категорию?», «Это лучшее, что у них есть?», «Связан ли набор продуктов в категории напрямую с этим типом предмета?», «Если мне не нужен такой предмет, тогда этот сайт не для меня?». Эти опасения усилятся, если пользователи увидят первые объекты в категории, схожие с изображением в меню. Иконка же, наоборот, просто передает информацию, что данная категория содержит определённый вид продуктов, ничего больше, ничего меньше.
Тем не менее, с иконками такое работает, если они соответствуют определённым стандартам. Иконка может легко показаться неуместной, если она нарисована плохо. И если она не достаточно узнаваема, она может легко смутить пользователей. Поэтому, не смотря на то, что иконки больше подходят к категориям продуктов, если Вы не уверены, что сможете сделать их профессионально и узнаваемо, лучше убрать их вообще.
Названия, изображения и описания
Иногда даже названий и изображений недостаточно, чтобы пояснить категории продуктов. Поставщики услуг с комплексными решениями, такие как банки, страховые компании и поставщики интернет-услуг, часто называют свои услуги, например, «50 плюс» или «Интернет на ходу». Большого изображения супружеской пары, разговаривающей с брокером или девушки, разговаривающей по смартфону, может быть недостаточно для обозначения оказываемых услуг. Для таких продуктов наиболее полезным будет описание в пару строчек вместе с названием и изображением.
Комплексным продуктам необходимы названия, изображения и описания, чтобы быть понятными.
Заголовки и названия статей – это отдельный тип обозначений, которым может понадобится изображение и описание, а может и нет.
Многие авторы используют говорящие заголовки с ключевой информацией в них, и чтобы они были как можно более короткими.
Общая рекомендация: делать заголовки как можно более короткими и говорящими сами за себя.
Заголовки выше короткие и по существу, в то же время такой стиль написания имеет свои риски и не подходит всем сайтам.
Первый вопрос, где и как писать описания. Заголовки BBC чаще всё-таки сопровождаются описаниями. Ниже показаны заголовки с описаниями, которые, как Вы можете отметить, просто состоят из большего количества слов, но не несут в себе новой информации.
Описания не должны содержать информацию, которую уже несёт в себе заголовок.
Если заголовки уже несут в себе ключевую информацию, как показано выше, то описания не нужны. Возможно даже, это замедлит пользователей из-за прочтения описания, хотя они могли бы точно также ориентироваться в статьях после прочтения заголовков.
Тем не менее, показ заголовков в одиночку или написание заголовком в таком стиле не всегда лучший вариант или даже целесообразный. Если статья является всего лишь коротким репортажем о событии, тогда заголовки как в BBC – хороший выбор. Но если статья является более глубокой, чем заголовок, то изображение и описание могут стать более эффективными и вовлекающими.
Заголовок на скриншоте ниже больше броский, чем информативный, а вся ключевая информация представлена в паре строк ниже. Также было добавлено изображение, чтобы задать тон статье.
Названия, изображения и описания зачастую лучший способ, чтобы дать углубленное пояснение к статье.
Понять о чём данная статья не трудно из сниппета (краткого описания). Более того, использование захватывающего внимание заголовка и описания для пояснения статьи, и изображения для задания тона статье, предоставляет автору больше пространства не только для информирования пользователя, но и для передачи проблематики статьи.
Наконец, примите во внимание совет, который часто дают при написании заголовков, заключающийся в том, чтобы заголовок был понятен вне контекста сайта. В конце концов, заголовок может появиться в результатах поисковых запросов, в социальных медиа и в контексте других веб-сайтов. Некоторые авторы даже придумывают формулы для этой цели.
Многие авторы пытаются писать заголовки так, чтобы они были понятны вне контекста оригинального веб-сайта.
Только будьте осторожны, чтобы не добавить лишней информации при добавлении контекста к заголовку.
Заголовок, показанный выше «Avoid Multi-Column Layouts», не обеспечивает достаточного контекста, так как сайт о веб-дизайне, а макеты с несколькими колонками (multi-column layouts) могут играть роль на домашних страницах, меню, статьях и т.п., не только в формах. Поэтому, «Form Field Usability» напрямую добавляет контекст к изначальному заголовку. Хотя, писать для внешнего контекста не всегда необходимо, так как другие люди, которые будут ссылаться на заголовок, будут стремиться обеспечить свой собственный контекст.
Разработчики поисковых систем знают, что пользователи будут обходить их стороной, если результаты поисковых запросов не будут соответствовать их ожиданиям. Поэтому они постоянно работают над повышением актуальности и успешности своих результатов, будь то расширение сниппетов, изображений или превью или с помощью улучшения своих алгоритмов. Точно также, если заголовок появился в «рекомендуемом к прочтению» для другой статьи, то статья сама по себе даст необходимый контекст.
Подводим итоги
Информационная архитектура, т.е. структура и обозначение содержимого – это основа удобной навигации. Дизайнеры могут эффективно упростить информационную архитектуру веб-сайта, структурируя контент путем, который естественно сужает и дополняет возможности навигации целевой аудитории, также как объясняет варианты выбора, минимизируя умственную нагрузку пользователей.
Рекомендации, данные в этой статье можно разделить на два следующих списка, поделенных на «структурирование контента» и «названия элементов».
Структурирование контента
1. Соберите и систематизируйте метаданные о типах элементов, по которым пользователи должны совершать навигацию.
2. Сгруппируйте категории метаданных на ключевые, дополнительные и несущественные. Ключевые категории важны всем целевым пользователям, дополнительные – для некоторых, а несущественные – для нецелевых пользователей.
3. Представьте только одну группу ключевых категорий на первом уровне.
4. Если элементы на следующем уровне не превышают определённое количество, то последующие категории не нужны. В противном случае, покажите следующие ключевые категории одну за другой, на каждом последующем уровне.
5. После исчерпания всех ключевых категорий, покажите страницу на которой будут показаны все предметы, соответствующие выбранным ключевым категориям.
6. Если оставшихся элементов всё равно слишком много, тогда представьте все дополнительные категории на одном уровне.
7. Если дополнительные категории являются взаимоисключающими, введите их на дополнительном уровне к ключевым. Если дополнительные категории можно объединить, представьте их в виде динамических фильтров.
Названия элементов
• Если обозначение элемента достаточно известно, то его достаточного самого по себе. Сделайте обозначения как можно короче, без потери ясности. Покажите общее количество элементов на главной странице и на странице категорий, но не между. Также рассмотрите возможность добавить иконки к обозначениям, чтобы упростить процесс обработки и выбора между альтернативами.
• Если обозначений недостаточно, рассмотрите возможность добавления изображений. Используйте иконки, чтобы обозначить категории, но только в том случае, если иконки хорошо сделаны и узнаваемы. В противном случае, лучше используйте изображения.
• Для комплексных услуг и продуктов, рассмотрите возможность добавления изображения и описания к обозначениям. Описания должны обеспечивать действительно новую информацию, а не просто перефразировать заголовки. Также, будьте осторожны, при добавлении контекста в заголовок, чтобы не добавить избыточной информации.
После того, как Вы упростили архитектуру, пользователям будет предоставлен выбор взаимодействия для собственного удовлетворения. Поэтому, Вы всегда должны разрабатывать навигационное меню, подходящее под пользовательский выбор и создающее комфорт взаимодействия. Процесс дизайна навигационного меню будет объяснён во второй части этой серии.
