Как организовать сайты трёх приобретённых компаний в один экосистему

Ключевые факты

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

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

Почему это важно

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

Ред. Переформулировка "переездов в товары" на "целей клиента" решает две проблемы: политическую и стратегическую одновременно.

Кому это важно

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

Ред. Затрагивает всех, кроме может быть frontend-разработчиков, которые просто выводят вёрстку (хотя и им полезно понять, почему кнопка вообще там).

Как это применить

Соберите фокус-группу из людей разных компаний. Каждый пишет цели пользователя для чужого продукта, это ломает силос. После этого выпишите все уникальные и пересекающиеся цели. Найдите общие действия: например, "запросить смету" работает для резидентского переезда и для перевозки картин. Затем классифицируйте пользователей по осмысленным категориям: для мувинг-сервиса это может быть географическое место, тип клиента (физ. лицо или юр.), бюджет, срочность. Для ПО это может быть размер команды, опыт в управлении, роль в компании. Создайте макеты одной главной страницы и одной страницы товара, предложив несколько путей к информации. Затем пригласите 5-8 пользователей из каждой группы и спросите: "Как ты бы нашёл информацию о тарифах?" или "Можешь ли ты объяснить, в чём разница между нашими сервисами?" Слушайте, где они спотыкаются. Затем повторите циклы, пока не переберёте основные пути.

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

Можно ли доверять

Автор, контент-дизайнер Лесли Берри, пишет на своём сайте буквально следующее: "Я лично пишу каждый черновик и финальную копию. Весь контент отражает мои собственные идеи, стиль и ремесло. Я не использую ИИ вроде ChatGPT для генерации статей. Изредка я прошу ИИ (вроде Formalizer) обобщить или переформулировать мои собственные идеи и могу переструктурировать секции на основе ответа." То есть рекомендации это отжатые идеи самого автора, без ИИ-ассистентов и без скрытых коммерческих мотивов. Примеры (компания по переездам, компания по обучению медсестёр) реальны и специфичны, а не вымышлены для красоты. Методология опирается на известные работы Донны Спенсер по архитектуре информации, а не на импровизацию.

Ред. Автор честно говорит, что ИИ не писал пост, редко, но честно; это скорее похвально, чем подозрительно.

Риски и подводные камни

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

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