{"id":13505,"url":"\/distributions\/13505\/click?bit=1&hash=ca3734639136826288c9056e5c8fa03a05e87c4060ae84df200f2c90f5262470","title":"\u0412\u044b \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a? \u0410 \u043f\u043e\u043d\u0438\u043c\u0430\u0435\u0442\u0435 \u0447\u0442\u043e-\u0442\u043e \u0432 \u0438\u0441\u043a\u0443\u0441\u0441\u0442\u0432\u0435 \u043a\u043e\u0434\u0430?","buttonText":"\u041f\u0440\u043e\u0432\u0435\u0440\u0438\u0442\u044c","imageUuid":"f5f0e11f-fefd-52f5-8712-82164a59b7ce","isPaidAndBannersEnabled":false}
Дизайн
UX-Марафон

Основы информационной архитектуры от Алексея Бородкина

Эта фундаментальная лекция открыла UX-Марафон #22, состоявшийся в январе текущего года и посвящённый вопросам информационной архитектуры. Основатель Гильдии вольных проектировщиков и один из популярнейших спикеров нашей конференции Алексей Бородкин рассказал, что такое информационная архитектура, как она влияет на UX и на успешность продукта, и почему так важно уделять ей должное внимание.

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

Грань 1. Навигационная структура цифрового продукта

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

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

Например, первая группа – это люди, которые приходят в интернет-магазин за конкретной книгой. Они знают, чего хотят, и действуют по принципу «пришёл, увидел, победил».

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

Ещё одна группа – «всеядные» читатели, которым надо дать покопаться в каталогах и выбрать что-то по душе. Наконец, особняком будет стоять группа бизнесменов – издатели, перекупщики. У них свои задачи, которые не совпадают с задачами других клиентов, но они также являются важной частью целевой аудитории.

В норме подобных групп для сложного продукта должно быть от четырёх до шести.

Поскольку работать с огромным количеством разных пользователей неудобно, для каждого сегмента придумывается один персонаж (персона), который является для нас олицетворением, «послом» от этого сегмента и несёт в себе все самые значимые его характеристики, начиная от цели и заканчивая образом поведения:

Дальше мы задействуем ещё один очень полезный инструмент, который идеально работает в сочетании с методом персонажей – Customer Journey Map (CJM) или, применительно к цифровому продукту – User Jorney Map.

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

Любой CJM «вертится» вокруг ответа на три главных вопроса:

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

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

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

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

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

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

***

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

Если интересно узнать, как продукты, ориентированные на пользователей, создаются в Яндексе, Сбере, Тинькофф, Вконтакте и других компаниях – приходите 9 декабря на онлайн-конференцию UX-Марафон #26 «Проектирование сложных систем».

0
Комментарии
Читать все 0 комментариев
null