Как мы проектируем e-commerce: от объектов к опыту

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

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

В Peretz мы подходим к e-commerce иначе. Прежде чем обсуждать Shopify или Laravel, React или Vue, вайрфреймы или дизайн-системы, мы пытаемся понять систему за интерфейсом: бизнес-модель, путь клиента, процесс продажи, контент, логистику и решения, что двигают клиента к покупке.

Только тогда мы решаем, чем цифровой продукт должен реально быть.

Этот подход тесно связан с несколькими устоявшимися методологиями продуктового дизайна, включая Jobs to Be Done, Double Diamond, Object-Oriented UX (OOUX) и Atomic Design. Мы не относимся к ним как к изолированным фреймворкам. Вместе они дают полезные способы формализовать процесс, что мы применяли к цифровым продуктам годами.

Отправная точка всегда одна:

Что этому бизнесу реально нужно от цифрового опыта?

НЕ С ТЕХНОЛОГИИ

Мы не начинаем с технологии

Технология важна. Просто это не первое решение.

Стоит ли проекту использовать Shopify, WordPress, Laravel, headless-архитектуру, React, Vue или другой стек, зависит от того, что продукту нужно достичь, как он будет расти и как будет поддерживаться.

Эти решения становятся гораздо проще, когда понятны лежащие в основе требования.

Наш процесс поэтому начинается с вопросов вроде:

• Кто клиент?

• Что он пытается достичь?

• Как бизнес реально продаёт?

• Сколько занимает решение о покупке?

• Какую роль сайт играет в процессе продажи?

• Какие части пути происходят онлайн, а какие через людей?

• Как маркетинг, продажи, логистика и клиентская поддержка взаимодействуют?

• Что происходит после запуска?

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

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

Цель не скопировать то, что делают конкуренты.

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

Это различие важно.

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

Мы писали больше про проектирование вокруг реальных бизнес-условий, а не предполагаемых, в статье We Design for Reality, Not for Ideal Scenarios.

СПЕЦИФИКАЦИЯ

Спецификация полезна, только когда мы понимаем, что за ней стоит

Клиенты часто приходят с готовой спецификацией.

Тридцать страниц. Иногда больше.

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

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

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

Это отличная отправная точка.

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

Проблема не в том, что есть спецификация.

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

Документ, что говорит "нам нужно 30 страниц", не объясняет, почему эти страницы нужны.

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

А сайт конкурента автоматически не даёт чертёж для другого бизнеса.

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

Это не дополнительный слой бюрократии.

Это часть продуктового дизайна.

ОТ ИССЛЕДОВАНИЯ К ПУТИ

От конкурентного исследования к пути клиента

У успешного e-commerce сайта редко есть один универсальный путь клиента.

Представь двух посетителей одного и того же премиального продуктового сайта.

Один приходит через поисковик, уже точно зная, что хочет.

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

В итоге они могут купить один и тот же товар.

Их пути совершенно разные.

Это становится особенно важным для обдуманных покупок: luxury-товаров, ювелирки, элитной мебели, недвижимости, B2B-продуктов, профессиональных услуг и других покупок, где важны доверие и оценка.

Для этих категорий привычное:

каталог → страница товара → корзина → чекаут

может описывать только часть опыта.

Клиент может вместо этого двигаться так:

бренд → коллекция → история → товар → эксперт → консультация → покупка

или:

поиск → товар → сравнение → исследование → повторный визит → покупка

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

Именно поэтому карта пути клиента для нас не просто UX-документ. Это один из входных данных, что определяет архитектуру самого продукта.

Индустрия тоже важна.

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

Иногда лучший опыт быстрее.

Иногда сам опыт часть того, что покупает клиент.

САЙТ НЕ ПРОДУКТ

Сайт не продукт

Это различие ведёт к более широкому вопросу:

Что именно мы проектируем?

Если думать только категориями страниц, ответ очевиден:

Главная.
Страница категории.
Страница товара.
О нас.
Блог.
Контакты.
Чекаут.

Но бизнесы на самом деле не состоят из страниц.

Они состоят из объектов и отношений.

Товар принадлежит коллекции.

