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

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

Паттерны моделирования свойств

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

Да и с базовыми, если честно, порой могут возникнуть проблемы. Например, у нас есть свойство «Цвет». Оно простое: ни на кого не ссылается, это не таксономия — это, скорее, словарь, сквозное свойство. Как с ним быть? Или с полем «Описание» — оно тоже простое, но активно участвует в индексации и поиске, об этом тоже нужно подумать.

Давайте разбираться.

Нормализованные словари

Их ещё называют «справочниками», а разработчики — ENUM, перечислением. Мы их уже касались вскользь. Поля такого типа могут принимать только значения из конкретного, определённого перечня.

Правила:

• Значения — всегда конечные и контролируемые, добавление новых происходит только по процессу ревью.
• Поддерживают алиасы/синонимы для поиска, но в БД хранится нормализованное значение (ключ).
• Если значения словаря локализуются (переводятся на другие языки), то внутренний ключ остаётся неизменным.

Пример:

У товара есть поле brand, которое ссылается на запись из справочника брендов. В справочнике брендов есть конечный перечень записей обо всех брендах, представленных в системе.

Риски:

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

Ссылочные поля

Поля, указывающие на другие сущности через внешние ключи. Главное их отличие от нормализованных словарей в том, что ссылочные поля связывают сущности между собой и с другими объектами (например, с терминами таксономий). Тогда как значения ENUM из предыдущего примера не являются отдельными объектами, они просто строчка в фиксированном списке.

Ссылочные поля — это «мостики» между сущностями: товар связан с категорией, тегами, продавцом, заказами. Благодаря им карточка не живёт в вакууме, а встраивается в общую систему.

Правила:

• Для «один‑ко‑многим» 1:N (категория → товары) у товара хранится ссылка на свою категорию.
• Для «многие‑ко‑многим» M:N (товар ↔ тег) связи хранятся отдельно.
• Важно продумать, что происходит при удалениях: кого переносим, кого архивируем, а где просто убираем связь.

Пример:

У товара есть одна «Категория», но множество «Тегов».

Если удалить тег — товар останется. Если удалить категорию — нужно заранее решить, куда товар переедет.

Риски:

• Непродуманные правила удаления ведут к потере данных или поломке логики. Я видел случаи, когда при удалении рубрики в CMS, из базы данных удалялись десятки статьей и сотни комментариев.
• Когда связи между сущностями организованы неэффективно, системе приходится делать много лишних запросов, фильтровать данные или пересчитывать агрегаты на лету. Это замедляет скорость работы продукта.
• Если связи построены небрежно, при массовых обновлениях могут случиться зависания или сбои. Например, любое изменение категории или продавца может вызвать ошибки в отображении связанных с ними карточках.

Вычисляемые поля

Это свойства, которые не вводятся вручную, а считаются системой на основе других данных: средний рейтинг, количество просмотров, популярность, конверсия. Они помогают понять, насколько «живой» или успешный объект, не требуя ручного обновления.

Вычисляться такие поля могут «на лету», либо храниться в БД или кэше.

Правила:

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

Пример:

Риски:

• «Расползание» цифр: в карточке одно, в отчёте другое. На момент написания статьи такое можно увидеть на Хабре, там два разных счётчика просмотров: один доступный всем, другой — только авторам.
• Неочевидные формулы, спрятанные в глубинах кода. Показатели меняются, команда не понимает причин.
• Слишком частые пересчёты. Система вычисляет показатели слишком часто, нагружая серверы без нужды. Или наоборот — слишком редкие обновления, из‑за которых пользователи видят устаревшие данные.

Диапазоны и интервальные фасеты

Кто-то считает интервальные фасеты лишь подмножеством вычисляемых полей, но я решил выделить их отдельно. Они чаще всего встречаются и имеют несколько специфичных свойств.

Фильтры по числам и датам помогают пользователю быстрее находить подходящие товары. Мы редко ищем вещь за точно 2 570 рублей — обычно хотим что-то «в районе двух‑трёх тысяч». Поэтому интерфейс должен позволять задавать диапазон значений: цену «от-до», вес или рейтинг. Пользователь мыслит не конкретными числами, а удобными «вилками» — например, «до 1000 рублей» или «от 4 звёзд и выше».

Правила:

• В системе хранится точное значение, а пользователю показываются готовые «умные» интервалы (например, на основе реального распределения цен). Если меняем цену, то принадлежность к интервальным полям изменяется автоматически.
• Правила границ (включительно/исключительно) и округления задаются явно. Чтобы не было непонятно, входит «1000» в «до 1000» или в «1000-5 000».
• Должны быть продуманы правила обработки пустых/нулевых значений. Например, «цена не указана» — это отдельная группа, она не попадает в интервалы.

Пример:

Риски:

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

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

Составные и полуструктурированные поля

Когда у сущности много разнородных характеристик (например, у товара есть изображения, материалы, дополнительные свойства) — удобнее собрать их в «пакеты». То есть не разбивать свойство на десятки отдельных полей, а объединить в один структурированный набор. Это помогает избежать перегруженности данных и сделать архитектуру более гибкой.

Во второй статье цикла я писал о сильной и слабой типизации. Так вот составные поля — отличных пример признака слабой типизации.

Правила:

• Те свойства, которые часто используются для фильтрации, сравнения или сортировки (ширина, вес, цена), лучше выделить в отдельные простые поля. Остальное можно хранить в составе набора.
• Важно сразу договориться о едином формате (например, JSON или таблица), чтобы не получилось сотни уникальных схем в разных объектах.
• Также стоит помнить об ограничении глубины вложенности — чем проще структура, тем меньше ошибок при обновлениях.

Пример:

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

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

Риски:

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

Поисковые поля

Это поля, которые напрямую влияют на то, как пользователи находят нужный элемент через поиск. Именно они определяют качество и релевантность результатов. Обычно сюда входят: название, краткое описание, артикул и так далее.

Правила:

• Поиск должен «думать как человек»: учитывать разные формы слов («купить» и «покупка»), синонимы («ноутбук» и «laptop») и популярные опечатки. Именно поисковые поля должны лучше всего индексироваться.
• Полезно задавать разный «вес» полям — название важнее описания, а описание важнее технических характеристик.
• Важно поддерживать актуальный словарь синонимов и опечаток: он должен пополняться на основе статистики реальных поисковых запросов.

Пример:

Риски:

• Сложные запросы без ограничений по размеру выдачи запросто могут «положить» поиск, перегрузив систему.
• Если переусердствовать с синонимами, поиск начинает показывать нерелевантные результаты, будет слишком много «шума».
• Несвоевременно обновляемый словарь приводит к тому, что люди начнут искать новые термины, которых в базе нет — и, не получив результатов, посчитают, что товара нет вовсе.

Технические поля

Это служебные поля, которые фиксируют то, что пользователям знать не обязательно. Например: когда и кем запись создана/изменена, какой у неё статус, флаги индексации. Такие данные помогают поддерживать порядок, находить ошибки и понимать, как объект живёт во времени. Без них часто невозможно разобраться, кто и что сделал, особенно если с системой работает большая команда.

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

Правила:

• Типовые значения указываются в едином формате: например, время — только в UTC+0. Это позволяет потом не путаться при реализации и анализе.
• Важно заранее договориться о понятных статусах сущностей и допустимых переходах между ними, фиксировать автора, источник и причину изменений.
• Желательно хранить историю правок хотя бы ключевых сущностей, чтобы при спорных ситуациях можно было восстановить ход событий.

Пример:

Риски:

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

Ограничительные поля

Это поля, которые определяют рамки доступности сущности: кто может её видеть, с ней взаимодействовать, где и при каких условиях. Они регулируют поведение системы и помогают избегать нарушений — например, продаж алкоголя несовершеннолетним или показ товаров, запрещённых к экспорту в конкретной стране. Также ограничительные поля фиксируют бизнес‑ограничения и ролевую модель вроде «только для админов» или «данные предоставляются по запросу».

Правила:

• Разделяйте «бизнес‑ограничения» (что показываем и кому) и «технические» (что разрешает система). Должно быть прозрачно, почему сущность или операция скрыта или недоступна.
• Желательно сопровождать такие поля пояснениями — что именно ограничивает доступ и где отображается уведомление пользователю.
• Все ограничения должны иметь понятные статусы (например, «активно», «ожидает проверки», «временно снято с продажи») и быть управляемыми, а не жёстко зашитыми в код.

Пример:

Риски:

• Скрытые ограничения ломают пользовательский опыт. Если это не предусмотрено специально, всегда сообщайте об ограничениях тем, кого они касаются.
• Разные правила на фронте и бэкенде почти всегда приводят к несоответствиям. Лучше делать основную логику на сервере, а клиенту (браузеру или приложению) доверять только визуальное отображение.
• При массовых изменениях может возникнуть путаница. Например, когда правила блокировок не синхронизированы между странами или каналами продаж.

Собственно, фиксация

Теперь, когда с паттернами стало немного понятнее, давайте попробуем всё это зафиксировать.

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

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

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

Основная информация

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

Пример основной информации о сущности «Товар»:

Обратите внимание на тип данных: в различных системах типы данных могут обозначаться по-разному, при работе с IA желательно придерживаться какого-то единого, понятного всем, формата. Конкретно здесь:

• int — простое целое число;
• text — текст без явных ограничений в типе данных (не varchar, например);
• float — число с плавающей точкой (3.23);
• ref — ссылка на другую сущность, reference;
• enum — его вы уже знаете, нормализованный словарь.

Источник и валидация

Откуда берётся значение и как проверяется. Укажите, поступает ли значение от пользователя, из импорта, внешней системы или вычисляется автоматически. Опишите правила проверки (валидации): допустимые диапазоны, форматы, обязательные символы. Также стоит указать, что происходит, если значение не проходит проверку (ошибка, предупреждение, автозамена).

Индексация и поиск

Как используется в поиске, фильтрах и аналитике. Опишите, участвует ли поле в поиске или фасетах, влияет ли оно на фильтрацию, сортировку и аналитику. Укажите, какие сценарии зависят от него (поиск по названию, сортировка по цене, фильтр по цвету). Добавьте, нужна ли регулярная переиндексация и как часто.

Владение и контекст

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

Жизненный цикл и обновление

Как часто меняется поле. Разделите поля по типу обновления: редактируемые пользователем, автоматически пересчитываемые системой, импортируемые из внешних источников. Укажите частоту проверки актуальности и правила пересмотра.

Нормализация и перевод значений

Как поддерживается единообразие. Опишите, как поле очищается и приводится к общему формату: регистр, язык, синонимы, стандарты записи. Если данные многоязычные — уточните правила перевода. Добавьте примеры типичных ошибок и корректного вида.

Таблица свойств (Entity Attribute Matrix)

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

Обязательно ведите версионирование: когда и кем изменялась таблица, что именно было изменено. Это позволит, при необходимости, провести трассировку изменений (например, при расхождении информационной архитектуры с программной реализацией).

Ну и напоследок, как и обещал, полная таблица свойств из этой статьи:

Не переключайтесь, в цикле будет ещё как минимум две статьи.

Запись Информационная архитектура: сущности (практика, vol.2) первой появилась на Павел Шерер.

Небольшое вступление

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

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

Подготовка: контекст и границы

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

Цель продукта

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

В сложных продуктах может быть сильно больше 3-5 ключевых задач. В этом случае рекомендую декомпозировать его на логические или функциональные компоненты — и в каждом из них уже выводить свои цели и задачи.

Для каждой задачи задайте измеримые KPI: «среднее время до результата (time‑to‑task)», «конверсия в целевое действие», «доля успешных сценариев» и подобные.

Границы домена

Составьте карту предметной области: какие объекты и операции в неё входят, а какие находятся за её пределами. Например, для маркетплейса внутрь попадают товары, продавцы, категории и заказы, а расчёт комиссий или логистика могут быть вынесены в соседние сервисы. Это защитит команду от размывания фокуса и неконтролируемого расширения требований.

Источник истины

Определите, где хранятся все артефакты ИА: таблицы сущностей, словари терминов, фасеты, схемы связей и тд. Лучше всего, если это будет ваша внутренняя вики, типа Confluence. Для диаграмм и визуальных схем можете использовать draw.io (благо, он встраивается почти куда угодно) или FigJam.

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

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

Согласование терминологии

Создайте единый глоссарий терминов, где каждое понятие имеет согласованное определение. Например: в интерфейсе, в аналитике и в БД термин «пользователь» должен значить одно и то же, а не три разных понятия: аккаунт, клиент и автор. Я встречал системы, где одна и та же информационная сущность в одном месте называлась «пользователь», в другом «клиент», а в третьем «посетитель». Не надо так.

Хорошо организованный глоссарий устраняет двусмысленности и предотвращает непонимание между аналитиками, дизайнерами и разработчиками.

Декомпозиция: перечень сущностей

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

Цель здесь простая: увидеть полную картину того, из чего состоит продукт и как эти части взаимодействуют между собой.

Определение типов

Пройдитесь по всем сценариям вашего продукта и выпишите устойчивые типы информации: «товар», «категория», «метка/тег», «пользователь», «заказ», «корзина», «страница» и тп. Добавьте сюда вспомогательные и производные сущности, которые не видны пользователю напрямую, но обеспечивают работу системы — например, «транзакция», «сессия», «ревизия».

Скорее всего, на этом этапе вы упустите какие-то объекты, ничего страшного. Как я уже говорил, работа над IA — не всегда строго последовательный процесс. Вернётесь, как найдёте ошибку.

Описание сущности

Для каждой сущности кратко опишите:

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

Тут важно не уходить в дебри и не погружаться в детальное проектирование. Вот вам пара простых примеров:

Проверка на дубликаты

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

Закрепление ответственных

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

Вот простенький пример такой матрицы для e-com:

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

Выработка метрик

Дополнительно укажите метрики для каждой сущности — показатели того, что она используется и актуальна. Вот несколько примеров:

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

Классификация: таксономии, уровни и операции

После того как сущности выделены и описаны, важно понять, как они группируются и взаимодействуют в структуре продукта. Этот этап превращает «список объектов» в осмысленную систему: мы определяем, какие сущности являются базовыми разделами, какие служат фильтрами или связками, и как пользователь перемещается между ними.

Классификация помогает превратить набор данных в удобную навигацию, а архитектуру — в понятную карту продукта.

Типы таксономий

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

Пример, по традиции, из e-com:

Уровни сущностей

Назначьте уровень сущности — высокий, средний или низкий:

• Высокие уровни — это корневые разделы и хабы, которые формируют скелет навигации и точку входа в систему.
• Средние уровни — это страницы‑коллекции, объединяющие однотипные объекты.
• Низкие уровни — карточки конкретных объектов, где реализуются операции и принимаются решения.

Пример распределения сущностей по уровням:

Такое разделение помогает проектировать маршрут от главной страницы к объекту и обратно, управлять глубиной дерева и оптимизировать путь пользователя.

Группы, фасеты и фильтры

Сформируйте операционные группы, в которых будет понятно, где живёт каждая сущность (в каком разделе, хабе или подсистеме), какие фасеты с фильтрами к ней применимы и какие действия доступны. Это создаёт связь между информационной архитектурой и интерфейсом.

Пример разницы между статьёй и товаром:

Приоритеты и наследование

Добавьте описание приоритетов и наследования таксономий: что отображается в интерфейсе, что используется для аналитики и SEO, а что служит внутренней классификацией.

Например:

Обязательно фиксируйте ещё и правила наследования: категория → подкатегория → объект. В интерфейсе это проявляется как автоматическое применение фильтров при переходе на нижний уровень.

Управление обновлениями

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

Например, контент‑отдел добавляет новые категории раз в квартал, SEO‑отдел проводит сверку алиасов, а аналитика проверяет наличие связанных данных.

Для крупных продуктов полезно ввести аудит изменений с фиксированием автора, даты пересмотра и краткого описания причины (например, «слияние категорий», «переименование фасета»).

Выявление связей: кардинальности и контексты

В теоретической части цикла мы говорили о кардинальностях, хранении, сценариях и индексах. Теперь давайте взглянем на то, как к этом прийти.

Кардинальности

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

• с чем осуществляется связь,
• тип связи,
• глубину вложенности и
• пример (при необходимости).

Вот как это может выглядеть для сущности «товар»:

Такая таблица может стать отличным началом для дальнейшей проработки связей.

Контекстные связи

Речь о связях вроде «похожие», «часто вместе», «варианты», «альтернативы» и так далее. Они используются в карточках, рекомендациях и аналитике пользовательских сценариев. Например, в e-commerce это может быть «с этим товаром часто покупают», а в медиа — «похожие статьи» или «продолжение серии».

Важно разделять логические связи (на уровне ИА) и вычисляемые (на уровне аналитики и рекомендательных алгоритмов).

Вот тот же пример, но с добавленными контекстными связями. Здесь и дальше я буду удалять лишние столбцы для читаемости, но в реальной таблице их лучше бы оставлять (или делать перекрёстные таблицы):

Разумеется, эта табличка сильно упрощает реальность. Даже в простеньком интернет-магазине контекстная связь «Похожие товары» будет, скорее, вычисляемой на основе многих факторов, а не только тегов.

Ключевые и вариативные связи

Выделите два типа связей:

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

Вот тот же пример:

Направление и зависимости связей

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

Вот как это может выглядеть:

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

Итог

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

Запись Информационная архитектура: сущности (практика, vol.1) первой появилась на Павел Шерер.

Вокабуляр

Для начала давайте вспомним некоторые определения, которые помогут вам ориентироваться в этой статье:

Информационная сущность — устойчивый тип информации в домене продукта (товар, пользователь, заказ, пост, коллекция, организация и тп), обладающий набором свойств и связей.

Свойство сущности — характеристика, описывающая сущность количественно или качественно (название, цена, цвет, дата создания и тп). Свойства могут быть разных типов, заполняться и проверяться по разным правилам, быть «зависимыми» или нет.

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

Термин таксономии — конкретная единица этой классификации (например, категория «Кроссовки» в таксономии «Обувь»).

Фасет — нормализованный атрибут, используемый для фильтрации и уточнения поиска (бренд, цвет, размер и тп).

Что такое «сущность» и чем она не является

Сущность всегда:

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

Из-за того, что терминология, как обычно, размыта, сущности легко можно спутать с чем-то, что ими не является, например:

• со страницей/экраном (это представление сущности в одном из контекстов);
• с UI‑компонентом (это способ отображения свойства или связи);
• с таблицей БД (это реализация хранения, одна сущность может жить в нескольких таблицах и наоборот);
• с бизнес‑процессом (это поведение вокруг данных: процесс «оформить заказ» использует сущности «корзина», «заказ», «платёж»).

