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

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

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

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

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

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

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

Их ещё называют «справочниками», а разработчики — 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 для решения по сущностям.

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

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

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

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

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

И вот в этот момент происходит выбор.

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

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

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

Антропология страха

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

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

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

Механизмы

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

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

Кто хочет, тот ищет возможности, кто не хочет — ищет причины

Сократ

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

Абстракция и её уровни

Когда нам приходится рассеивать неопределённость, мы, как правило, делаем это очень точечно. Мы начинаем сразу проектировать детали продукта, мыслим картинками и сценариями.

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

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

При чём здесь геймификация

В свое время Ричард Алан Бартл описал модель сегментации игроков по психотипам, и отдельную роль выделил Исследователям (Explorers), которые тщательно исследуют игровой мир, его механики и тайны. В основе их поведения лежит тот же инстинкт «рассеивания тьмы». Не удивительно, что большинство тех, кто занимается аналитикой и проектированием, имеет существенный перекос в сторону именно этого психотипа. Хороший проектировщик не обретёт покоя, пока в проекте есть белые пятна.

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

Запись Антропология старта первой появилась на Павел Шерер.

В этой статье я хочу рассказать о том, как «продолжение» 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 и функциональная архитектура первой появилась на Павел Шерер.

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

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

Аналитическая стратегия

Одна из серьёзнейших проблем в IT – это терминология. Бешеная скорость развития технологий и методик заставляет термины изменяться и вырастать из своих прежних определений. Так было с UX, с персонами, с API и даже с названием множества IT-профессий.

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

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

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

Итак, если с этой частью терминологии мы определились, идём дальше.

Проблема обновлений

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

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

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

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

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

С мобильными приложениями вообще мрак. Допустим, наши разработчики внесли нужные изменения. Они отправляют новую версию на ревью, и она благополучно оседает там на несколько дней, а то и недель. Пока AppStore и Google Play проводят проверку приложения, данные, разумеется, не собираются. И даже после этого пользователи скачивают обновление не сразу, процесс может затянуться надолго. За это время появляются новые требования к сбору, и цикл повторяется.

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

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

Ошибочное решение

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

Во-первых, отправка событий, чаще всего, стоит каких-то денег: например, тот же Amplitude позволяет бесплатно отправлять только 10 миллионов эвентов в месяц. Это только кажется много: если у вас даже 2 тысячи ежедневных пользователей, вы исчерпаете этот лимит, отправив с каждого всего по 170 событий в сутки, включая переходы между экранами.

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

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

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

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

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

Вот как должна выглядеть идеальная схема:

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

Формирование списка претендентов

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

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

Присваивание идентификаторов

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

Опытным аналитикам эта работа во многом уже знакома, но я всё равно о ней расскажу.

Вы можете придумать собственные правила создания таких айдишников, или воспользоваться моими, сформированными на базе событий из Google Analytics:

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

Пример составленного таким образом идентификатора:

user_post_social-share_facebook_235

Приоритизация списка

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

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

Пока что всё знакомо и понятно, да? Первые три шага в той или иной мере выполняет каждый аналитик. Интересное начинается на шаге четвёртом.

Работа с кодом и конфигами

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

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

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

Добавление механизма обновления

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

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

Всё. Теперь, если нам нужно поменять события для отправки, мы просто заменяем/правим конфиги на сервере – и приложение само понимает, что теперь в аналитику нужно слать новые данные. Profit.

Вместо эпилога

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

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

Запись Разгоняем аналитику через систему триггеров первой появилась на Павел Шерер.

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

В любом IT-проекте рано или поздно наступает этап формирования аналитической стратегии. Даже если вы так её и не называете.

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

Главная проблема здесь в том, что чаще всего это происходит именно поздно, а не рано.

Что такое аналитическая стратегия

Как и большинство терминов в IT, этот тоже сильно размыт. Кто-то под АС будет подразумевать аналитику рынка, кто-то – отслеживание нагрузки на серверные мощности и её балансировку.

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

Немного непонятно, да? Давайте расскажу чуть подробнее.

Зачем нужна стратегия

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

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

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

Шесть стратегических этапов

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

Модернизируйте схему, руководствуясь здравым смыслом и логикой.

Определяем конечную цель

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

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

Составляем аналитическую карту

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