У коллекции может быть история.

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

Магазин может быть связан с локацией.

Эксперт может быть связан с услугой.

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

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

Вместо вопроса:

"Сколько страниц нам нужно?"

мы можем спросить:

"Каковы фундаментальные сущности этого бизнеса, и как они должны взаимодействовать?"

Именно здесь Object-Oriented UX (OOUX) становится особенно актуальным для e-commerce.

OOUX предлагает проектировать вокруг реальных объектов системы, а не начинать с экранов или действий пользователя. Для e-commerce продукта такими объектами могут быть товары, коллекции, материалы, дизайнеры, истории, эксперты, локации или услуги.

Ценность не в использовании аббревиатуры.

Ценность в создании системы, что может точно представить бизнес, а потом переиспользовать эти объекты в разных опытах.

Товару не нужно существовать только на странице товара.

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

Это фундаментально другой способ думать об архитектуре e-commerce.

OOUX И ATOMIC

OOUX и Atomic Design: два слоя одной системы

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

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

Важная идея для e-commerce не в самой терминологии.

Она в том, что страница не первичная единица интерфейса.

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

Именно здесь OOUX и Atomic Design дополняют друг друга.

OOUX описывает, из чего состоит бизнес.

Atomic Design описывает, как интерфейс это представляет.

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

Вместе они дают полезный фундамент для модульной e-commerce архитектуры.

ОРГАНИЗМ НЕ АТОМЫ

Мы начинаем с организма, не с атомов

Есть важный нюанс в том, как мы применяем эти идеи.

Нам нравится Atomic Design, но мы не начинаем с рисования атомов.

Мы начинаем с живого организма.

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

Только тогда мы разбиваем эту систему на переиспользуемые компоненты.

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

Можно создать прекрасно построенную дизайн-систему и всё равно построить неправильный опыт.

Идеально консистентная кнопка не говорит, должен ли клиент видеть кнопку именно в этот момент.

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

Консистентность ценна. Контекст определяет, принадлежит ли компонент здесь вообще.

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

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

ОБДУМАННАЯ ПОКУПКА

Почему это важно для обдуманной покупки

Это различие становится особенно важным при проектировании e-commerce для обдуманной покупки, той же территории, что мы разбираем в статье Why Luxury E-commerce Breaks Every Rule of Conversion Optimization.

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

Клиент, рассматривающий украшение, luxury-товар, недвижимость, дорогую мебель или сложное B2B-решение, может иметь совершенно другой процесс принятия решения.

Ему может понадобиться:

• информация о товаре;

• сравнение;

• происхождение;

• экспертное руководство;

• социальное доказательство;

• техническая документация;

• история за товаром;

• консультация;

• время вернуться и переосмыслить.

Это не обязательно шаги в фиксированной воронке.

Это независимые части опыта, что могут стать актуальными в разные моменты.

Это различие важно.

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

Модульная архитектура позволяет тем же самым лежащим в основе объектам появляться в разных контекстах.

Товар может быть представлен вместе со своей историей.

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

Материал может стать точкой входа в группу товаров.

Эксперт может стать частью пути покупки, а не изолированной страницей "Связаться с нами".

Система становится способной отражать, как люди реально принимают решения.

СТРАНИЦЫ К МОДУЛЯМ

От страниц к модульному опыту

Именно поэтому мы не видим будущее e-commerce обязательно "безстраничным".

Страница всё ещё полезна.

Людям нужны URL. Поисковикам нужны индексируемые документы. Контенту нужен контекст. Пользователи всё ещё навигируют между значимыми пунктами назначения.

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

Страница может быть композицией переиспользуемых бизнес-объектов и модулей интерфейса.

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

Это создаёт более гибкую информационную архитектуру e-commerce.

Это также облегчает эволюцию продукта.

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

Новой кампании может понадобиться другая композиция.

Новый путь клиента может обнажить отсутствующую связь между двумя объектами.

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

В этом практическая ценность модульности.

Дело не в том, чтобы сделать архитектуру модной.

Дело в сохранении возможности передумать.

И это становится всё важнее по мере того, как цифровые продукты становятся умнее.