Небольшая оговорка: иногда название сущности совпадает с названием представления, это абсолютно нормально. В контент‑ориентированных продуктах (CMS, документация, лендинги) тип «Страница» может быть полноценной контент‑сущностью с собственными свойствами (название, ярлык, текст, автор и тп) и жизненным циклом. Тезис «страница — не сущность» касается только путаницы между сущностью домена и экраном интерфейса (UI‑представлением).

Сложно? На самом деле нет. Вот вам простой тест. Объект — это сущность, если содержит хотя бы 3 из следующих признаков:

• имеет собственные свойства;
• имеет связи с другими объектами;
• повторяется во множестве экземпляров;
• нужен в отчётности/поиске;
• имеет собственные правила валидации/жизненный цикл.

Свойства сущности

Как мы уже выяснили, у сущностей есть свойства. Это, пожалуй, самое важное, что отличает их от остальных объектов цифрового продукта. Давайте поговорим об этом чуть подробнее.

Типы свойств

Свойства могут быть нескольких типов:

• Базовые: идентификатор, название, описания и прочие. Это простые поля, которые содержат типовую информацию. Базовые свойства не ссылаются на другие объекты и, как правило, представлены в виде простых типов данных (строка, число, дата и тп).
• Ссылочные: внешние ключи на другие сущности (например, «идентификатор пользователя» в сущности «заказ»), а также термины таксономий (категория, метка, группа). Ссылочные свойства нужны для того, чтобы гарантированно связать сущности между собой и с терминами таксономий.
• Составные: свойства, которые включают в себя сразу несколько значений, объединённых одной логикой. Составные свойства могут быть однородными и неоднородными:
  • однородные списки (например, изображения: {url, alt},...);
  • неоднородные комплекты (например, габариты: {weight, width, height, depth}).
• Вычисляемые: свойства, для фиксации (сохранения, отображения и тп) которых нужно сначала произвести какие-то операции. Например, это могут быть: цена со скидкой, количество на складе, агрегированный рейтинг.
• Технические: SKU/артикул, временные отметки, статусы модерации/публикации, флаги индексации. Технические свойства редко используются в визуальном представлении (например, в карточке товара из десятка технических свойств будет выводиться только артикул).
• Ограничительные: права доступа (ACL), владельцы, видимость. Их очень легко спутать с техническими, так как они тоже используются больше в логике, чем в представлении. Если сомневаетесь, задайте себе вопрос: «это свойство влияет на возможности пользователей?» — если да, то перед вами именно ограничительное свойство.

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

Пример описания свойств

Минимальный набор информации, которую желательно фиксировать при описании каждого свойства сущности:

1. название — короткое имя свойства, одно-два слова;
2. код — как это свойство будет называться в коде и базе данных;
3. тип данных — строка, число, массив, объект, ссылка и тп;
4. обязательность — обязано ли свойство быть заполненным, если отметка «да», то значение свойства не может быть пустым;
5. пример — короткий пример заполнения свойства (если пример слишком длинный, он может быть обрезан);
6. описание/комментарий — если требуется вносить какую-то дополнительную информацию.

При желании, этот перечень можно дополнить дополнительными параметрами:

1. источник — откуда берётся значение свойства (логика, подсистемы, интеграции и тп);
2. валидации — базовое правило проверки значения свойства;
3. индексация/поиск — участвует ли свойство в поиске и индексации, если да, то как;
4. политика i18n — для локализуемых свойств: какие переводятся, какие нет;
5. политикой заполнения — кто и когда обязан заполнить.

Вот пример того, как могут фиксироваться свойства сущности «товар» (табличка получилась внушительная, скрольте влево):

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

Примеры по доменам

Из-за того, что все продукты разные, домены в них тоже могут отличаться. В одном e-com сущность «товар» будет обладать одним набором свойств, в другом — совершенно иным. Порой очень хочется просто взять наработки с прошлого места работы и запихнуть их в текущую архитектуру «как есть». Призываю вас этого не делать, а всегда проектировать сущности, исходя из реалий продукта, процессов, потребностей пользователей и бизнес-задач.

Чтобы показать, насколько всё может отличаться от продукта к продукту, вот вам несколько примеров сущностей со свойствами из разных доменов:

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

Связи между сущностями

Как я уже говорил, сущности почти всегда связаны как между собой, так и с терминами таксономии. Давайте теперь копнём поглубже.

Кардинальности

Кардинальность — это характеристика связи между двумя сущностями (таблицами, объектами, классами и т.д.), показывающая, сколько экземпляров одной сущности может быть связано с экземпляром другой. Проще говоря, это способ ответить на вопрос: «Сколько А может быть связано с одним B?» и наоборот.

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

Подробнее про кардинальности я писал в цикле про дизайн данных, здесь пройдёмся коротко:

• Один-ко-одному, 1:1 — связь, когда каждой записи одной сущности соответствует не более одной записи другой (аккаунт ↔ профиль). Используется для разделения личных и технических данных или выделения редко используемых атрибутов.
• Один-ко-многим, 1:N — наиболее частая связь: один объект верхнего уровня связан с множеством подчинённых (категория → товары; организация → проекты). Применяется для иерархий, коллекций и агрегатов.
• Многие-ко-многим, M:N — объект может быть связан с несколькими другими (товар ↔ теги; пост ↔ автор). Реализуется через промежуточные таблицы/сущности, содержащие идентификаторы обеих сторон и метаданные связи.

Хранение и производительность

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

Это ещё не дизайн баз данных, но первый шаг к нему.

Ключевые, частые связи

Реализуются как явными внешними ключами (Foreign Key, FK — ссылка из одной таблицы БД на запись другой таблицы), так и отдельными таблицами. Индексируются для быстрого поиска и каскадных операций (например, при удалении пользователя каскадом удаляются его профиль, способы оплаты и тп). Ключевые связи хорошо подходят для данных, которые часто запрашиваются и требуют согласованности.

Например, ключевой связью является связь пользователя и его профиля (1:1) или заказа и товара (1:N).

Вариативные, редкие связи

Удобнее хранить в агрегированных структурах (JSON, массивы, ключ-значение) или связующих таблицах без строгих FK. Такой подход облегчает эволюцию схемы и интеграции с внешними источниками.

Пример вариативной связи: товар и теги (M:N через JSON или связующую таблицу) или пост и связанные материалы (список ссылок в массиве).

Комбинированный подход

Сочетает строго типизированные связи для критичных сценариев (например, FK для заказов и пользователей) и гибкие структуры для второстепенных (например, свойства товара в JSON). Это компромисс между скоростью, расширяемостью и затратами на сопровождение.

Пример комбинированного подхода: заказ и пользователь (жёсткий FK) + история изменений в JSON, товар и его характеристики (основные поля + гибкое поле параметров).

Поисковые сценарии и индексы

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

Поисковые сценарии — это практические случаи, когда пользователь взаимодействует с данными через поиск, фильтрацию и сортировку.

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

Индексировать можно разные типы полей:

Фасетные поля

Категория, бренд, размер, цвет, материал и прочее. Хранятся в нормализованных словарях или связаны с терминами таксономий, индексируются отдельно. Это даёт возможность строить фильтры и считать количество элементов в каждой группе (это ещё называется «фасетные агрегации»). Чтобы ускорить отклик системы, важно хранить предвычисленные частоты — но это уже совсем мрак, оставим его архитекторам БД.

Поисковые поля

Используют полнотекстовые индексы и префиксные деревья для автодополнения и предложений. Помните, как вы вбиваете что-то в строку поиска, а вам показывают подсказки? Вот это оно. Здесь же добавляются морфологический анализ, поддержка синонимов, транслитерации и нечёткий поиск (fuzzy search).

Сортировочные поля

Числовые и временные индексы (цена, рейтинг, дата создания, популярность), обеспечивающие быстрые операции сортировки и пагинацию без нагрузки на базу данных.

Сложно? Подождите, это ещё не всё

Существует тьма технических приёмов, нацеленных на оптимизацию индексирования: применение комбинированных индексов по частым связкам category_id + price, денормализация популярных связей product → category_name, кэширование фасетных частот для снижения нагрузки и прочее. Но это вам так, если захочется погрузиться.

Таксономии и «сквозные» свойства

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

Иерархическая таксономия

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

Такая модель хорошо подходит для каталогов товаров, корпоративных порталов и CMS, где пользователи ожидают логичную последовательность разделов и вложенных подразделов.

Преимущество: высокая предсказуемость навигации и простота в управлении.

Недостаток: ограниченная гибкость и риск «похоронить» информацию слишком глубоко.

Плоская таксономия

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

Чаще всего плоские таксономии используется в медиа, блогах и SaaS‑платформах для тегирования и сквозных переходов между материалами.

Преимущество: простота расширения и гибкость.

Недостаток: если не контролировать список терминов, со временем возможна потеря структурности и даже полная поломка логики (например, когда у вас есть 2 разных метки «UX» и «ux»).

Фасетная таксономия

Объединяет независимые классификации, например: категория, бренд, размер, цена, материал. Пользователь может фильтровать данные сразу по нескольким измерениям.

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

Преимущество: высокая управляемость фильтрацией и быстрый поиск.

