{"id":13456,"url":"\/distributions\/13456\/click?bit=1&hash=6bf95d5850d39a632d71d9ebb94b8a4e644bc6a23b4e4c2644b39e47003b100d","title":"80 \u0442\u044b\u0441\u044f\u0447 \u0447\u0435\u043b\u043e\u0432\u0435\u043a \u0438\u0441\u043a\u0430\u043b\u0438 \u043f\u0430\u0440\u0443 \u0434\u044b\u0440\u044f\u0432\u043e\u043c\u0443 \u043d\u043e\u0441\u043a\u0443 \u0441\u043f\u0435\u0446\u0430\u0433\u0435\u043d\u0442\u0430","buttonText":"\u0427\u0442\u043e\u043e\u043e?","imageUuid":"a05ce1a7-0771-5520-b8cb-45c9bdd65351","isPaidAndBannersEnabled":false}
Дизайн
UX-Марафон

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

Предлагаем вашему вниманию вторую часть лекции Алексея Бородкина, которая открыла UX-Марафон #22. В предыдущей публикации Алексей на примере проектирования книжного интернет-магазина рассмотрел первую из трёх составляющих информационной архитектуры – навигационную структуру цифрового продукта. Сегодня речь пойдёт о двух других гранях этого понятия.

Напоминаем, что полностью посмотреть доклад Алексея Бородкина можно в бесплатном доступе на нашем YouTube-канале. А уже 9 декабря ведущие специалисты Яндекса, Сбера, Тинькофф, Вконтакте, Мой Склад, Solit Clouds расскажут о своём опыте проектирования сложных систем на онлайн-конференции UX-Марафон #26.

Грань 2. Описание структуры подачи контента

Итак, пойдём дальше в нашем примере с интернет-магазином. Допустим, мы приступаем к проработке каталога. И тут мы осознаём, что в нашем интернет-магазине будут продаваться самые разные книги. Вот, например, первые 10 позиций, взятые из топа на Озоне. Трудно представить, по какому принципу вообще возможно как-то систематизировать все эти совершенно непохожие издания.

Есть несколько путей решения этой проблемы. Первый – сделать всё самому. Однако в этом случае вы неизбежно подменяете логику пользователя собственной логикой. Поэтому лучше воспользоваться карточной сортировкой.

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

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

Существует ещё и обратная карточная сортировка, когда пользователю предлагают найти книгу в готовой структуре. Но этот способ используется исключительно для проверки уже существующих каталогов.

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

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

Грань 3. Описание структуры данных в их взаимосвязи

Помимо навигационной структуры, каталога и интерфейсов вам необходимо будет спроектировать админку – панель управления сайтом, у которой будут собственные пользователи: администраторы или контент-редакторы.

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

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

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

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

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

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

  • проработка навигационной структуры вашего продукта;
  • проработка структуры упаковки контента (каталог, разделы сайта);
  • описание того, какие данные заложены в вашу систему, как они между собой взаимосвязаны и как ими управлять.

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

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

***

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

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