В предыдущей статье мы разобрали способы организации информации и посмотрели, как одна модель помогает решать разные задачи. До этого довольно подробно занимались сущностями, свойствами и связями. Описаний накопилось достаточно, чтобы перейти к следующему вопросу: как пользоваться всем этим в работе над продуктом?
На схеме можно связать товар с категорией, но стрелка не расскажет вам, что делать с незаполненными свойствами. Или как найти товар по привычному покупателю обозначению и куда приведёт старая ссылка после изменений. Эти решения тоже придётся принять.
В заключительной части цикла соберём несколько практических приёмов. Продолжим на примере условного магазина одежды. Все товары, ситуации и персонажи вымышленные.
Проверяйте модель на реальных данных
Для начала возьмите несколько объектов, с которыми действительно работает ваш продукт. В магазине это будут карточки товаров, в редакции — публикации, во внутреннем сервисе — заявки или проекты. Посмотрите, удаётся ли описать их по принятым правилам.
Причём выбирайте не только образцовые записи. Полезно взять объект с незаполненным свойством, неоднозначным названием или устаревшими сведениями. Если продукта пока нет, используйте доступные материалы предметной области, а придуманные примеры отмечайте как гипотезы. Можно подсмотреть у конкурентов или попросить нейронки (но там, разумеется, аккуратнее).
Это нужно, чтобы не допустить расхождений в дальнейшем. В нашем магазине у одной куртки материал указан в отдельном поле специальным кодом, у другой спрятан в описании, у третьей записан как есть текстом, а у четвёртой вообще неизвестен. На схеме у всех есть свойство «Материал». Но наполнить фильтр только по этой схеме не получится: сначала нужно понять, откуда брать значения и насколько им можно доверять.
Здесь стоит договориться о том, кто уточняет материал и можно ли до этого публиковать товар. Если нужных сведений нет, требование заполнить поле само по себе проблему не решит. У редактора может появиться соблазн поставить хоть что-нибудь, лишь бы сохранить карточку. Поведение при неизвестном значении мы уже обсуждали в прошлой части.
Для существующего продукта полезно собрать перечень содержимого и отдельно оценить его состояние. В NN/G эти задачи разделяют на инвентаризацию и аудит: сначала выясняют, что есть, затем — что требует исправления, дополнения или удаления. Начать можно с участка, важного для выбранной задачи, и постепенно расширять проверку.
Результат такого разбора всегда конкретный: вот тут информации не хватает, здесь разные названия одного понятия, а здесь наше правило не подходит к реальному объекту. Теперь понятно, что нужно исправлять — содержимое, описание свойства или саму модель.
Продумайте входы, переходы и адреса
Схема сущностей помогает проектировать навигацию, но готового меню из неё не получается. Например, для «Материала» нам может хватить фильтра, а для «Подборки» понадобится отдельная страница. При этом пункт «Новинки» можно построить как выборку по дате поступления. Само появление нового пункта меню ещё не требует новой сущности.
Проверьте, с каких точек человек может начать работу. Покупатель вполне способен попасть прямо в карточку куртки «Город» по ссылке из сообщения. Он не видел главную страницу и не проходил через каталог. Достаточно ли в карточке информации, чтобы понять, что это за вещь и где посмотреть другие куртки?
А другой покупатель пришёл из отфильтрованного списка. Ему может понадобиться вернуться к сравнению, сохранив условия отбора. Это отдельная задача. Хлебные крошки показывают положение страницы в иерархии; историю посещений и возврат к своим результатам стоит продумать отдельно.
С адресами тоже договоритесь заранее. Например, карточка нашей куртки может жить по условному адресу /products/p-17/. Категории и подборки будут ссылаться на неё. Перенос товара в другую категорию тогда не потребует менять адрес.
Это один из вариантов, а не обязательная схема URL. Можно включить категорию в адрес, но тогда нужно решить, что произойдёт при изменении классификации. Дерево категорий не обязывает копировать всю вложенность в URL. Кстати, Google при определении структуры сайта обычно ориентируется на связи между страницами, а не на вложенность адресов.
Если адрес всё же меняется, предусмотрите переход со старого на новый. Для постоянного переноса страницы используют постоянное перенаправление. Старые ссылки могут оставаться в закладках, сообщениях и других материалах — они не обновятся вместе с вашей схемой.
Договоритесь, что именно делает поиск
В прошлой статье мы упростили поиск куртки «Город» до точного совпадения названия. Для объяснения модели этого хватало, но теперь давайте посмотрим, какие ещё запросы должен понимать наш условный магазин.
Покупатель может искать конкретную вещь по названию, целый класс товаров или сочетание характеристик. Для каждого случая нужно определить ожидаемый результат и данные, по которым его можно получить.
Вот несколько вопросов для проверки:
| Запрос | Что нужно решить |
|---|---|
| «Город» | Как отличить название товара от такого же слова в описаниях других вещей? |
| «куртка» | Должен ли поиск находить товары категории «Куртки», даже если это слово не входит в название? |
| «чёрная куртка» | Учитываем ли свойства товара или ищем только совпадение текста? |
| «ветровка», «бомбер» | Какие товары соответствуют этому обозначению и где это зафиксировано? |
Последний случай особенно полезен. Если в нашей классификации ветровки — разновидность курток, то поиск всех курток по этому слову может дать слишком широкую выдачу. Прежде чем добавлять слово в список синонимов, нужно договориться, какие товары оно обозначает. Сама настройка поиска этого вопроса за вас не решит.
Соберите характерные запросы из обращений, исследований и поисковых журналов, если они уже есть. На их основе решайте, где нужны альтернативные названия, обработка словоформ или подсказки. NN/G рекомендует проверять такие решения на реальных запросах: расширение поиска может помочь найти больше нужного, но заодно добавить неподходящие результаты.
Если вместе с товарами вы ищете статьи и подборки, опишите, как они участвуют в выдаче. Запрос с названием куртки и вопрос об уходе за тканью могут требовать разных результатов. Универсальное «всегда сначала товары» всегда стоит хотя бы проверять.
Отдельно разберите пустую выдачу. Подходящих вещей действительно может не быть. Или нужный товар есть, но поиск не распознал название. Или его исключили выбранные условия. За одинаковым экраном скрываются разные причины.
Покажите, по какому запросу и с какими условиями ничего не найдено. Дайте возможность изменить их. Если предлагаете альтернативы, обозначьте, чем они отличаются от запрошенного. В исследованиях NN/G пользователи принимали похожие ссылки за результаты поиска, когда сообщение об отсутствии совпадений было недостаточно заметным.
Пустая выдача сама по себе ещё не говорит об ошибке архитектуры. Если подходящего товара нет, честный ответ об этом вполне корректен.
Разберите состояния объектов
До сих пор наши товары были доступны покупателю. Добавим изменение: куртку «Город» снимают с продажи. Что теперь должно произойти с её карточкой, результатами поиска и подборками?
Фразы «товар больше не показываем» недостаточно. Не показываем где? Можно ли открыть сохранённую ссылку? Увидит ли карточку редактор? Нужно ли удалить связи с подборками?
Для нашего магазина договоримся о трёх состояниях. В этой упрощённой ситуации опубликованные товары доступны для покупки; складские остатки и резервирование здесь по понятным причинам не рассматриваем.
| Состояние | В каталоге, поиске и публичных подборках | По прямой ссылке для покупателя | Покупка |
|---|---|---|---|
| Черновик | Не показываем | Карточка недоступна | Недоступна |
| Опубликован | Показываем по правилам соответствующей выборки | Карточка доступна | Доступна |
| Архив | Не показываем | Сохраняем карточку с пометкой о снятии с продажи | Недоступна |
Редактор с нужными правами может работать с записями во всех трёх состояниях. Сам товар и его связи при архивировании сохраняем. В блоке рекомендаций тоже будем показывать только опубликованные товары.
Ну и подборки. Раньше для нашего примера было достаточно включения товара редактором. Теперь добавилось условие показа: товар должен быть опубликован. Куртка остаётся связанной с подборкой, но в публичной подборке больше не выводится. Мы изменили правило представления и явно это зафиксировали.
Это выбранная политика магазина. Для другого продукта может потребоваться иное поведение: например, архивная публикация продолжит участвовать в поиске. Название состояния само по себе ответа не даёт.
Вместе с состояниями определите, кто может их менять и что для этого требуется. Если публиковать товар можно только после проверки описания, в модели и процессе должно быть понятно, кто проверяет и что считается завершённой проверкой. Здесь информационная архитектура встречается с функциональной: состав информации связан с допустимыми действиями над ней.
Проверяйте доступность во всех предусмотренных точках входа. Убрать карточку из каталога недостаточно, если по вашим правилам покупатель вообще не должен её видеть, а старая ссылка всё ещё открывается.
Соберите договорённости в удобном месте
К этому моменту уже есть описания сущностей, схема связей, правила выборок и несколько решений о поведении продукта. Посмотрите, может ли другой участник команды найти в них ответ на конкретный вопрос.
Например, дизайнеру нужно понять, как выглядит карточка архивной куртки по прямой ссылке. Разработчику — какие товары показывать в подборке. Редактору — почему товар без указанного материала не попадает в выборку по хлопку. Даже если все перечисленные — AI-агенты.
Если ответы приходится каждый раз добывать в переписке или уточнениях0, стоит поправить организацию самих описаний.
Для нашего примера достаточно связать между собой:
- описание товара, его свойств и отношений;
- правила каталога, поиска, подборок и карточки;
- используемые названия и допустимые значения;
- состояния, права и условия переходов;
- причины решений, к которым может понадобиться вернуться.
Эти сведения могут жить в нескольких связанных документах. Схема будет показывать отношения, таблица — свойства, короткая запись — принятое решение. Выберите место для актуальной версии каждого правила и ссылайтесь на него из остальных материалов. Если скопировать одно и то же условие в несколько мест, при изменении придётся обновить каждую копию. Да и контекст не резиновый, даже с RAG.
Техническую реализацию обсуждайте с разработчиками по мере работы. В нашей модели нужно учитывать состояние товара в каждом представлении по согласованным правилам; способы хранения и обновления данных могут быть разными. Если выбранное решение не позволяет выполнить требование, это повод вернуться к обсуждению. Ограничения системы полезно выяснять по ходу проектирования.
Наконец, главное. Назначьте ответственных за содержание. Кто разбирается с дубликатами материалов? Кто может изменить структуру категорий? Кто обновит правило публикации после согласованного изменения? Для небольшого продукта это может быть один человек или даже скилл для LLM. Важно, чтобы было понятно, к кому обращаться и кто/что поддерживает принятые договорённости.
Фиксируйте изменения вместе с их последствиями
Предположим, редакторы создали два разных значения справочника: «Хлопок» и «хлопок». Для нашего магазина они означают одно и то же, но товары связаны с разными записями. В фильтре появились два почти одинаковых варианта.
Здесь полезно оставить короткую запись о решении. Например:
Объединяем два значения материала, поскольку в нашей классификации они равнозначны. Сохраняем одну запись «Хлопок», переводим на неё связи товаров. При наполнении карточки редактор выбирает существующее значение; создание нового значения проходит отдельную проверку.
После изменения проверяем товары из обеих групп и результаты отбора. Если старое значение использовалось в сохранённых ссылках с фильтром, учитываем и эти ссылки. За справочник отвечает редактор каталога, за перенос связей — разработчик.
Так вы фиксируете решение, его причину и последствия. Этот принцип используется в коротких записях об архитектурных решениях — ADR. Для наших задач можно взять сам подход, без обязательного большого шаблона на каждую правку.
Если два значения действительно различаются по смыслу, объединять их только из-за похожего написания нельзя. Сначала нужно уточнить различие и понять, важно ли оно для задач продукта.
После изменения пройдите затронутый сценарий целиком: от исходных данных до результата, который увидит пользователь. В нашем случае проверьте, что товары сохранили материал, фильтр находит обе прежние группы, а редактор понимает, какое значение выбирать. Если это влияло на поиск, повторите и соответствующие запросы.
После запуска продолжайте смотреть, где люди затрудняются. Анализ поисковых запросов помогает обнаружить расхождение в названиях или нехватку содержимого. Но цифра сама не объясняет причину: частые запросы без результата нужно разбирать, а выбранное исправление — проверять на задаче пользователя.
Напоследок
На этом цикл можно завершать. Мы прошли от выделения сущностей до правил, по которым информация появляется в продукте, связывается, находится и меняется. Дальше попробуйте пройти этот путь на одной задаче своего продукта. Возьмите реальные объекты, проверьте нужные свойства и связи, продумайте способы доступа и исключения. По ходу станет видно, каких решений ещё не хватает и кто должен помочь их принять.
Любая архитектура остаётся полезной только пока вы возвращаетесь к ней при работе над продуктом и обновляете вслед за решениями.