Недостаток: сложность проектирования и ухудшение управляемости при росте числа комбинаций.

Сквозные свойства

Например: материал, бренд, разрешение экрана. Сквозные свойства выполняют роль фасетов и служат мостом между таксономиями и данными:

• живут в единых словарях, которые поддерживаются централизованно;
• используются как фасеты и правила мерчендайзинга/рекомендаций;
• имеют политику синонимов, нормализации значений и правила локализации;
• могут быть жёстко типизированы (enum — о них чуть ниже) или гибкими (текстовые значения, появляющиеся из данных);

Однако у сквозных свойств есть и обратная сторона. Давайте разберём на примере свойства товара «материал».

«Материал» — фасет только при наличии нормализованного словаря (ограниченный справочник материалов). Если материал хранится как произвольный текст (например, «металлический с пластиковыми вставками»), он не является фасетом и остаётся обычным полем: участвует в полнотекстовом поиске, но не в фасетной фильтрации.

Противоречивые классификации

Иногда классифицировать сущности оказывается сложно. Хороший пример такой противоречивой классификации — вопрос «где разместить арбуз»? Это ягода (что правильнее с точки зрения ботаники), тыквина (что ещё более правильно) или фрукт (ведь именно там его ищут пользователи)?

Когда один и тот же объект может относиться сразу к нескольким категориям, архитектору важно не выбрать «правильный» ответ, а установить управляемую логику принятия решений. Задача таксономии — не отражать условную «истину», а обеспечивать предсказуемость и согласованность между системами.

И для этого существует несколько правил:

1. Вводим приоритеты классификаций (биология < повседневные ожидания < бизнес‑цели каталога). Эти приоритеты задают уровень, на котором принимается решение — например, витрина каталога ориентируется на пользовательскую логику, а не на научную.
2. Формируем правила визуализации и информационные связи: как объект отображается в меню, поиске, фильтрах и фасетах, чтобы не было дублирования или рассинхронизации. В карточке сущности могут быть указаны обе принадлежности, но навигация использует только основную.
3. Фиксируем конфликты и владельцев решения: кто принимает решение, когда пересматривается структура, где фиксируются комментарии и примечания.
4. Документируем принципы разрешения конфликтов и исключения, чтобы разные подсистемы (поиск, рекомендации, SEO) пользовались единым источником правды.

Пример визуализации базы данных

По итогу работы над информационной архитектурой обычно создаются спецификации API и дизайн БД. Про API здесь говорить пока рано, а вот про БД уже пора.

Ловите пример того, как может выглядеть простенькая база данных в виде ER-диаграммы:

Здесь учитывается почти всё:

• По типу соединения можно понять тип связей. Например, от users.id к orders.user_id соединение начинается одной линией, а заканчивается несколькими, разветвлением — это связь однин-ко-многим (1:N).
• Иконка «ключика» возле названия поля обозначает первичный ключ (primary key), который уникально идентифицирует каждую запись. А иконка «заметки» говорит о том, что у поля есть дефолтное значение.
• Если возле названия есть иконка «ссылки», то это внешний ключ (foreign key), и от него почти всегда будет связь 1:N к источнику. Например, от того же orders.user_id к users.id.
• Две буквы «NN» в конце каждой строки — это «NOT NULL», поле не может быть пустым. Та самая обязательность из таблички, помните?
• Буква «Е» в orders.status означает «ENUM» — набор именованных констант. Значение этого поля может быть заполнено только значениями из определённого словаря. В нашем случае статус заказа может быть только pending, paid, shipped, delivered или canceled.
• Ну а всякие varchar, int, decimal, datetime и другие — всего лишь типы данных, которые хранятся в этом поле.

Так нафига вообще тогда информационная архитектура, если можно сразу пилить ER-диаграммы и не париться? Да потому что они описывают только один слой IA — слой реализации хранения данных (в самом начале статьи мы об этом говорили). Огромный пласт информации, накопленной грамотным подходом к IA, здесь не учитывается. Примеры, политики заполнения и мультиязычности, правила валидации, источники данных и куча всего остального.

Так что не ER-диаграммами едиными.

Что дальше

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

Подписывайтесь на канал, там будут все новости.

Запись Информационная архитектура: сущности (теория) первой появилась на Павел Шерер.

Я начинал свой путь в дизайне, когда все эти ваши юиксы обитали, преимущественно, на Западе. А сииксов вообще не было. Тогда всё это называлось просто «юзабилити». Ещё живя в Саратове (не пытайтесь покинуть Саратов), я выступал за расширение этого понятия. Читал наивные лекции о том, что «пользователь пьян», был одним из евангелистов пользовательского опыта как подхода.

Но обожаемый мною маркетинг, как обычно, всё упростил.

Так случилось с персонами Алана Купера (моделями типичных пользователей), картами пути клиента (CJM) и даже со скрамом.

UX сузили до интерфейсов, а CX (опыт клиента) возвели в ранг «нового короля». Меня это иногда подбешивает, и я решил немного подушнить. Теперь я буду просто давать ссылку на эту статью.

Но чтобы было понятнее, давайте разберёмся на простом примере.

Пример: бронирование билета в авиакомпании

Как все себе представляют это разграничение сейчас:

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

Если вы улучшите только UX-форму оплаты, NPS может не сдвинуться, потому что претензии к колл-центру останутся. И наоборот: идеальный CX-чеклист не спасёт, если кнопка «Оплатить» лагает.

Да, UX и CX связаны, но я считаю, что в 2025 году UX остаётся фундаментом. Давайте разберём, почему.

Почему UX главнее

UX включает в себя CX, а не наоборот. Да, всё идёт к слиянию, но это не будет «поглощением» сииксом юикса. Это либо будет что-то новое (об этом чуть ниже), либо юикс останется собой. И вот почему:

Оригинальное определение

Дон Норман ещё в девяностых определил UX как «все аспекты взаимодействия конечного пользователя с компанией, её услугами и продуктами»:

«User experience» encompasses all aspects of the end-user’s interaction with the company, its services, and its products.

«Весь» опыт — это и офлайн-доставка, и колл-центр, и вообще всё, что маркетологи потом назвали CX.

Да, Норман прямо говорит, что сейчас классический human-(user)-centered design фокусируется на «сделать интерфейс понятным» и забывает о том, как производство, утилизация и экосистема влияют на людей и планету. То есть сам термин UX за 30 лет врос в digital-нишу и утратил изначальную широту. Однако это не делает его синонимом «юзабилити» и не превращает в «расширенный UI».

Ещё раз, хронология:

• 1993 — Норман вводит UX, чтобы расширить понятие «интерфейсы».
• 2010-е — маркетинг обратно сужает UX до UI.
• 2023 — сам Норман вытаскивает понятие дальше, к humanity-centered.

То есть, если продолжать наш пример с авиакомпанией, то в последний пункт добавляются вопросы выбросов CO₂, переработки одноразового пластика в салоне, программы компенсации углеродного следа и тп. И всё это продолжает влиять на пользовательский опыт в широком его смысле.

Международный стандарт

Я не особо люблю стандарты, но ISO 9241-210:2019 явно закрепил UX как «восприятия и реакции человека, возникающие до, во время и после использования системы». Это охватывает весь опыт, включая моменты, которые CX-команды считают «своими». CX не выходит за рамки UX.

Лингвистика

Слова имеют значение:

• «User» — любой, кто взаимодействует: покупатель, партнёр, сотрудник.
• «Customer» — только тот, кто платит.

Например, в Sony Playstation Store пользователи — это и отец (который выбирает игру и покупает её), и сын (который играет). А вот клиент — только отец, потому что платит именно он. Следовательно, все CX-сценарии с платящими клиентами являются подмножеством более широкого множества UX-сценариев.

Историческое родство

Сервис-дизайн и CJM выросли из UX-исследований, чтобы захватить бэкстейдж услуги. CX появился как маркетинговый «ребрендинг» этой надстройки. Исторически CX-инструментарий вышел из UX, а не наоборот.

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

Методологическая инклюзивность

A/B‑тесты, глубинки, этнография — это всё базовый UX‑арсенал, который CX‑команды заимствуют. Обратного движения почти нет.

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

Почему кто-то считает CX важнее

Сторонники CX скажут, что он ближе к бизнес-целям: удержание клиентов, рост лояльности, увеличение выручки. Например, компании вроде Amazon фокусируются на CX, чтобы каждый контакт с клиентом, от рекламы до возврата товара, был безупречным. Это помогает растить базовые метрики, вроде LTV. CX фокусируется на эмоциональной связи с брендом, что критично для долгосрочной лояльности клиентов.

UX же, по их мнению, слишком узок и зациклен на интерфейсах. Но это не так. UX охватывает весь опыт, включая моменты, которые CX считает «своими». Да, CX кажется ближе к бизнесу, но только потому, что UX шире.

Хороший UX тоже влияет на метрики: снижает churn rate (отток пользователей) и увеличивает retention (удержание), а это напрямую влияет на выручку компании.

Маркетинг сузил восприятие UX до дизайна кнопок, а CX возвёл в ранг «стратегического подхода». На деле же хороший UX уже включает заботу о клиенте — просто без маркетингового шума.

Почему спор постепенно стихает