ИИ И СТРУКТУРА

ИИ нуждается в структурированном продукте, чтобы работать

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

Она начинается со структуры продукта.

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

Но если у продукта есть структурированные отношения между:

товары → коллекции → материалы → истории → эксперты → услуги → намерение клиента

тогда эти отношения становятся пригодными для слоя персонализации.

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

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

Мы не считаем, что каждому e-commerce бизнесу нужна AI-оркестрация сегодня.

Не нужна.

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

Чем более модульна лежащая в основе система, тем больше опций остаётся доступным.

Именно здесь наше мышление связывается с идеями, что мы разбирали в статье Что будет с e-commerce, когда сайт перестанет быть сайтом?, нашем материале про Callimacus и AI-ведомую оркестрацию интерфейса. Идея не в том, что ИИ должен заменить архитектуру продукта. Скорее, ИИ может в итоге работать поверх структурированной системы переиспользуемых объектов и модулей, динамически собирая опыт в зависимости от контекста.

Другими словами:

OOUX определяет объекты. Atomic Design определяет переиспользуемые компоненты интерфейса. ИИ может в итоге решать, как эти компоненты и объекты должны комбинироваться для конкретного контекста.

Это гораздо более интересное будущее, чем просто поставить чат-бота на страницу товара.

ИИ, зеркало людей, что его используют

Есть ещё одно AI-связанное изменение, что мы видим намного раньше в процессе.

Всё чаще клиенты приходят со спецификациями, созданными с ChatGPT, Claude, Perplexity, Copilot или другими AI-инструментами.

Мы сами используем эти инструменты, обширно.

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

Нет ничего изначально неправильного в спецификации, созданной с помощью ИИ.

Во многих случаях это может значительно ускорить процесс.

Важный вопрос, какое мышление стоит за документом.

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

Она в экспертизе, что ведёт работу.

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

Маркетолог понимает привлечение и позиционирование.

Бизнес-аналитик видит процессы, зависимости и требования.

UX-специалист изучает поведение и взаимодействие.

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

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

Ни одна из этих перспектив не полная сама по себе.

ИИ, зеркало человека, что его использует.

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

Цель не избегать ИИ.

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

ТЕХ СЛЕДУЕТ ЗА ПРОДУКТОМ

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

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

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

Команда особенно хорошо знает Laravel, поэтому проект становится Laravel.

Другая команда специализируется на Shopify, поэтому всё становится Shopify.

Кто-то предпочитает React.

Кто-то другой утверждает, что Symfony лучше для крупных команд.

Все это могут быть технически разумные решения.

Они также могут быть совершенно нерелевантными реальной бизнес-проблеме.

Не существует универсально правильной e-commerce платформы или фреймворка.

Для одного бизнеса WordPress может быть более чем достаточен. Другому может быть отлично достаточно Shopify. Другому продукту может реально понадобиться кастомное приложение, headless-архитектура на Laravel, или более изощрённый бэкенд. Ошибиться в этом решении дорого исправлять потом, мы разбираем этот риск напрямую в статье The Hidden Cost of Choosing the Wrong Architecture.

Решение зависит от таких факторов, как:

• сложность товара;

• количество и тип товаров;

• интеграции;

• внутренние процессы;

• ожидаемый рост;

• требования к персонализации;

• контентная архитектура;

• возможности команды;

• требования безопасности и соответствия;

• модель поддержки;

• и ожидаемая жизнь продукта.

Технология, это решение о реализации.

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

Это также меняет, как мы думаем про стоимость.

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

Иногда самое изощрённое решение это ровно то, что нужно проекту.

Иногда это дорогой способ решить проблему, которой у бизнеса на самом деле нет.

РАБОТА ПОСЛЕ ЗАПУСКА

Цифровой продукт должен работать после запуска

Сайт не завершён, когда команда разработки его развёртывает.

Это особенно верно для e-commerce.

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

Аналитика показывает, откуда люди приходят.

Данные поиска показывают, что они ищут.

Поведение пользователей показывает, где они колеблются.

A/B-тестирование может оспорить предположения.

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

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

И внезапно продукт начинает нас чему-то учить.

