Покажите объект.
Управляйте деталями.

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

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

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

В рабочем сценарии последовательно связаны этапы: Объект и этап → Отчёт подрядчика → Проверка замечаний → Приёмка объёма. Каждый переход имеет исполнителя, входные данные и видимый результат. До разработки разбираем нормальный маршрут, возврат на исправление, отмену и повторное действие. Статус в интерфейсе должен отражать подтверждённое состояние, а не просто факт нажатия кнопки.

Проверяем перед запуском: Возврат и повтор не теряют данные и не создают второй результат.

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

Проверяем перед запуском: Изменение справочника не переписывает согласованный документ.

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

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

Статусы помещений могут приходить из CRM, проектные документы — из согласованного хранилища, данные о работах — из внутренней системы. Для бронирования проверяем текущее состояние объекта повторно на сервере. При задержке обмена показываем дату актуальности и не обещаем свободный объект по устаревшей карточке.

Проверяем перед запуском: Недоступность источника не отображается как подтверждённый успех.

Для длинных операций показываем, что запрос принят, и сохраняем идентификатор результата. Повтор после потери связи не создаёт второй объект. Ошибки разделяем на исправимые пользователем и требующие специалиста; введённые данные сохраняются в пределах согласованных правил. Состояния «пусто», «загрузка», «нет доступа» и «сервис недоступен» проектируем до вёрстки, а не после запуска.

Проверяем перед запуском: Повторное событие не меняет уже выполненную операцию.

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

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

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

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