Nielsen Norman Group недавно отметила тренд слияния UX и CX. Компании вроде Airbnb и Spotify создают кросс-функциональные journey-команды, где исследователи, дизайнеры, продакт-менеджеры и CX-специалисты вместе отвечают за весь путь клиента — от первого знакомства с брендом до повторной покупки. Например, в Spotify такая команда может работать над «опытом первого прослушивания», синхронизируя интерфейс приложения, рекомендации и поддержку.

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

Что дальше?

Скорее всего, UX и CX скоро окончательно сольются, но пока важно помнить: UX — это основа, на которой строится весь опыт. Если вы хотите создать продукт, который люди полюбят, начните с UX-исследований: глубинных интервью, юзабилити-тестов, анализа поведения. Это даст фундамент, на котором CX сможет выстроить лояльность и бизнес-результаты.

Мой призыв к дизайнерам и продактам: думайте не только об интерфейсах, но и о каждом моменте, где пользователь встречается с вашим продуктом, верните термину UX его изначальный смысл. Даже если планируете идти в сторону HX.

Независимо от того, как эволюционируют термины, принципы UX — понимание пользователей и создание удобных решений — останутся базой для продуктов, которые люди любят.

Запись UX vs CX: кто кого включает первой появилась на Павел Шерер.

В этой статье я хочу рассказать о том, как «продолжение» User Story может не только улучшить UX продуктов, но и решить кое-какие фундаментальные проблемы их разработки.

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

Персоны и User Story — это такая прикольная штуковина для того, чтобы погрузить всех участников в проектный процесс, выявить и подсветить истинные задачи пользователей. Однако сами по себе персоны практически не влияют на процесс создания продуктов, лишь на их функциональность. Чего нельзя сказать о следующем этапе развития пользовательских историй — о User Story Mapping.

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

Проблемы

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

Требования к продукту плохо структурированы по отношению друг к другу

Нет иерархии и последовательности требований. Не всегда понятно, какая задача какую блокирует и от какой зависит. Чаще всего зависимость задачи проставляется исключительно командой разработчиков или тимлидом — но они не владеют общим видением продукта, руководствуясь только своими представлениями о локальном участке архитектуры. То есть они не видят всю связь, весь flow бизнеса и пользователя целиком. Не тот уровень абстракции.

Это, разумеется, влияет на глобальную архитектуру, на качество кода и самого продукта, на динамику разработки. Что, в свою очередь, приводит к многократному увеличению стоимости поддержки и развития.

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

Требования к продукту не приоритизированы с точки зрения ценности для пользователей

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

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

Последствия в этом случае весьма печальны, вплоть до полной невостребованности продукта аудиторией.

Отсутствует единое понимание стратегии разработки, последовательности и состава релизов

Отсутствие стратегического подхода влечёт за собой не только архитектурные ошибки (опять), но и заставляет нервничать стейкхолдеров и владельцев продукта. Прогнозы в такой ситуации строить крайне сложно.

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

Кто-то мне скажет, что это не всегда возможно. Часто исследования идут бок о бок с разработкой. Те же гибкие методологии, в конце концов. Однако даже здесь нужно опираться на определённый фундамент, базис. Ну и кроме того, гибкие методологии имеют весьма ограниченный ореол применения.

Функциональные границы проекта очерчены слишком высокоуровнево или даже вовсе отсутствуют

Бизнес требует внедрения всё новых фич, разработка затягивается, бэклог растёт, команда выгорает. Продукт получается, мягко говоря, странным.

Случалось ли у вас, что клиент/начальник/инвестор начинал каждую неделю приносить новые функции в проект? И обычный вначале лендинг в итоге превращался в космолёт-монстр, с админкой, функцией телепортации и собственным мобильным приложением?

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

User Story Mapping

Как я уже сказал, все эти проблемы (и не только) решают карты историй. Вот вам хорошее определение USM:

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

Крис Симс (в переводе Ольги Жолудовой и Рината Шайхутдинова)

По факту, карта историй — это набор упрощённых User Stories: собранные, отсортированные и приоритизированные. Сама методология простая, на высоком уровне с ней справится даже новичок. Но если копнуть глубже, то там окажется целое поле работы для исследователей, продактов и архитекторов.

В этой статье в качестве иллюстрации для составления USM мы будем использовать небольшую браузерную игру с программой лояльности какого-нибудь банка. В ней есть регистрация, игровой персонаж, его убежище, сражения и баллы лояльности.

Следующие ниже изображения-схемы могут быть не очень хорошо читаемы на небольших экранах мобильных устройств. В этом случае рекомендую посмотреть их на десктопе или перевернуть смартфон в «ландшафт».

Шаг 1. Выявляем активности

Сначала нужно собрать список основных активностей пользователей. В нашем примере игры их пять:

1. Регистрация и логин;
2. Работа над аватаром;
3. Работа над убежищем;
4. Участие в сражении;
5. Работа с баллами лояльности.

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

Шаг 2. Разворачиваем активности в задачи

Теперь мы раскладываем их (активности) на задачи. Например, активность «Регистрация и логин» превращается в три задачи:

1. Регистрация и логин через соцсети;
2. Регистрация и логин через e-mail;
3. Восстановление доступа.

Заметьте, здесь нет отдельно «логина» или «регистрации». Это более глубокий уровень, задачи же — это такие «категории» пользовательских историй. В функциональной архитектуре это тоже функциональные разделы, но уже не глобальные, а обычные.

Шаг 3. Задачи детализируем до конкретных историй

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

• ценность для пользователей;
• ценность для бизнеса;
• сложность реализации.

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

В случае нашего примера, задача «Регистрация и логин через e-mail» разложилась на 2 истории:

1. Регистрация с помощью e-mail;
2. Логин через e-mail;

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

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

Шаг 4. Делаем из приоритетов схему релизов

Напомню, что истории — это всего лишь функции будущей системы. Понимая это, мы просто переносим те истории, которые не критичны или требуют на этом этапе слишком много ресурсов, в следующий релиз. Точно так же можно выделить MVP.

Например, нам проще сделать логин и регистрацию через соцсети — и регистрацию через e-mail мы отодвигаем на второй релиз. Пользователям не так важна покупка амуниции — и она тоже вылетает из MVP.

Дополнительно: цветовая индикация и структура

Принято разделять USM на две структурных части:

1. Верхняя часть, с активностями и задачами, называется «backbone» (хребет), но я предпочитаю слово «скелет».
2. Нижняя часть, истории, называется «тело».

И да, цветом стикеров можно помечать отдельные категории событий/действий, дополнительную важность (например, для бизнеса), типы пользователей и так далее. Всё, что посчитаете важным.

Итог

С помощью User Story Mapping можно не только планировать новые продукты, но и улучшать уже существующие — например, приоритизировать бэклог.

USM позволяет на очень простом визуальном языке донести до всех участников команды не только функциональный состав продукта, но и порядок проектирования и реализации. Если вы хотите выполнить глубокое функциональное проектирование будущего продукта, то User Story Mapping — отличное начало для этого.

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

Запись User Story Mapping и функциональная архитектура первой появилась на Павел Шерер.

Так почему же сейчас этот метод так непопулярен? Почему на каждом углу кричат, что методология не работает, что персонажи устарели? А, главное, к чему апеллируют все эти люди? Давайте разбираться.

Начнём с основ.

Немного истории

Купер не был первым, кто использовал термин «персона» применительно к роли личности. Более ста лет назад это сделал Юнг, но суть его была несколько иной, разумеется. Затем термин плавал, видоизменяясь, пока в начале 21 века не попал в золотые руки Алана, а затем — в грязные лапы глобализации. Но давайте по порядку.

1912-1916

Карл Густав Юнг переопределяет понятие «архетипы». Здесь «персона» — это «маска», социальная роль, компромисс между индивидуумом и социальностью. В одном человеке всегда сочетается несколько таких «персон» — это основа подхода.

1995-2009

Алан Купер во время работы с компанией Sagent Technologies, а затем и в нескольких книгах, формирует метод выявления и использования «персон» для улучшения пользовательского опыта и, как следствие, улучшения продукта. Купер говорит об эмпатии, о том, что только поняв пользователей, можно придумать, как решить их задачи в продукте.

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

2010-2015

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

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

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

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

2016-2020

Кажется, уже последний гвоздь в крышку методологии забивает Клейтон Кристенсен, автор методологии Jobs To Be Done.

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

Глобализация, рост технологий и big data тем временем продолжают снабжать маркетологов, дизайнеров и исследователей всё новой информацией. Которую многие из них лопают без разбора.

Мусорные войны

В итоге, мы получаем печальную картину: в широких дизайнерских массах JTBD явно заменяет персонажей. Но причина тому вовсе не в том, что персонажи плохие — просто к этому времени способ их создания стал настолько неряшливым, что сама методология в общественном сознании обратилась чем-то простым. Слишком незатейливым, чтобы быть правильным.

И вот тут начинается самое нелепое. Люди, которым всегда нужен кто-то, против кого дружить, объединяются и начинают как из автомата строчить однотипные «разгромные» статьи, в которых главным доводом против придуманного Купером подхода то и дело всплывают фразы вроде «ну и как то, что Вася курит, поможет нам продать ему пиццу?». Вы вообще понимаете, что происходит? Думаю, да. Но я всё равно расскажу.

Шаг 1

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

Тут мы пока что всё делаем правильно.

Шаг 2

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

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

Шаг 3

Начинаем применять персон и вдруг понимаем, что «вредная привычка Васи не помогает нам продать ему пиццу»!

Profit, метод дискредитирован. Мы молодцы.

