- Все статьи цикла:
- Информационная архитектура: краткий экскурс
- Информационная архитектура: пример и типизация
- Информационная архитектура: сущности (теория)
- Информационная архитектура: сущности (практика, vol.1) (вы здесь)
- Информационная архитектура: сущности (практика, vol.2)
- Информационная архитектура: модели (coming soon)
- Информационная архитектура: практические советы (coming soon)
В предыдущей статье цикла мы разобрались, что такое информационные сущности, какие бывают типы свойств и базовые связи, прошлись по таксономиям и классификациям. Теперь давайте приступим к более практической части.
1. Небольшое вступление
На самом деле, работу над информационной архитектурой не всегда можно унифицировать, загнать в стандарты и фиксированные этапы. Иногда вы будете что-то упускать и потом возвращаться, это нормально. А часто, напротив, какие-то ответы уже есть в проектной документации — и тогда нужно просто собрать всё в одном месте и раскрасить оставшиеся «белые пятна».
Рассматривайте шаги, описанные ниже, исключительно как советы опытного архитектора, и ни в коем случае не как чёткие инструкции, которым надо слепо следовать. Более того, в реальных продуктах я сам не всегда всё это делаю — просто потому что не всегда в этом есть необходимость.
2. Подготовка: контекст и границы
Многие советы из этого раздела так или иначе перекликаются с обычной работой над продуктом (формирование границ, фиксация метрик и прочее). Если у вас уже есть эти данные, прекрасно, переиспользуйте их. Если же нет, то это может стать неплохим поводом подсветить слабые места продуктового подхода.
2.1. Цель продукта
Начните с формулировки основной пользовательской ценности и трёх–пяти задач, ради которых продукт вообще существует. Например: «заказать доставку еды за 3 клика», «найти нужную деталь по артикулу», «сравнить тарифы по параметрам».
В сложных продуктах может быть сильно больше 3-5 ключевых задач. В этом случае рекомендую декомпозировать его на логические или функциональные компоненты — и в каждом из них уже выводить свои цели и задачи.
Для каждой задачи задайте измеримые KPI: «среднее время до результата (time‑to‑task)», «конверсия в целевое действие», «доля успешных сценариев» и подобные.
2.2. Границы домена
Составьте карту предметной области: какие объекты и операции в неё входят, а какие находятся за её пределами. Например, для маркетплейса внутрь попадают товары, продавцы, категории и заказы, а расчёт комиссий или логистика могут быть вынесены в соседние сервисы. Это защитит команду от размывания фокуса и неконтролируемого расширения требований.
2.3. Источник истины
Определите, где хранятся все артефакты ИА: таблицы сущностей, словари терминов, фасеты, схемы связей и тд. Лучше всего, если это будет ваша внутренняя вики, типа Confluence. Для диаграмм и визуальных схем можете использовать draw.io (благо, он встраивается почти куда угодно) или FigJam.
Важно, чтобы был один актуальный источник, а не десяток несвязанных и противоречивых документов.
Назначьте владельцев этих артефактов и регламент обновления: кто, как часто и по какому триггеру правит данные, кому сообщается об изменениях.
2.4. Согласование терминологии
Создайте единый глоссарий терминов, где каждое понятие имеет согласованное определение. Например: в интерфейсе, в аналитике и в БД термин «пользователь» должен значить одно и то же, а не три разных понятия: аккаунт, клиент и автор. Я встречал системы, где одна и та же информационная сущность в одном месте называлась «пользователь», в другом «клиент», а в третьем «посетитель». Не надо так.
Хорошо организованный глоссарий устраняет двусмысленности и предотвращает непонимание между аналитиками, дизайнерами и разработчиками.
3. Декомпозиция: перечень сущностей
После того как определены контекст и границы продукта, наступает этап декомпозиции — разбиения системы на отдельные сущности. На этом шаге мы превращаем абстрактные понятия («контент», «пользователи», «данные») в конкретные элементы модели, с которыми можно работать, описывать их свойства и связи.
Цель здесь простая: увидеть полную картину того, из чего состоит продукт и как эти части взаимодействуют между собой.
3.1. Определение типов
Пройдитесь по всем сценариям вашего продукта и выпишите устойчивые типы информации: «товар», «категория», «метка/тег», «пользователь», «заказ», «корзина», «страница» и тп. Добавьте сюда вспомогательные и производные сущности, которые не видны пользователю напрямую, но обеспечивают работу системы — например, «транзакция», «сессия», «ревизия».
Скорее всего, на этом этапе вы упустите какие-то объекты, ничего страшного. Как я уже говорил, работа над IA — не всегда строго последовательный процесс. Вернётесь, как найдёте ошибку.
3.2. Описание сущности
Для каждой сущности кратко опишите:
- роль (что делает эта сущность, зачем она нужна);
- жизненный цикл (от создания до удаления или архивации);
- точки появления в интерфейсе (можно прям названия экранов);
- обязательные операции (создать/редактировать/найти/связать).
Тут важно не уходить в дебри и не погружаться в детальное проектирование. Вот вам пара простых примеров:
Товар
Роль: бизнес-сущность, описывает продаваемую единицу ассортимента и используется в каталоге, карточке товара и отчётности.
Жизненный цикл: создаётся продавцом или контент-менеджером, редактируется при обновлении данных, архивируется при снятии с продажи.
Точки появления: каталог, результаты поиска, карточка товара, блоки рекомендаций.
Операции: создать, редактировать, связать с категорией и тегами, добавить в акцию или архивировать.
Пользователь
Роль: системная сущность, представляет зарегистрированного клиента или участника системы.
Жизненный цикл: создаётся автоматически при регистрации или импорте из CRM, обновляется при изменении профиля, может быть деактивирован или удалён.
Точки появления: личный кабинет, заказы, отзывы, админ-панель.
Операции: регистрация, авторизация, редактирование профиля, привязка к заказам или организациям.
3.3. Проверка на дубликаты
Проверьте, нет ли дублирующих или пересекающихся сущностей: если у вас есть и «автор», и «пользователь», возможно, это одно и то же с разными контекстами. Тогда их лучше объединить в одну сущность и добавить поле «роль» или «тип».
3.4. Закрепление ответственных
Для сложных систем составьте матрицу принадлежности: кто владелец данных по каждой сущности (продукт, контент, аналитика), где они хранятся и как обновляются. Опять же, не уходите в детали, здесь важно оставаться на высоком уровне абстракции.
Вот простенький пример такой матрицы для e-com:
| Сущность | Владелец | Хранилище | Канал обновления | Комментарий |
|---|---|---|---|---|
| Товар | Продакт-менеджер, Контент-отдел | CMS | Импорт из ERP, ручное редактирование | Данные синхронизируются ежедневно |
| Категория | Контент-отдел | CMS | Ручное обновление, ревью раз в квартал | Согласование с SEO и маркетингом |
| Пользователь | Аналитика | CRM | Регистрация, API | Обновление при каждом входе |
| Заказ | Финансы | ERP | Автоматическая синхронизация | Источник для отчётности |
| Тег | Контент-отдел | CMS | Ручное добавление, периодическая чистка | Проверка дубликатов перед публикацией |
Такая таблица помогает выстроить процессы и избежать ситуаций, когда разные отделы изменяют одни и те же сущности без синхронизации.
3.5. Выработка метрик
Дополнительно укажите метрики для каждой сущности — показатели того, что она используется и актуальна. Вот несколько примеров:
Доля заполненных полей — процент карточек, где заполнены все обязательные атрибуты (например, описание, фото, цена, категория).
Частота обращений — сколько раз сущность запрашивается пользователями или системами в сутки/неделю (например, просмотры карточек товаров или загрузка профилей).
Связность — среднее количество связей с другими сущностями (например, число тегов на статью, товаров в категории).
Актуальность данных — доля сущностей, обновлённых за последние N дней.
Ошибки и дубли — количество некорректных или дублирующих записей в системе.
Использование в сценариях — сколько продуктовых сценариев или отчётов опираются на эту сущность.
Эти показатели помогут оценивать зрелость и здоровье информационной архитектуры, выявлять запущенные участки и планировать развитие модели данных.
4. Классификация: таксономии, уровни и операции
После того как сущности выделены и описаны, важно понять, как они группируются и взаимодействуют в структуре продукта. Этот этап превращает «список объектов» в осмысленную систему: мы определяем, какие сущности являются базовыми разделами, какие служат фильтрами или связками, и как пользователь перемещается между ними.
Классификация помогает превратить набор данных в удобную навигацию, а архитектуру — в понятную карту продукта.
4.1. Типы таксономий
Разведите иерархические (категории, разделы, рубрики) и плоские (теги, темы, ключевые слова) таксономии. Определите, какие сущности формируют структуру навигации, а какие служат только для связей или фильтрации.
Пример, по традиции, из e-com:
Категории формируют иерархическое дерево меню, которое задаёт маршрутизацию и навигацию: «Одежда» → «Женская» → «Блузки».
Теги «скидка», «новинка», «распродажа» или «эксклюзив» применяются как плоские фильтры — независимые признаки, не влияющие на структуру меню, но позволяющие пользователю собирать нужные срезы данных.
В результате одна и та же карточка товара может одновременно находиться в нескольких категориях и иметь множество тегов, отражающих её свойства или состояние.
4.2. Уровни сущностей
Назначьте уровень сущности — высокий, средний или низкий:
- Высокие уровни — это корневые разделы и хабы, которые формируют скелет навигации и точку входа в систему.
- Средние уровни — это страницы‑коллекции, объединяющие однотипные объекты.
- Низкие уровни — карточки конкретных объектов, где реализуются операции и принимаются решения.
Пример распределения сущностей по уровням:
| Уровень | Сущность | Тип задач пользователя | Тип контента |
|---|---|---|---|
| Высокий | Каталог, Блог, Документация | Обзор, переход к разделу | Навигационный |
| Средний | Категория, Раздел, Проект | Сравнение, поиск | Коллекционный |
| Низкий | Товар, Статья, Пользователь | Изучение, действие, покупка | Объектный |
Такое разделение помогает проектировать маршрут от главной страницы к объекту и обратно, управлять глубиной дерева и оптимизировать путь пользователя.
4.3. Группы, фасеты и фильтры
Сформируйте операционные группы, в которых будет понятно, где живёт каждая сущность (в каком разделе, хабе или подсистеме), какие фасеты с фильтрами к ней применимы и какие действия доступны. Это создаёт связь между информационной архитектурой и интерфейсом.
Пример разницы между статьёй и товаром:
| Сущность | Раздел | Фасеты и фильтры | Основные операции |
|---|---|---|---|
| Товар | Каталог | Бренд, Цена, Размер, Цвет | Купить, Сравнить, Добавить в избранное |
| Статья | Медиа | Рубрика, Теги, Дата | Читать, Поделиться, Добавить в подборку |
4.4. Приоритеты и наследование
Добавьте описание приоритетов и наследования таксономий: что отображается в интерфейсе, что используется для аналитики и SEO, а что служит внутренней классификацией.
Например:
Для корпоративного портала «Тип документа» может быть фасетом (для фильтрации и аналитики), а «Отдел» — иерархической категорией (для навигации и прав доступа).
В коммерции «Категория» и «Подкатегория» определяют URL и хлебные крошки, но не отображаются в фасетах, где остаются только фильтры «Бренд», «Цена», «Материал».
Обязательно фиксируйте ещё и правила наследования: категория → подкатегория → объект. В интерфейсе это проявляется как автоматическое применение фильтров при переходе на нижний уровень.
4.5. Управление обновлениями
Зафиксируйте методы актуализации таксономий: кто отвечает за создание новых терминов, их перевод, синхронизацию и архивирование. Опишите процессы ревизии, чтобы не допустить появления дубликатов или устаревших меток.
Например, контент‑отдел добавляет новые категории раз в квартал, SEO‑отдел проводит сверку алиасов, а аналитика проверяет наличие связанных данных.
Для крупных продуктов полезно ввести аудит изменений с фиксированием автора, даты пересмотра и краткого описания причины (например, «слияние категорий», «переименование фасета»).
5. Выявление связей: кардинальности и контексты
В теоретической части цикла мы говорили о кардинальностях, хранении, сценариях и индексах. Теперь давайте взглянем на то, как к этом прийти.
5.1. Кардинальности
Определение кардинальности было в прошлой статье, подробно на термине останавливаться не стану. Добавлю только, что для каждой связи крайне желательно описать:
- с чем осуществляется связь,
- тип связи,
- глубину вложенности и
- пример (при необходимости).
Вот как это может выглядеть для сущности «товар»:
| Связан с | Кардин. | Глубина вложенности | Описание связи и кардинальности |
|---|---|---|---|
| Категория | 1:N | 2-3 уровня | Иерархическая таксономия. Один товар принадлежит одной конечной категории, но категория содержит множество товаров. В родительской категории находятся все товары дочерних. |
| Тег | M:N | 1 уровень | Плоская таксономия. Один товар может иметь несколько тегов, каждый тег применяется к нескольким товарам. |
| Заказ | M:N | 1 уровень | Связанная сущность. Один товар может входить во множество заказов. В одном заказе может быть несколько товаров. |
| Отзыв | 1:N | 1 уровень | Связанная (дочерняя) сущность. У одного товара может быть множество отзывов. |
| Пользователь | M:N | 1 уровень | Связанная сущность. Пользователь может взаимодействовать с несколькими товарами (просмотры, избранное, история покупок). С одним товаром могут взаимодействовать множество пользователей. |
Такая таблица может стать отличным началом для дальнейшей проработки связей.
5.2. Контекстные связи
Речь о связях вроде «похожие», «часто вместе», «варианты», «альтернативы» и так далее. Они используются в карточках, рекомендациях и аналитике пользовательских сценариев. Например, в e-commerce это может быть «с этим товаром часто покупают», а в медиа — «похожие статьи» или «продолжение серии».
Важно разделять логические связи (на уровне ИА) и вычисляемые (на уровне аналитики и рекомендательных алгоритмов).
Вот тот же пример, но с добавленными контекстными связями. Здесь и дальше я буду удалять лишние столбцы для читаемости, но в реальной таблице их лучше бы оставлять (или делать перекрёстные таблицы):
| Связан с | Контекст | Тип контекста |
|---|---|---|
| Категория | «Товары в этой категории» — аналогичные товары из категории. | Логический |
| Тег | «Похожие товары» — товары с пересекающимися тегами. | Логический |
| Заказ | — | — |
| Отзыв | — | — |
| Пользователь | «Вам понравится» — на основе поведенческих данных и предыдущих заказов. | Вычисляемый |
Разумеется, эта табличка сильно упрощает реальность. Даже в простеньком интернет-магазине контекстная связь «Похожие товары» будет, скорее, вычисляемой на основе многих факторов, а не только тегов.
5.3. Ключевые и вариативные связи
Выделите два типа связей:
- ключевые (частые) связи — они должны быть быстрыми, индексируемыми, проверяемыми на целостность;
- вариативные — их можно хранить гибко, например, в JSON или агрегированных таблицах.
Вот тот же пример:
| Связан с | Тип связи | Комментарий к типу связи |
|---|---|---|
| Категория | Ключевая | Основная связь для навигации и фасетной фильтрации, требует строгой целостности и индексации. |
| Тег | Вариативная | Может меняться часто, используется для быстрых выборок и контекстных срезов, хранится гибко. |
| Заказ | Ключевая | Одна из бизнес‑критичных связей, формирует аналитику продаж и отчётность, требует транзакционной целостности. |
| Отзыв | Вариативная | Данные обновляются динамически пользователями; важно для контентных сервисов, но не влияет на бизнес‑логику. |
| Пользователь | Вариативная | Основана на поведенческих данных (просмотры, избранное, покупки), часто хранится в отдельных логах или кэше. |
5.4. Направление и зависимости связей
Направления связей и зависимость объектов часто определяет их поведение. Заказ зависит от пользователя, а не наоборот. Комментарий зависит от поста, а не пост от комментария. Такие зависимости влияют на каскадное удаление и миграции, это очень важная часть ИА и дальнейшего проектирования баз данных.
Вот как это может выглядеть:
| Связан с | Направление связи | Зависимость | Описание |
|---|---|---|---|
| Категория | Категория → Товар | Товар зависит от категории | При удалении категории товары должны быть перемещены, переназначены или архивированы. |
| Тег | Двусторонняя (M:N) | Независимая | При удалении тега удаляются только связи, товары остаются без изменений. |
| Заказ | Товар → Заказ | Заказ зависит от товара | Заказ хранит ссылки на товары. При удалении товара заказы сохраняют данные о позиции, помечая их как архивные или недоступные. |
| Отзыв | Товар → Отзыв | Отзыв зависит от товара | При удалении товара отзывы удаляются или помечаются как «осиротевшие». |
| Пользователь | Двусторонняя (поведение) | Частично | Поведенческие связи с товаром (просмотры, избранное) можно анонимизировать или обнулить при удалении пользователя. |
На этом, пожалуй, можно завершить историю про выявление связей между сущностями. Мы и так одной ногой ступили на зыбкую почву дизайна баз данных. Дальше пусть взрослые разбираются.
6. Итог
Мы ещё не успели пройтись по самому интересному — выявлению и фиксации свойств сущностей, схематизации всего этого добра. Но статья и так вышла объёмной, об этом будет в следующей части серии.
- Все статьи цикла:
- Информационная архитектура: краткий экскурс
- Информационная архитектура: пример и типизация
- Информационная архитектура: сущности (теория)
- Информационная архитектура: сущности (практика, vol.1) (вы здесь)
- Информационная архитектура: сущности (практика, vol.2)
- Информационная архитектура: модели (coming soon)
- Информационная архитектура: практические советы (coming soon)
