Как мы проектировали UX/UI сервиса управления коммерческой недвижимостью для собственников, арендаторов и УК
Роли, сценарии, статусная логика и снижение когнитивной нагрузки в продукте на 200+ экранов
У клиента было несколько цифровых сервисов, и каждый жил своей жизнью. Пропуска — в одной системе. Документы и бухгалтерия — в другой. Заявки на обслуживание — в третьей. Переговорки бронировались вообще отдельно. Формально процессы были оцифрованы. По факту — один и тот же человек ходил по нескольким интерфейсам, чтобы решить одну бытовую задачу.
У арендатора это выглядело так: оплатить счёт в одном месте, забрать акт в другом, оформить пропуск на въезд в третьем, оставить заявку на ремонт в четвёртом. У собственника проблем было не меньше. Единой точки, где можно быстро понять, что происходит с помещениями, кто платит вовремя, где есть долги и как выглядит доходность по объектам, просто не было.
Клиент строит и развивает индустриальные парки. И не только сдаёт помещения, а управляет всей инфраструктурой вокруг них: эксплуатацией, расчётами, пропускным режимом, коммуникациями, сервисами для резидентов. В какой-то момент стало ясно: набор разрозненных систем не помогает бизнесу расти, а начинает его тормозить.
Готовое решение они уже пробовали. Но оно было заточено скорее под классическую недвижимость, а не под коммерческие объекты с более сложной логикой. Интеграций с внутренней ИТ-средой не хватало, отчёты не отвечали на управленческие вопросы, выгрузки в 1С работали нестабильно. Тогда и появилось решение делать свой сервис.
К нам пришли с понятным, но масштабным запросом: спроектировать с нуля продукт, который объединит в одной экосистеме обслуживание помещений, платежи, документы, пропуска, аренду, продажи, коммуникации и дополнительные сервисы для резидентов. И главное — сделать это так, чтобы пользователю не приходилось каждый раз разбираться в новой логике.
Проектирование UX/UI сервиса управления коммерческой недвижимостью с нуля
В подобных проектах легко ошибиться уже на старте. Кажется, что задача про интерфейсы, значит можно быстро перейти к прототипам. На практике, если не разобраться в процессах, красивый UI просто аккуратно упакует старый беспорядок.
Поэтому мы начали не с макетов, а с погружения.
Провели глубинные интервью, разобрали текущие процессы, посмотрели, где теряются данные, где сотрудники переключаются между системами, где возникают лишние шаги и ручная работа. После этого собрали CJM, user flow, wireframes, провели тестирование, подготовили техническую записку и ТЗ на разработку. Дальше — дизайн-система, UI для web и mobile, передача в разработку, тестирование и доработка.
Первым этапом стал публичный сайт. Это был MVP: главная, услуги, новости, контакты, формы, бронирование переговорок, авторизация. Он давал сервису публичную точку входа. Но основная сложность проекта началась позже — на этапе личных кабинетов.
Со стороны клиента в проекте участвовали маркетинг, ИТ, финансы, эксплуатация и юристы. И почти сразу стало понятно: объединять придётся не просто разделы будущего продукта, а разные внутренние системы, привычки и представления о том, как вообще должен работать сервис.
Какие роли нужно учитывать при проектировании личного кабинета для коммерческой недвижимости
В проекте было три основные роли: собственник, арендатор и администратор управляющей компании. Плюс несколько вспомогательных: брокер, модератор, исполнители.
На словах звучит довольно стандартно. На практике каждая из этих ролей смотрит на одну и ту же реальность под разным углом.
Администратор видит объекты, пользователей, маршруты заявок, задачи, документы, финансы, коммуникации, интеграции и отчёты. Для него система — это панель управления большим количеством процессов сразу.
Собственник смотрит на те же помещения иначе. Ему важно не просто “что это за объект”, а как он работает как актив: кто арендует, какие есть начисления, где просрочки, что подписано, что требует внимания, сколько приносит конкретное помещение или группа помещений.
Арендатору вообще не нужна большая часть этой логики. Для него помещение — это рабочее пространство, вокруг которого есть свои задачи: счета, документы, заявки, пропуска, показания, сервисы, поддержка.
По сути, мы проектировали не один интерфейс, а несколько слоёв доступа к одной системе. И это была одна из ключевых сложностей проекта.
Личный кабинет собственника: как показать помещения, арендаторов, документы и финансы без перегруза
Кажется, что самая сложная роль здесь — администратор. У него больше модулей, больше данных, больше сценариев. Отчасти это так. В его кабинете действительно много контуров: дашборд, пользователи и роли, объекты и парки, помещения, заявки и маршрутизация, задачи, финансы, документы, услуги, пропуска, коммуникации, интеграции, отчёты, профиль.
Но самый тонкий и спорный слой оказался у собственника.
Потому что в реальной модели у одного собственника может быть несколько помещений, иногда в разных парках. У одного помещения может быть несколько собственников. У помещения могут быть арендаторы с разными финансовыми сценариями. И всё это должно собираться в понятную картину: где доход, где задолженность, где документы, где активность по объекту.
Если в таком кабинете ошибиться с логикой, пользователь начинает тонуть в деталях. Формально все данные есть, но реальной ясности нет.
Именно поэтому кабинет собственника мы пересобирали несколько раз. На разных этапах тестирования включались разные команды клиента, и требования не всегда совпадали. Нам приходилось не просто “доделывать экран”, а перепроверять саму модель: вокруг чего вообще строить навигацию и как показать пользователю сложную структуру без перегруза.
Почему в архитектуре сервиса ключевой сущностью стал собственник
Сначала мы шли по более очевидному пути и строили логику вокруг помещения. Это выглядело разумно: помещение — физическая единица, к ней можно привязать документы, счета, заявки, арендаторов.
Но на тестировании быстро выяснилось, что для собственника такая модель неудобна. Если у него несколько помещений, список “по помещениям” не помогает увидеть общую картину. Чтобы понять, что происходит с активами, приходится проваливаться в каждую сущность отдельно и собирать всё в голове.
Мы развернули архитектуру. В центре логики оказался собственник.
Теперь именно он стал входной точкой в сценарий. Пользователь заходит и сразу видит своё: помещения, объекты, сводку по начислениям, задолженностям, документам и активности. А дальше уже проваливается туда, где нужна детализация.
Это решение изменило не только навигацию, но и всю информационную архитектуру. Зато система стала восприниматься естественнее. Особенно для тех, у кого не один объект, а портфель помещений.
Как снизить когнитивную нагрузку в сложном B2B-сервисе для недвижимости
В подобных сервисах проблема не в количестве функций как таковом. Проблема в том, что бизнесу хочется показать всё сразу, а пользователю в каждый конкретный момент нужно понять только одно: что происходит и что делать дальше.
Мы держали проект на трёх принципах.
Первый — не унифицировать роли там, где у них разные задачи.
Соблазн сделать один универсальный кабинет был. Но довольно быстро стало понятно, что это приведёт к перегруженному интерфейсу, где каждому пользователю показывают чужую логику. Мы сознательно развели сценарии по ролям.
Второй — проектировать не разделы меню, а последовательности действий.
Мы смотрели не на абстрактные сущности, а на реальные вопросы пользователя: как оплатить, где взять документ, как подать заявку, как понять статус, как оформить пропуск, где увидеть проблему, требующую внимания.
Третий — не вытаскивать на экран всю внутреннюю механику.
Система может быть сложной внутри, но интерфейс не обязан демонстрировать эту сложность пользователю. Мы оставляли на виду только те состояния, которые помогают принять решение: подписать, оплатить, согласовать, дождаться, проверить. Всё остальное — промежуточные этапы, технические переходы, служебные статусы — уходило во внутреннюю логику и административный слой.
Статусная логика, документы, пропуска и заявки: как не перегрузить интерфейс
Отдельный пласт сложности пришёл из интеграций. Многие сущности в системе не живут автономно: они завязаны на внешние сервисы и получают часть своей логики оттуда.
Документы связаны с 1С. Пропуска — с системой контроля доступа. Заявки на обслуживание уходят в Bitrix24. Переговорки живут через отдельное ПО. Уведомления и коммуникации тоже входят в общую связку.
Из-за этого одна простая с виду операция может запускать целую цепочку переходов.
Например, пользователь создаёт заявку — и она уходит на исполнителя в Bitrix24. Подтверждение услуги создаёт начисление и документ. Одобрение пропуска открывает доступ в пропускной системе. Подписание документа меняет статус и отправляет уведомление. Просрочка оплаты выводит предупреждение в дашборде собственника или арендатора.
Если показывать пользователю весь этот маршрут целиком, интерфейс моментально превращается в схему для внутреннего обучения команды, а не в рабочий инструмент.
Поэтому мы применили прогрессивное раскрытие. Пользователь видит текущий статус и ближайшее действие, а не всю внутреннюю цепочку. Сама система знает больше, но наружу показывает только тот слой, который нужен в конкретной роли и в конкретный момент.
Это решение сильно снижает когнитивную нагрузку. Особенно в продуктах, где один и тот же объект проходит через несколько систем и несколько ответственных.
Что не сработало с первого раза
В проекте было несколько гипотез, которые выглядели логично на старте, но не выдержали столкновения с реальностью.
Первая — сделать один адаптивный веб-интерфейс на все платформы.
Идея казалась красивой: один продукт, одна логика, одна кодовая база. Но по мере проектирования стало ясно, что мобильные сценарии арендатора и десктопные сценарии администратора слишком разные. Быстро проверить статус заявки и оплатить счёт с телефона — не то же самое, что управлять пользователями, отчётами и маршрутами на рабочем месте. В итоге логика ушла в нативные решения для iOS и Android плюс веб.
Вторая — перенести задачи эксплуатации целиком в новый сервис.
С точки зрения “идеальной системы” это выглядело правильно. Но команда клиента уже работала в Bitrix24: процессы там были отстроены, люди обучены, интеграции жили. Полный переезд стал бы дорогим и рискованным проектом внутри проекта. Поэтому мы оставили внутренний контур в Bitrix24, а в новом сервисе собрали внешнюю часть сценария: постановку заявки, коммуникацию и понятный статус для арендаторов и собственников.
Третья — строить всё от помещения.
На бумаге такая модель выглядела логично, но на тестировании проиграла реальному пользовательскому поведению. Собственнику нужен был не список помещений сам по себе, а понятный обзор по своему портфелю. Поэтому архитектуру пришлось разворачивать.
Где особенно хорошо видно эффект — в кабинете арендатора (как собрать оплату, документы, заявки, пропуска в одном интерфейсе)
Если выбирать один сценарий, который лучше всего показывает смысл всей работы, это будет кабинет арендатора.
Раньше, чтобы решить несколько обычных задач, ему приходилось буквально путешествовать по разным системам. Оплата — здесь. Документы — там. Пропуск — ещё в одном сервисе. Заявка на обслуживание — в другом. Переговорки — отдельно.
Мы собрали это в одну точку входа.
Теперь арендатор заходит в кабинет и видит перед собой понятный рабочий контур: счета, документы, показания, заявки, услуги, пропуска, поддержку, бронирование. Не в виде хаотичного набора ссылок, а как единое пространство вокруг его помещения и его повседневных задач.
Снаружи это выглядит просто: всё в одном месте. Но внутри за этим стоит большая архитектурная работа. Мы проектировали не только экраны, но и то, как между собой взаимодействуют 1С, Bitrix24, система пропусков, HR-портал, Telegram-бот, корпоративный сайт и другие части инфраструктуры.
Дашборды для собственника, арендатора и администратора: что показать в первую очередь
Почти в любом сложном продукте дашборд кажется самым понятным модулем: собрать виджеты, расставить приоритеты, показать главное. На деле это один из самых спорных экранов.
У администратора одни сигналы внимания: новые обращения, статус задач, должники, загрузка, контроль процессов. У собственника — другие: доходность, документы, долги, активность по помещениям. У арендатора — третьи: счета, текущие заявки, предупреждения, показания.
Мы несколько раз меняли логику первого экрана. В одних версиях он был слишком тяжёлым: пользователь видел много данных, но не понимал, за что зацепиться. В других — слишком “чистым”, и тогда приходилось делать лишние переходы, чтобы добраться до сути.
В итоге рабочей стала модель, где на первом экране лежит только то, что требует реакции прямо сейчас. Всё аналитическое и детальное — ниже, по провалам из виджетов. Такой подход делает интерфейс спокойнее и помогает быстрее принимать решения.
Что получил бизнес в итоге: единая цифровая инфраструктура для управления коммерческой недвижимостью
В финальном виде продукт включает более 200 экранов, 14 крупных модулей и 9 интеграций с действующей инфраструктурой клиента: корпоративным сайтом, HR-порталом, Telegram-ботом, Bitrix24, внутренней рассылкой, 1С ЖКХ, 1С Предприятие, системой пропусков и ПО для переговорных комнат. Отдельно в развитии предусмотрены электронная подпись, ПЭП через SMS и эквайринг.
Но важнее не сами цифры, а результат.
У клиента появилась не ещё одна цифровая надстройка, а собственная система управления коммерческой недвижимостью, собранная под реальные процессы компании. Для бизнеса это означает меньше операционной разрозненности, выше прозрачность, меньше ручных ошибок, лучше управляемость и более понятный сервис для резидентов.
Если совсем коротко: раньше цифровая среда состояла из кусков. Теперь это единая инфраструктура.
И именно в этом была главная задача проекта. Не нарисовать красивый интерфейс, а собрать систему, в которой сложность остаётся внутри, но перестаёт давить на пользователя.