Итог

Кажется глупостью, но это происходит именно так. Горе-исследователи сперва набивают персонажей всяким дерьмом, а потом предъявляют это в качестве неоспоримого доказательства несостоятельности методологии.

Мне одному кажется, что здесь что-то не так?

Совокупность

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

Без сомнения, персоны не всеобъемлющи. В современных реалиях, в условиях постоянного усложнения продуктов и технологий, полагаться на одни только короткие описания усреднённых пользователей — явно маловато. Просто это не «серебряная пуля», и использовать персонажей нужно в совокупности с другими методами — хотя бы с тем же Jobs To Be Done.

А не гоняться каждый год за новыми модными фреймворками (хотя и посматривать, конечно, в их сторону).

Примеры

Куда ж без них. Ниже можно посмотреть на пример простых (очень простых) персонажей, в которых нет ни капли лишней информации. Тут и контекст, и задачи, и особенности. Можно было бы даже фотографии убрать, но они полезны для эмоциональной привязки.

Руководствуйтесь здравым смыслом, а не хайпом. Купер тоже так делает.

Запись Персонажи по Куперу: как дискредитировать методологию первой появилась на Павел Шерер.

О чём статья

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

Типизация

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

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

Информационные архитекторы, чаще всего, выполняют свою работу «по наитию» (разумеется, называя это «логикой» и «опытом»). Наверное, в этом нет ничего плохого или критичного — так делают все, и даже сложные продукты как-то создаются, живут и развиваются. Однако мы же хотим сделать мир лучше и совершеннее, не правда ли?

Пример проекта

У нас есть реальный проект, работа над которым ведётся прямо сейчас, пока пишется эта статья. Проект некоммерческий, никаких NDA. Плюс, он попутно выполняет некоторые образовательные цели — на нём обкатывает навыки информационного и функционального проектирования талантливая Евгения Шамрай.

Информационная структура

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

Если попробовать изобразить иерархию сущностей графически, то получится что-то вроде этого:

1. Инфоблок — самая низкоуровневая сущность, «молекула» информационной архитектуры, содержащая произвольную информацию (например, текст, цитату, изображение и тп). Из инфоблоков, собственно, и строится почти вся контентная часть продукта.
2. Год — статическая среднеуровневая сущность, которая объединяет инфоблоки в разрезе определённых лет. Они единые для всех композиторов, но конкретные годы у конкретных композиторов могут не совпадать.
3. Период — уникальная для каждого композитора среднеуровневая сущность, проходящая через все слои и объединяющая годы в определённый этап жизни композитора.
4. Слой — статическая информационная сущность, объединяющая разные периоды в некий тематический срез творчества композитора. Слоёв ограниченное количество, они обязательны и одинаковы для всех композиторов.
5. Композитор — высокоуровневая, главная сущность проекта.

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

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

Навигационная модель

Схема навигации в примере максимально простая:

• Есть главная страница, на ней перечислены композиторы.
• Внутри раздела каждого композитора есть список слоёв.
• Каждый слой представлен отдельной страницей, на которой в иерархическом порядке расположены периоды, а в них — годы.

Внутри каждого года может находится произвольное количество инфоблоков — я не стал их отображать на схеме, чтобы не усложнять восприятие:

Под капотом

Важно понимать, как именно будет работать наша система — без этого зачастую невозможно выяснить все свойства и связи сущностей. Здесь мы уже одной ногой ступаем на зыбкую почву дизайна данных, но без этого никак. Мы должны построить схему обмена и формирования информации в нашем продукте.

В нашем случае логика такова:

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

Как же происходит сортировка? Здесь тоже всё просто:

1. все инфоблоки разделяются на периоды;
2. периоды сортируются по порядку;
3. внутри периодов происходит объединение инфоблоков по годам;
4. годы также сортируются по порядку внутри периодов;
5. внутри каждого года по порядку сортируются сами инфоблоки.

В результате в браузер пользователя прилетает многомерный массив, который потом просто разбирается на странице.

Связи сущностей

Как я уже говорил, все сущности связаны. Но связь эта не всегда прямолинейна.

Чтобы связать информационные элементы, к одной сущности нужно прикрепить ссылку на другую. В нашем случае — к «дочерней» нужно прикрепить ссылку на «родительскую». Делать это правильнее (и проще) всего как раз с помощью идентификаторов.

• Композитор — главная и независимая сущность.
• Слои единые для всех композиторов и вообще — для всего проекта, они ни от чего не зависят.
• Период у нас уникален для каждого композитора, а значит, ссылается на него (имеет в своих свойствах идентификатор того композитора, которому принадлежит).
• Годы тоже едины для всего проекта, независимы от остальных сущностей.
• И только инфоблоки, как низшая сущность, зависят от всех остальных информационных элементов системы. У них в свойствах прописаны идентификаторы всех остальных сущностей.

Вот так выглядит схема зависимостей в нашем примере:

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

Проблема

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

Какая здесь появляется проблема? Мы должны спроектировать хранение связей в инфоблоке таким образом, чтобы добавление новых сущностей и связывание их с инфоблоками (как минимум с ними) не вызывало особенных проблем.

Как такое проектирование происходит обычно? А никак. Когда добавится новый тип сущности, к инфоблоку в базе данных просто будет добавлено новое поле. У каких-то инфоблоков оно будет заполнено, у каких-то — нет. Где-то в интерфейсе будет обрабатываться его отсутствие, где-то — не будет. Где-то на странице вывалится ошибка, где-то пользователь обматерит очередное обновление, где-то тестировщик обольётся кровавыми слезами.

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

Решение

А решения нет. По крайней мере, однозначного.

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

Боюсь, я вас запутал. Давайте немножко упрощу.

У нас, казалось бы, два варианта:

1. Хранить каждую связь в конкретном свойстве инфоблока. Это в IA — признак «строгой» или, по другому, «сильной» типизации.
2. Хранить все связи в одном свойстве, массивом. Обычно это отличает «слабую» типизацию.

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

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

Излишне сильная типизация в разы увеличит стоимость поддержки и развития продукта. Разработчики будут ещё сильнее, чем обычно, материть проектировщика/архитектора. Время внедрения и отладки даже маленькой новой фичи станет сопоставимо с операцией Барбаросса в 1941-ом (и, вероятно, закончится так же, — провалом).

Настоящее решение

Грамотный и осознанный баланс — вот залог действительно качественного продукта. Это в полной мере касается и информационной архитектуры.

В нашем случае я выберу комбинированный подход:

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

В следующей статье разберём подробно, что же такое информационная сущность и из чего она состоит.

Запись Информационная архитектура: пример и типизация первой появилась на Павел Шерер.

Что такое IA

Очень ёмко об информационной архитектуре высказался Алексей Бородкин, основатель Гильдии Вольных Проектировщиков:

Это описание связи всего со всем!

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

Грамотная информационная архитектура упрощает поддержку и развитие продукта, улучшает UX:

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

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

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

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

Этапы создания IA

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

Подготовка

Работа над информационной архитектурой начинается сильно позже старта проектирования. Сперва определяется концепция, суть продукта. Нам нужен базис, от которого мы уже начнём выстраивать IA.

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

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

Декомпозиция

На этом шаге мы разбираем проект на отдельные информационные сущности. Каждая такая сущность обладает определёнными свойствами. Некоторые сущности могут быть вложенными (каталог и товар, например), некоторые — независимыми.

Итак, пусть в нашем примере будет только 5 сущностей:

1. Страница (статические сущности, содержащие какую-то информацию; например, страницы «О компании», «Доставка и оплата»).
2. Товар (да, обычный товар с описанием, фоточками, ценой и тп).
3. Каталог (внезапно, но каталог — это тоже сущность; у него есть свои свойства, вроде параметров поиска или уровня вложенности).
4. Корзина (которая обладает динамическими свойствами: вложенные товары и их количество, скидки, даже связь с конкретным пользователем).
5. Пользователь (тут всё понятно: как минимум, у пользователя есть регистрационные данные, адрес доставки и платёжные реквизиты).

Конечно, даже в самом простом e-commerce этих сущностей больше, а их свойства разнообразнее. Однако мы помним, что это пример, да? Для простоты мы в дальнейшем даже не будем детально разбирать почти ничего, кроме самих «товаров».

Важная оговорка: в контент-проектах «Страница» — полноценная контент-сущность, но в UX-лексике «страница/экран» — это UI-представление, и она не равна сущности домена. Подробнее об этом будет в третьей статье цикла.

На этом и последующих этапах присутствуют некоторые пересечения с дизайном данных, это не страшно и не противоречит концепции информационной архитектуры. Если проектировщик/архитектор хороший, он совмещает оба направления, экономя ресурсы компании.

Классификация

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

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

Для нашего примера классификация задач пользователя будет очень простой:

1. Найти товары (с помощью поиска, фильтрации и сортировки).
2. Сравнить товары (выбрать наиболее подходящий вариант).
3. Почитать про товары (ознакомиться с характеристиками).
4. Купить товары (положить в корзину, оплатить и ждать доставку).

Как видите, все действия напрямую связаны с товарами, и опосредованно — с остальными сущностями (например, поиск товара осуществляется в каталоге, а покупка — в корзине).

На этом шаге мы также определяем все возможные варианты и способы манипуляции с нашими сущностями: определяем, как будет осуществляться поиск, по каким параметрам мы будем сортировать товары и так далее.