Если у вас есть под рукой подробный CJM или UJM вашего продукта, то задача упрощается в разы.

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

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

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

Разделяем внешнюю и внутреннюю аналитики

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

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

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

Формируем систему триггеров

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

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

Определяемся с инструментарием

Крайне важный момент, который многие упускают. Аналитика просто так не собирается. Хорошо, если у вас простой интернет-магазин, и вам достаточно одной только Google Analytics. С мобильными приложениями, например, сложнее. Или с финтехом, в котором вообще подключение внешних аналитических систем крайне не рекомендуется (здесь нужно использовать self-hosted системы, которые собирают и хранят все данные непосредственно на ваших серверах).

Помимо вездесущих Google Analytics и Яндекс.Метрики есть ещё огромное количество других инструментов. Например, Amplitude и Branch для сквозной мобильной аналитики, Matomo для self-hosted решений.

Документируем, администрируем

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

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

Вместо итогов

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

Запись Аналитическая стратегия цифровых продуктов первой появилась на Павел Шерер.

О чём статья

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

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

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

Напоследок

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

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

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

Заранее извиняюсь за некоторую грубость повествования: в выборе выражений я не силен.

Почему перепроектирование — это клёво

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

Бабло

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

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

Аналитика

Первое, что я спрашиваю у клиента перед перепроектированием — это доступ к GTM, Яндекс.Метрике, Branch/Amplitude и тп. И только потом называю финальную оценку своей работы. Если аналитика на старте была настроена грамотно, то 90% гипотез могут быть проверены за несколько минут (пусть иногда и косвенно). И это по-настоящему круто. Вот прям круто-круто.

Реальный случай, из недавнего: клиент заявляет, что пользователи жалуются на сложную форму заказа и это — главная проблема сервиса. Начинаю копать аналитику и понимаю, что с формы заказа отваливается примерно половина пользователей, тогда как со страницы поиска услуг — около 80%. То есть вглубь воронки проходит только 20%, из которых половина валится на заказе. Если даже не делать ничего с заказом, а добиться удвоения прохождения поиска (с 80% до 60%) — это будет равносильно идеальной форме заказа, со стопроцентной конверсией. Конечно, это не значит, что заказ не надо трогать. Это говорит только о том, что мнение клиента попало под влияние «систематической ошибки выжившего»: до заказа доходили только самые упорные клиенты, и они же потом не ленились писать про сложность формы. Они не говорили о траблах с поиском,  просто потому что заказ был их крайней проблемой, а мозг, ленивая скотина, склонен экономить джоули.

Пользователи

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

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

Бизнес-процессы

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

Чаще всего внутренняя часть БП уже настроена, так или иначе обкатана, вычислены узкие места. Не нужно много думать, предполагать, строить монструозные BPML’ки. Чаще всего достаточно взять готовое и оптимизнуть. И это прекрасно, ибо для меня лично бизнес-процессы — самая унылая часть проектирования. Да, она, вероятно, самая важная, но как же выбешивает опрашивать менеджеров колл-центра или по крупицам собирать ценные факты из потока пожеланий какого-нибудь руководителя отдела.

Грабли

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

К граблям, на которые можно наступать неоднократно, относятся:

• неверное определение целевой аудитории, их микропотребностей;
• самонадеянная проработка UX, слабо соотносящаяся с реальностью;
• нюансы финмодели, «просаживающие» прибыль сервиса;
• еще миллион явлений, решений и событий.

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

Техническая составляющая

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

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

Масштабируемость и развитие

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

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

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

Контент

Чаще всего контент — это серьезный геморрой при проектировании. Я уже неоднократно заявлял, почему в макетах не должно быть текста-рыбы. Но иногда реальный контент взять неоткуда. Иногда — но не в случае с перепроектированием. Это же рай: ваш прототип/макет может содержать только реальные данные. Вам не нужно копать в Интернете, подсматривать у конкурентов или что-то выдумывать (увеличивая вероятность «просачивания» левого текста в продакшн). Более того, вы можете составить текстовый кит проекта (!) и требования к контенту. Если не это счастье — то что?

Черные лебеди

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

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

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

Риски перепроектирования

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

Красная кнопка

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

Все считается

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

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

Снова пользователи

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

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

Итог

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

Запись Светлая сторона (пере)проектирования первой появилась на Павел Шерер.