- Все статьи цикла:
- Информационная архитектура: краткий экскурс (вы здесь)
- Информационная архитектура: пример и типизация
- Информационная архитектура: модели (coming soon)
- Информационная архитектура: сущности (coming soon)
Это короткая статья не претендует на полное раскрытие термина, ибо он настолько глубок, что даже для базового его изложения потребуется не один пост — или один, но реально огромный. А так как изначально статья публиковалась на Яндекс.Дзене (который не прощает лонгридов), то здесь я опишу только самые фундаментальные принципы. Можете считать это «трамплином» для погружения в пучину Information Architecture.
Что такое IA
Очень ёмко об информационной архитектуре высказался Алексей Бородкин, основатель Гильдии Вольных Проектировщиков:
Это описание связи всего со всем!
И во многом он прав. Во время этапа проработки IA формируется информационная структура продукта, выявляются взаимосвязи между всеми его частями, определяется их важность и содержимое.
Грамотная информационная архитектура упрощает поддержку и развитие продукта, улучшает UX:
- программисты не матерят своих предшественников (или себя) за неудобные для масштабирования роутинг и базы данных;
- контент-менеджеры и администраторы больше не льют кровавые слёзы при работе с внутренней частью продукта;
- пользователи легко и непринуждённо находят то, что им нужно и попадают именно туда, куда хотели;
- сеошники и поисковые системы влюбляются в ваш сайт и не хотят оттуда никуда уходить.
Притом, как это часто случается в IT, каждый специалист вкладывает немного собственного смысла в этот термин, поэтому любая формулировка рискует оказаться недостаточно точной. И всё же я постарался сформулировать максимально общее определение информационной архитектуре:
Это совокупность данных об информационной структуре цифрового продукта, способствующая его правильной работе, выполнению задач и интуитивному доступу к содержимому.
Стало не сильно понятней, да? Вот так, сходу, всё это может показаться немного запутанным или сложным. Поэтому давайте на каком-нибудь очень простом и понятном примере пройдёмся по базовым этапам создания IA. Пусть это будет абстрактный интернет-магазин одежды.
Этапы создания IA
Важно понимать, что каждый опытный архитектор выполняет эту работу немного по-своему. В формате этой «вводной» статьи я смогу рассказать только о ключевых моментах, основных вехах.
Подготовка
Работа над информационной архитектурой начинается сильно позже старта проектирования. Сперва определяется концепция, суть продукта. Нам нужен базис, от которого мы уже начнём выстраивать IA.
Мы должны как минимум очертить высокоуровневые границы проекта, сформировать базовое понимание его функциональности. И только на этом этапе приступать к информационному проектированию.
В нашем случае базис относительно простой: есть интернет-магазин, есть товары, категории и пользователи. Углубляться не станем, а то всё-таки скатимся к лонгриду.
Декомпозиция
На этом шаге мы разбираем проект на отдельные информационные сущности. Каждая такая сущность обладает определёнными свойствами. Некоторые сущности могут быть вложенными (каталог и товар, например), некоторые — независимыми.
Итак, пусть в нашем примере будет только 5 сущностей:
- Страница (статические страницы, содержащие какую-то информацию; например, страницы «О компании», «Доставка и оплата»).
- Товар (да, обычный товар с описанием, фоточками, ценой и тп).
- Каталог (внезапно, но каталог — это тоже сущность; у него есть свои свойства, вроде параметров поиска или уровня вложенности).
- Корзина (которая обладает динамическими свойствами: вложенные товары и их количество, скидки, даже связь с конкретным пользователем).
- Пользователь (тут всё понятно: как минимум, у пользователя есть регистрационные данные, адрес доставки и платёжные реквизиты).
Конечно, даже в самом простом e-commerce этих сущностей больше, а их свойства разнообразнее. Однако мы помним, что это пример, да? Для простоты мы в дальнейшем даже не будем детально разбирать почти ничего, кроме самих «товаров».
На этом и последующих этапах присутствуют некоторые пересечения с дизайном данных, это не страшно и не противоречит концепции информационной архитектуры. Если проектировщик/архитектор хороший, он совмещает оба направления, экономя ресурсы компании.
Классификация
Теперь надо классифицировать получившиеся сущности, но не только их. Для грамотного составления архитектуры, нам потребуется классифицировать ещё и возможные операции с этими сущностями.
A. Классификация пользовательских потребностей (задач) в разрезе информационной архитектуры опирается, как правило, на результаты пользовательских же исследований. Мы должны понимать, что действительно нужно нашим потенциальным покупателям. Исходя из этой информации, мы выясним, как именно следует связать наши сущности как они будут друг к другу относиться.
Для нашего примера классификация задач пользователя будет очень простой:
- Найти товары (с помощью поиска, фильтрации и сортировки).
- Сравнить товары (выбрать наиболее подходящий вариант).
- Почитать про товары (ознакомиться с характеристиками).
- Купить товары (положить в корзину, оплатить и ждать доставку).
Как видите, все действия напрямую связаны с товарами, и опосредованно — с остальными сущностями (например, поиск товара осуществляется в каталоге, а покупка — в корзине).
На этом шаге мы также определяем все возможные варианты и способы манипуляции с нашими сущностями: определяем, как будет осуществляться поиск, по каким параметрам мы будем сортировать товары и так далее.
B. Классификация информационных сущностей — ещё один обязательный этап. Вся информация, которую видит пользователь, должна быть структурирована. Страницы должны объединяться в разделы, товары — в категории. И те, и другие должны быть доступны для поиска, а последние — ещё и для сортировки. У товаров могут быть общие свойства, вроде скрытых от глаз пользователя «тегов/меток» или доступных для просмотра «размеров».
На этапе классификации сущностей мы решаем, по какому принципу они будут объединяться и как пользователю будет удобнее с ними обращаться. Попутно не забываем и про администраторов, которым тоже нужно упростить работу.
В нашем примере добавляем три таксономии и одно общее свойство:
- Категория (иерархическая таксономия сущности «товар»).
- Метка (не-иерархическая таксономия сущности «товар»).
- Размер (не-иерархическая таксономия сущности «товар»).
- Цвет (общее свойство для всех экземпляров сущности «товар»).
Таксономии состоят из терминов. Например, таксономия «Размер» содержит несколько терминов: «XXL», «XL», «L», «M», «S», «XS».
Иерархические таксономии могут быть вложенными: например, категория может иметь подкатегорию (зимняя одежда -> пуховики). А вот у метки, например, родительского термина быть не может.
Некоторые архитекторы считают таксономии за отдельные сущности, однако мне такой подход не нравится, я предпочитаю отделять одно от другого. Вот «термин» таксономии вполне можно иногда посчитать за сущность, ибо порой термины обрастают таким количеством свойств, что сами по себе начинают претендовать на роль серьёзной информационной составляющей.
Выявление связей
На самом деле, этот этап (и следующий тоже) часто параллелятся с предыдущим, но излагать и воспринимать их удобнее именно так. Просто имейте в виду, что это не всегда прям последовательные шаги.
Итак, мы разобрались, что у нас за сущности и таксономии. Теперь нужно понять, как они будут между собой связаны. Связи сущностей могут быть совершенно разными. Если копнуть глубоко, то неподготовленный читатель слегка ошалеет от всех этих «от одного ко многим», «от многих ко многим» и тп. Мы рассмотрим только простые варианты, когда связи являются либо «плоскими», либо «иерархическими».
Плоские связи в нашем случае — это связь терминов таксономии «метки» между собой. У них нет родителей, они «равны». Или связь товаров с одинаковыми «метками» — она тоже плоская. Кстати, связь самого товара с меткой — тоже плоская.
Иерархическая связь, например, у терминов таксономии «категории» — они почти всегда вложенные. Также иерархическая связь будет между сущностями «каталог» и «товар», так как первый всегда включает в себя несколько товаров. Если пойти дальше, то в игру вступают термины таксономии и у нас получается целая цепочка связей: каталог -> категория -> товар.
Иерархия сущностей — вообще отдельная песня. У хорошего архитектора почти все сущности в проекте делится на высоко-, средне- и низкоуровневые.
Фиксация свойств
Во время всей работы над информационной архитектурой мы всё время попутно выясняли, какие именно свойства будут у наших сущностей. Пришло время их зафиксировать.
Мы знаем, что у товаров есть как минимум 10 свойств:
- Идентификатор (внутренний, в базе данных, он есть у каждой сущности и термина таксономии).
- Артикул (внешний, для обмена данными, например, с системой складского учёта).
- Название.
- Описание.
- Основное изображение (используется в карточке товара в каталоге).
- Дополнительные изображения (используются в галерее изображений на странице товара).
- Цвет (общее свойство для всех товаров; оно не «сквозное», как метки и категории, а может быть уникальным для каждого товара — например, цвет «синий с белым узором»).
- Размер (прикреплённый термин таксономии).
- Категория (прикреплённый термин таксономии)
- Метки (несколько терминов таксономии, на основе которых будут показываться «похожие» товары).
При этом мы знаем, что свойства 8 и 9 являются «ссылками» на конкретный термин таксономии, а десятое свойство — даже на несколько таких терминов.
Таким образом, мы составили информационную модельку нашего товара. Мы молодцы.
Схематизация
Составление предметных и навигационных схем продукта. Самый последний и самый сложный этап. Причём его сложность чаще не в каких-то особенных нотациях или технических трудностях. Его главная сложность — в психологическом факторе. Я видел, как талантливые информационные архитекторы сводили на нет результаты всей своей работы из-за небрежного финального оформления.
Причина тут простая: в голове у архитектора картинка уже сложилась. Переносить её на бумагу (пусть и цифровую) кажется второстепенной задачей. Гештальт закрыт, мозг получил свою дозу дофамина.
Вот только без грамотного отчуждения практически любые знания бесполезны. Всё, что получилось выяснить, сопоставить и придумать во время работы над информационной архитектурой, должно быть зафиксировано в документации. В случае с IA эта документация состоит, по большей части из разного рода схем. Здесь и перечень/описание сущностей и их свойств, здесь взаимосвязи, задачи, операции и так далее. Самые крутые даже описывают предполагаемую программную реализацию, миксуя информационную архитектуру с дизайном данных.
Об артефактах информационного проектирования можно написать не одну статью. И, возможно, я это ещё сделаю.
Напоследок
О сущностях, типах свойств и связей можно рассказывать очень долго. Как и об информационных моделях, например. Возможно, я в следующих статьях немного расскажу об этом — если вам интересно, пишите в комментариях.
Если тема вас заинтересовала — то вот тут я привожу реальный пример и рассказываю о типизации.
- Все статьи цикла:
- Информационная архитектура: краткий экскурс (вы здесь)
- Информационная архитектура: пример и типизация
- Информационная архитектура: модели (coming soon)
- Информационная архитектура: сущности (coming soon)