B. Классификация информационных сущностей — ещё один обязательный этап. Вся информация, которую видит пользователь, должна быть структурирована. Страницы должны объединяться в разделы, товары — в категории. И те, и другие должны быть доступны для поиска, а последние — ещё и для сортировки. У товаров могут быть общие свойства, вроде скрытых от глаз пользователя «тегов/меток» или доступных для просмотра «размеров».

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

Но для начала немного терминологии:

• таксономия — это управляемая схема классификации;
• термины — атомы таксономии.

Например, таксономия «Размер» может содержать несколько терминов: «XXL», «XL», «L», «M», «S», «XS».

В реальных продуктах часть терминов обрастает свойствами и становится «почти сущностями» — это нормально, фиксируем это явно.

В нашем примере добавляем три таксономии и одно общее свойство:

1. Категория (иерархическая таксономия сущности «товар»).
2. Метка (не-иерархическая таксономия сущности «товар»).
3. Размер (не-иерархическая таксономия сущности «товар»).
4. Цвет (общее свойство для всех экземпляров сущности «товар»).

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

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

Выявление связей

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

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

Плоские связи в нашем случае — это связь терминов таксономии «метки» между собой. У них нет родителей, они «равны». Или связь товаров с одинаковыми «метками» — она тоже плоская. Кстати, связь самого товара с меткой — тоже плоская.

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

Иерархия сущностей — вообще отдельная песня. У хорошего архитектора почти все сущности в проекте делится на высоко-, средне- и низкоуровневые.

Фиксация свойств

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

Мы знаем, что у товаров есть как минимум 10 свойств:

1. Идентификатор (внутренний, в базе данных, он есть у каждой сущности и термина таксономии).
2. Артикул (внешний, для обмена данными, например, с системой складского учёта).
3. Название.
4. Описание.
5. Основное изображение (используется в карточке товара в каталоге).
6. Дополнительные изображения (используются в галерее изображений на странице товара).
7. Цвет (общее свойство для всех товаров: оно не «сквозное», как метки и категории, а может быть уникальным для каждого товара — например, «синий с белым узором»).
8. Размер (прикреплённый термин таксономии).
9. Категория (прикреплённый термин таксономии).
10. Метки (несколько терминов таксономии, на основе которых будут показываться «похожие» товары).

При этом мы знаем, что свойства 8 и 9 являются «ссылками» на конкретный термин таксономии, а десятое свойство — даже на несколько таких терминов.

Таким образом, мы составили информационную модельку нашего товара. Мы молодцы.

На самом деле, конечно, не всё так просто. И в третьей статье цикла мы немного углубимся в тему свойств сущностей. Например, добавим понятие «контролируемый словарь», «фасет» и другие.

Схематизация

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

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

Вот только без грамотного отчуждения практически любые знания бесполезны. Всё, что получилось выяснить, сопоставить и придумать во время работы над информационной архитектурой, должно быть зафиксировано в документации. В случае с IA эта документация состоит, по большей части из разного рода схем. Здесь и перечень/описание сущностей и их свойств, здесь взаимосвязи, задачи, операции и так далее. Самые крутые даже описывают предполагаемую программную реализацию, миксуя информационную архитектуру с дизайном данных.

Важно: информационная архитектура описывает «что и как связано» (сущности, свойства, таксономии), а навигация — «как по этому двигаться» (меню, крошки, фасеты, поиск).

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

Напоследок

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

Запись Информационная архитектура: краткий экскурс первой появилась на Павел Шерер.

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

Но не всё так просто.

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

UPD: спустя год (09.2020)

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

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

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

Почему регистрация

В большинстве сервисов регистрация — это первый серьёзный шаг пользователя на тернистом пути к целевому для бизнеса действию. От того, насколько идеально будут работать логин, регистрация и восстановление доступа, зависит конверсия; это даже объяснять не нужно.

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

Проблема

Однако почему же тогда регистрация на большинстве сервисов отнюдь не идеальна?

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

1. Что произойдёт, если Facebook, с помощью которого регистрируется пользователь, не вернул e-mail?
2. Что делать, если соцсеть вообще отвалилась и не работает (например, кто-то из админов поменял конфиги)?
3. А если соцсеть при регистрации вернула e-mail, который уже есть в базе?
4. Как быть, если пользователь восстанавливает доступ, но у него нет пароля, так как он создавал аккаунт через ВКонтакте?
5. Нужно ли при попытке регистрации или восстановления доступа напоминать пользователю, что он уже регистрировался через Twitter?
6. А можно как-то заранее сообщить пользователю (ещё до нажатия кнопки входа), через какую соцсеть он входил в прошлый раз?

И ещё тьма вопросов. Все они относятся к бизнес-логике, интерфейсам и юиксу. И очень часто некоторые из них попросту обходятся дизайнерами. Разработчики тоже не боги. Они сперва делают то, что описано; потом — то что принесли тестировщики; потом — то, до чего додумались сами; а затем — чинят то, что поломали предыдущие два шага. И в части этих работ они уже не обращаются к дизайнерам, а делают «по аналогии». Понимаете, что происходит в такие моменты? Да, UX валится к чертям. Потому что красное сообщение о том, что «пароль не подходит» следовало бы заменить на синенькое «не тупи, ты регался через фэйсбук, у тебя нет пароля».

Не решение

Окей, допустим, нам попался реально умный дизайнер. Он описал все эти случаи. Все негативные сценарии, нулевые состояния, все экраны и валидации. Как он это сделал?

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

А общался ли наш дизайнер с разработкой, чтобы пощупать серверную логику и выяснить, можно ли вообще сделать так, как он описал — или это космически дорого и долго?

Он не подумал, что какие-то части могут быть общими для разных сценариев? Это здорово бы упростило (читай «удешевило») разработку. Хотя бы потому, что не всегда разработчик может (и будет) выходить на более высокий уровень абстракции — чаще всего он занят конкретной узкой задачей и не соотносит её с остальными. Или делает это не сильно тщательно.

Решение

Все эти проблемы разом убивает всего один-единственный документ. Вернее, одна диаграмма. Функциональная схема.

В ней можно описать:

• действия пользователя (белые блоки);
• действия системы на клиенте (серые блоки);
• действия системы на сервере (синие блоки);
• негативные события (красные блоки);
• позитивные события (зелёные блоки);
• условия перехода от действия к действию (жёлтые ромбы);

Все переходы в рамках одного компонента (сервера или сайта/мобильного приложения) мы будем показывать простыми линиями, а переходы между компонентами (например, передачу информации на сервер) — пунктирными.

Отдельно укажем точки входа и выхода из сценариев. А мелким текстом над некоторыми блоками даже укажем названия и состояния относящихся к ним экранов!

Красота же, да?

Пока рисовали, вспомнили про что-то ещё, дополнили. Через два дня подошли, посмотрели, увидели прореху — залатали. В итоге сделали немного сложную, плохо читаемую, но полную и наглядную функциональную диаграмму логина, регистрации и восстановления доступа.

Тут у нас и путь пользователя, и логика поведения системы, и обработка всех негативных и спорных сценариев, и общие функции (например, запись в БД данных о входе и отработка успешной аутентификации), и указание конкретных экранов и их состояний.

Посмотрите внимательно. В нашей диаграмме есть несколько простых решений, которые почти никто не использует — хотя они напрашиваются сами. Например, если у пользователя сохранились куки соцсетей, но протух ключ авторизации, мы можем показать ему его аватарку рядом с иконкой соцсети, через которую он входил. Или после попытки регистрации через e-mail подсказать, к какой соцсети этот e-mail привязан. Или сделать аккаунт пользователя безопаснее, деактивируя после использования его ключ из письма с восстановлением доступа (увы, многие разработчики просто забывают это реализовать).

Сценарии

Давайте пойдём дальше и сделаем нашу чудо-схему несколько более удобной для восприятия — ведь от того, насколько она будет читаемой, зависит качество её понимания и реализации программистами.

Для этого будет достаточно лишь подсветить конкретные сценарии — хвала богам, у нас их всего четыре:

• обычная регистрация через e-mail;
• регистрация через соцсети;
• вход в аккаунт;
• восстановление доступа.

Я не стану детально описывать особенности и решения каждого сценария — они прекрасно понятны из самих диаграмм. Если у вас возникли вопросы — пишите в комментариях.

Обычная регистрация

Регистрация через соцсети

Вход в аккаунт

Восстановление доступа

Это не идеальная регистрация

И эту схему можно улучшать бесконечно.

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

Но все продукты разные, и требования везде также отличаются. То, что я вам показал — это реальное проектное решение, со всеми присущими ему проектными ограничениями и особенностями. К примеру, здесь форма логина открывается в модальном окне — а у вас она может быть на отдельной странице. В любом случае, вы можете взять это решение и спокойно модифицировать его под себя.

Исходники

Понятно, что ценность этой статьи была бы невысока, если б я не предоставил исходников диаграммы. Собственно, вот.

В архиве:

1. исходник диаграммы (делал в draw.io, так как работал в Confluence);
2. все диаграммы в SVG и JPG с подсветкой конкретных сценариев из этого поста.

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

Запись Регистрация и логин на стероидах первой появилась на Павел Шерер.