Именно поэтому мы часто относимся к запуску как к началу итеративного процесса, а не концу разработки.

Первая версия даёт нам доказательства.

Эти доказательства информируют следующую версию.

Следующая версия производит больше доказательств.

Со временем продукт становится всё больше согласован с бизнесом и его клиентами.

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

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

Что делает его MVP, не плохое качество.

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

Это различие может сэкономить бизнесам огромные суммы денег.

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

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

Второй подход не устраняет риск.

Он делает риск видимым раньше, пока менять направление ещё доступно по цене.

ИССЛЕДОВАНИЕ НЕ РАЗОВОЕ

Исследование, не одноразовая фаза

Это ещё одна причина, почему мы не думаем про исследование как про что-то, что происходит только в начале проекта.

Начальное исследование устанавливает гипотезы.

Рынок их тестирует.

Продукт генерирует новую информацию.

Эта информация меняет наше понимание.

Процесс становится итеративным:

Исследование → Гипотеза → Дизайн → Запуск → Измерение → Обучение → Доработка

Иногда результат подтверждает оригинальную архитектуру.

Иногда нет.

Оба исхода полезны.

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

Модульная система может эволюционировать.

Жёсткая обычно накапливает заплатки.

БИЗНЕС ПРЕЖДЕ ИНТЕРФЕЙСА

Бизнес приходит прежде интерфейса

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

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

Мы проектируем цифровые продукты как часть более крупной бизнес-системы.

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

Только тогда UX становится значимым.

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

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

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

Именно поэтому мы не просто исполняем каждое требование ровно так, как оно приходит.

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

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

Это различие не про то, чтобы быть сложным.

Это про понимание, за что мы отвечаем.

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

Это исполнение.

И есть разница.

ОТ ОБЪЕКТОВ К ОПЫТУ

От объектов к опыту

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

Это система объектов, отношений, путей и решений.

Объекты дают бизнесу структуру.

Пути клиентов дают этой структуре контекст.

UX определяет, как люди с ней взаимодействуют.

Atomic Design даёт интерфейсу переиспользуемый визуальный язык.

Технология даёт инфраструктуру, что нужна системе для работы.

Аналитика и тестирование показывают нам, как она ведёт себя в реальности.

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

У каждого слоя своя работа.

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

Начать с технологии может привести к ненужной сложности.

Начать со страниц может создать жёсткую информационную архитектуру.

Начать с UI может произвести красивые интерфейсы, что не решают правильную проблему.

Начать с ИИ может произвести впечатляющие функции без значимой роли в пути клиента.

Начать с бизнеса даёт нам другой путь.

Первый вопрос не "Что нам построить?"

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

Но есть один вопрос, что идёт первым:

Из чего реально состоит этот бизнес, и какой опыт нужен клиенту, чтобы через него пройти?

Как только мы можем на это ответить, остальное становится дизайн-задачей.

Мы можем определить объекты.

Картировать пути.

Изучить рынок.

Определить архитектуру.

Выбрать подходящую технологию.

Построить дизайн-систему.

Запустить первую версию.

Измерить, что происходит.

И продолжать развивать продукт.

Вот почему мы не видим e-commerce UX дизайн просто как проектирование интернет-магазина.

Мы видим это как проектирование цифрового слоя бизнеса.

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

Потому что самые сильные e-commerce продукты, не те, что спроектированы оставаться ровно такими, какие есть.

Это те, что спроектированы эволюционировать.

Дальше по теме

Идеи этой статьи напрямую связаны с несколькими областями нашей работы, включая обдуманную покупку и luxury e-commerce, модульные цифровые опыты, OOUX и Atomic Design, и AI-ведомую оркестрацию интерфейса. Модульный подход, что мы описали здесь, также архитектурный фундамент того, что мы разбирали в статье Что будет с e-commerce, когда сайт перестанет быть сайтом?: AI-система может динамически собирать опыт только тогда, когда лежащий в основе продукт уже структурирован в значимые, переиспользуемые объекты и модули.

Страница не продукт. Интерфейс не бизнес. И технология не стратегия.

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

Автор: Евгений Боровой, основатель Peretz Agency.