26
8 мин
У компании было три объекта, и каждый помещался в верхнее меню. Потом появился четвёртый, две очереди строительства и новый город. В меню добавили вложенный список, на главной — ещё один слайдер, а в разделе «Проекты» смешали сданные дома, квартиры в продаже и будущие площадки. Для сотрудника компании названия знакомы. Покупатель видит коллекцию карточек без ответа на простой вопрос: где можно купить квартиру сейчас.
Сначала определяем, что считается объектом
Ошибка начинается в таблице данных. «ЖК Северный», корпус 1 и корпус 2 могут быть тремя строками у маркетолога, одним проектом у бренд-команды и двумя разрешениями у юриста. На сайте нужна понятная иерархия:
- компания или бренд;
- жилой проект;
- очередь или корпус;
- квартира, коммерческое помещение или машино-место.
Карточка каталога обычно представляет жилой проект. Корпуса и очереди раскрываются внутри него, если покупатель воспринимает их как части одного места. Такая модель позволяет сохранить историю проекта и не размножать похожие страницы.
Два входа в портфель для двух разных задач
На корпоративном уровне посетитель может изучать опыт компании: географию, сданные площади, типы проектов. На коммерческом уровне он ищет предложение: город, срок сдачи, комнатность, стоимость. Смешивать эти задачи в одном фильтре неудобно.
| Вопрос посетителя | Что показать | Куда вести |
|---|---|---|
| Что компания уже построила? | Сданные объекты с годом и результатом | В историю проекта |
| Где сейчас продаются квартиры? | Строящиеся ЖК с актуальным статусом | В каталог предложений |
| Есть ли проект в моём городе? | Город и район | На локальную подборку |
| Что появится дальше? | Анонсы без выдуманных сроков | На подписку или контакт |
Проектируя эти маршруты, полезно использовать подход из материала о том, как мы собираем путь посетителя до заявки: начинать не с блоков, а с конкретных вопросов человека.
Фильтры нужны не для демонстрации функционала
Для портфеля из восьми проектов достаточно города, статуса и типа недвижимости. Фильтр по десяткам параметров создаёт пустые результаты и усложняет управление. Подробный выбор площади, этажа и цены относится уже к каталогу квартир конкретного ЖК.
Статусы должны быть взаимоисключающими и понятными: «в продаже», «строится», «сдан», «скоро». Внутренние формулировки вроде «этап реализации 3» лучше оставить в CRM. Если объект сдан, но в нём осталось несколько помещений, карточка может иметь основной статус «сдан» и отдельную отметку о предложениях.
Карточка проекта — это развилка, а не уменьшенная главная
В карточке каталога достаточно названия, города, статуса, срока сдачи, одного сильного изображения и короткого объяснения отличия проекта. После перехода страница ЖК уже раскрывает расположение, генплан, квартиры, инфраструктуру и способы покупки. В кейсе быстрого запуска сайта застройщика два предложения — кирпичный дом и военная ипотека — стали основой страницы. Это полезнее длинного универсального описания.
Кто будет поддерживать порядок через год
Для каждого проекта задают обязательные поля и ответственного за их актуальность. Редактор не должен вручную менять одну и ту же дату на главной, в каталоге и на странице корпуса. Значение хранится один раз и используется во всех нужных представлениях. Здесь помогает единая система компонентов, о которой подробнее рассказано в статье про правила дизайна для растущего сайта.
Перед разработкой соберите инвентарную таблицу: проекты, города, статусы, корпуса, доступные типы помещений, ответственные сотрудники и источники данных. Затем проверьте будущую структуру на пяти реальных запросах покупателей. Если каждое добавление ЖК требует нового меню и ручного копирования страниц, нужен сайт застройщика с управляемым каталогом проектов. Такой сайт растёт вместе с портфелем, а не запутывает его сильнее.