В общем, да, грустная тогда вышла история. Инженер наш даже запил немножко. Недельку. Его бы уволили, но на предприятии никто не знал, в какое место надо засовывать перфокарты — и его оставили, просто лишив премии. Но премия была небольшая, так что он не сильно и расстроился. Вообще, зарплата инженера тогда была не ахти, не то что сейчас. Хотя тогда и цены были другие. А вот продуктов не было — один только дефицит в каждом магазине. Инженер вообще был доволен, что нашел такую жену, которая в общепите работает. Сами понимаете, о таком писать не принято, но с едой у них в доме проблем не было. Мурзилке (это собаку так звали, которая на даче ощенилась, из-за чего инженер пытался взять отгул, но ему не дали и он запил) вообще повезло — жена (инженера, не Мурзилки) каждый день что-нибудь, да и приносила с работы.

Это — история

И она не про Мурзилку, не про инженера с женой и не про расхищение социалистической собственности. Эта история про проектирование.

Хотя так себе история, надо признаться. Да что там, чушь полная. Хотел поведать о том, как нелегко было инженеру в ту пору сформировать архитектуру даже простой программы, но в какой-то момент… Что произошло вообще? Да все просто: мелочи, детали и нюансы погребли под собой суть. Причем так ловко, что та даже опомниться не успела.

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

Примерно такая же ситуация возникает и при попытке сформировать/сформулировать требования к разработке ПО. Вы можете быть суперкрутым спецом в своем деле, но если вас ненавидит проектная команда, какой в этом прок? А если ей придётся продираться через сбивчивый документ в 300 страниц — она вас возненавидят, гарантирую.

Все делают это

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

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

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

Нафига писать рассказ, который никто никогда не прочтёт? Или прочтёт с явным трудом, как инструкцию к старой микроволновке? Рассказ должен читаться легко, оставаться в памяти надолго, читатель должен жалеть, что рассказ кончился. Так и с документацией.

О боги, сколько я за свою жизнь видел техзаданий, концепций и диаграмм, которые никто, кроме их создателя, не может прочесть! А спустя полгода-год — уже и сами создатели с трудом их осиливают. Такая документация становится «вещью в себе», она существует вне нашего восприятия. Не надо так делать.

Видите картинку сверху? Она создавалась Мариной Пустовит с целью структурировать у себя в голове всю имеющуюся информацию по данным проекта. Такие запутанные схемы ни в коем случае нельзя передавать разработчикам и, тем более, клиентам. Мир и так не идеален, не стоит делать его хуже, а людей — грустнее.

Помните, что у проектной документации тоже есть пользователи. Рассматривайте её как отдельный внутренний продукт.

Ваша документация должна быть понятной, однозначной, отчуждаемой. Она должна быть, чёрт возьми, интересной! Это ведь действительно не очень сложно. Мы придумываем удобные интерфейсы (и не важно, UI или API) — но даже не пытаемся понять тех, кто реализует то, что мы там напридумывали.

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

8 советов

В итоге я собрал несколько правил и хаков, упрощающих «впитывание» информации членами проектной команды (да и клиентами, чего уж там).

Часть из этих советов я подсмотрел у других дизайнеров, часть выработал сам, а часть всплыла в ходе моего недавнего микро-опроса на фэйсбуке (за что отдельное спасибо Астхик Сукиасян, Антону Григорьеву и Виталию Мазуревичу).

Разумеется, это никакой не чеклист. Используйте только те пункты, которые применимы к конкретному проекту и конкретным условиям. Включайте голову, в общем.

Плавное погружение

Самый важный пункт по версии моей бабушки.

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

Делайте погружение в документацию плавным. Сперва расскажите основную информацию о проекте: краткое описание, задачи, ЦА, ключевую механику. Опишите базовые компоненты, состав сервиса, какие-то особенные технические или бизнес-требования. Очертите границы проекта.

У меня даже есть специальное слово для такого «вводного» документа — концепция. Обычно это небольшой документ на 3-4 страницы (зависит от сложности проекта) с очень чётким оглавлением и содержанием. Иногда уже одного этого хватает, чтобы тот же разработчик задал вам потом в миллион раз меньше вопросов. А уж клиенту/заказчику этот документ необходим как воздух.

Современные инструменты

Перестаньте использовать MS Office и файлики с макетами. Мир прекрасен и удивителен — и в нём есть куда более гибкие и подходящие для документации инструменты.

Интерактивные схемы, встраивающиеся прямо в страницы с текстом; перекрёстные ссылки на разделы; макросы и динамические содержания конкретных частей; краткие выжимки из разделов — это и многое другое откроется вам, как только вы начнёте использовать современный инструментарий. Просто представьте себе, насколько приятнее (и быстрее) нажать на статическое изображение и сразу открыть интерактивную user story, чем прочитать что-то вроде «более подробно схема представлена в рис. Польз_история_1_ (версия_5).jpeg в папке user_stories на Google Drive».

Хороших инструментов много, никто не мешает вам их совмещать и комбинировать, пока не найдёте идеального для вас варианта. Я лично предпочитаю Confluence (с десятком полезных плагинов) в связке с Axure и Figma. Но иногда не пренебрегаю и обычными гуглдоками (если их правильно приготовить, конечно).

Структурирование

Есть одна простая штука: в проектной документации нарратив не работает. Если у вас проект чуть сложнее лендинга, то разработчик (маркетолог/сеошник/клиент) будет скакать по разделам, как кузнечик по углям. Дайте ему возможность делать это легко и естественно.

Чёткая и (главное) понятная структура документации — залог её эффективного использования. Причём это касается как самих документов, так и разделов, в которых они лежат.

Пользователь (мы же помним, что у документации тоже есть пользователи, да?) должен иметь возможность найти любое место в доках буквально за 5 секунд.

Вот так выглядит примерная структура разделов у меня в Confluence (первые два уровня):

• Roadmap
• Текущее состояние
  • Требуется уточнение
  • Требуется проработка
  • Требуется локализация
  • TODO
  • Следующие итерации
• Словарь терминов
• Концепция
• Компоненты
  • Мобильное приложение
  • Сервер
  • Админпанель
  • Сайт
• UX/UI
  • Аудитория
  • Сценарии
  • Навигационная модель
  • Прототип
  • Screen Flows
  • Дизайн-макеты
• Entities
• Functions
  • Fn.Mobile
  • Fn.Server
  • Fn.Admin
  • Fn.Site
• API
  • Философия API
  • Словарь ошибок API
  • API.Mobile
  • API.Admin
• Databases
  • Db.Mobile
  • Db.Server

Разумеется, эта структура меняется от проекта к проекту — и об этом следующий пункт.

Контекст использования

Все команды и продукты разные. Если вы однажды нашли подходящий формат документации для одного проекта — не факт, что он станет таким же идеальным для другого.

Высокотехнологичные стартапы требуют более проработанной архитектуры, чем e-commerce на Битриксе. Команды, выполняющие типовые задачи (вроде того же e-commerce), наверняка уже знакомы с их базовыми UX-особенностями. Фрилансерам или удалёнщикам желательно расписывать всё максимально подробно — тогда как для остальных эта информация может оказаться избыточной.

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

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

Унификация формулировок

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

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

Словарь терминов

Незаменимая штука при соответствии любому из двух условий:

• в проектной команде меняются люди;
• проект необычный или сложный;

В первом случае это не обязательно обусловлено текучкой. Если проект долгий, менять разработчиков раз в квартал/полгода — нормально, защищает от выгорания. Имея словарь терминов, вы снижаете порог входа новых людей в проект.

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

Вообще, я бы рекомендовал заводить словарь терминов на всех проектах сложнее лендинга. А уж если вы научите свою документацию подсвечивать термины и выдавать определения, не сходя со страницы — спасибо вам скажут все: от разработчика до уборщицы.

Вот, например, специальный плагин такого словаря для Confluence.

Удобочитаемость

То, что сейчас принято называть «UX текста».

Разбивайте текст на абзацы, выделяйте важные места. Не пишите слишком длинных предложений, используйте переходные слова. Если где-то в проектной логике есть условия, делайте из них список (а лучше — диаграмму). Подзаголовки — наше всё.

И ради всего святого, не используйте канцеляризмы. Пишите простым языком, вы не на юридический поступаете.

Ну да на эту тему написано уже много, не стану повторяться. Если интересно, посмотрите на индекс удобочитаемости Флеша и индекс туманности Ганнинга — математика, конечно, но с неё можно начать.

Пасхалки

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

Когда был в агентстве, то вставлял в доку пасхалки. Например: при нажатии кнопки Звезда Смерти взрывается. Если я видел, что ТЗ согласовано с ними, то ловил на том, что его не читали. Однажды в ответ на такое ТЗ мне заказчик прислал правки, где фраза про Звезду Смерти была прокомментирована так: И Дарт Вейдер переходит на светлую сторону Силы.

Виталий Мазуревич

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

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

Завершение

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

Неактуальная документация может здорово снизить динамику разработки, а то и вовсе похоронить проект. Некоторые разработчики (заказчики/маркетологи) с радостью вернутся к привычному состоянию — когда можно было не читать.

Но это уже другая история, не про Мурзилку, её хозяйку и их мужа-инженера (который ушел в недельный запой из-за того, что жена утопила пятерых щенков, хотя одного из них он обещал своему начальнику).

P.S. На картинке к посту кубики Чаплыгина, крайне рекомендую для тех, у кого дети учатся читать.

Запись Учим проектную команду читать первой появилась на Павел Шерер.