ТЕЛЕГРАМ
Внутренняя система управления коммерческой недвижимостью
Спроектировал веб-систему для отдела, который управляет коммерческими объектами, арендаторами и размещением организаций. Продукт объединил рабочие данные в одном месте, заменил подготовку вариантов на бумажных планах интерактивным сценарием и автоматизировал формирование отчётов.
Проект в нескольких фактах
Роль и моя зона ответственности: Продуктовый дизайнер. Исследование процессов, архитектура, UX/UI, прототипирование, проверка решений, подготовка к разработке и дизайн-ревью
Команда: Проектный менеджер, команда разработки, продуктовый дизайнер. На финальном этапе — младший дизайнер для подготовки карт.
Контекст и исходная ситуация
Отдел управлял более чем 30 коммерческими объектами. Сотрудники отслеживали занятость помещений, готовили варианты размещения для новых организаций и формировали периодическую отчётность для руководства.

Единой системы не было. Информация хранилась в Excel, PDF-планах, договорах и бумажных документах. Часть планов приходилось восстанавливать из договоров, а актуальность данных зависела от того, кто и когда обновлял конкретный файл.
Бизнес-проблемы
1. Высокая операционная нагрузка. Сотрудники тратили часы и дни на поиск, сверку, подготовку отчётов и презентаций вместо работы с решениями.
2. Низкая прозрачность управления объектами. Не было единого места, где можно быстро увидеть состояние объектов, арендаторов, занятости помещений и связанных данных.
3. Неэффективное использование площадей. Из-за сложности с оценкой занятости и свободных помещений было трудно быстро понять, какие площади простаивают, где есть потенциал для размещения и как оптимизировать использование объектов.
Цель, критерии успеха и ограничения
Цель проекта: Оцифровать основные рабочие процессы отдела и создать внутреннюю систему, которая сделает работу с объектами более прозрачной и менее зависимой от разрозненных файлов и бумажных документов, а также позволит более эффективно использовать коммерческие площади
Как поймём, что решение работает
Основная работа переносится в цифровой продукт
Сотрудникам не нужно использовать бумажные материалы и разрозненные файлы как основной рабочий инструмент.
Информацию становится проще получать и актуализировать
Рабочие данные собраны в более целостной системе и доступны сотрудникам без длительного поиска по разным источникам.
Сокращается количество ручной работы
Повторяющиеся операции, которые можно выполнить средствами системы, не требуют постоянного ручного переноса и подготовки данных.
Взаимодействие с недвижимость становится более прозрачным и эффективным
Состояние объектов можно посмотреть в цифровом виде без отдельной подготовки и запроса информации
Ограничения
Сроки: Проектирование и разработка были ограничены годовым сроком проекта
Разработка: Команда была небольшой и ограничена в опыте реализации сложных интерфейсов
Доступ к пользователям: Сотрудников было сложно регулярно отвлекать от работы для длительных исследований и тестов
Дискавери. Погрузился в процесс работы в отедел работу
Вместе с командой провёл офлайн-встречи с 6 сотрудниками отдела. Я подготовил вопросы по рабочим сценариям, участвовал в обсуждениях и отдельно разбирал процесс непосредственно с будущими пользователями.
Что разбирал?
Как сейчас ведут базу объектов, арендаторов, площади и договоры. Где хранится информация. Как ищут актуальные данные. Как готовят варианты размещения. Как формируют отчёты и презентации. Где возникают ошибки, задержки и ручная работа и тд
Что получил на выходе?
Информация о ключевых процессах, основные пользовательские боли, ожидания сотрудников от портала, список сценариев, которые система должна закрыть
Что стало понятно после Discovery
Пользовательские боли
1. Много времени на отчеты. В отчётный период нужно было собрать данные из разных источников, сверить их, подготовить документы и презентации.
2. Сложная актуализация. Сотрудники не всегда понимали, какие данные свежие, что уже изменилось, а что нужно перепроверить
3. Долга ручная подготовка размещений. Для будущего арендатора нужно было вручную собирать варианты размещения. Сотрудники распечатывали план помещения и вручную зарисовывали возможные варианты размещения в здании. Таких вариантов подготавливалось от 2 до 5-6 на одного арендатора
4. Разрозненность данных. Файлы, бумаги, таблицы, планы помещений находились в разных источниках, а иногда и вообще в знаниях отдельных сотрудников
Инсайты по рабочему процессу
Также отдельно хочется выделить конкретные вещи, связанные с существующим процессом, которые повлияют в дальнейшем на дизайн-решения
Процесс размещения состоит из двух разных состояний
До согласования сотрудник работает с несколькими потенциальными вариантами, и только один из них позже становится фактическим.
Основной рабочий контекст — объект
Большая часть информации связана между собой через конкретный объект: помещения, арендаторы, занятость и площади.
Значительная часть отчётности — повторная сборка уже существующих данных
Сотрудники не создают новую информацию, а повторно сводят и визуализируют то, что уже есть в других источниках.
Правила не всегда работают как жёсткие ограничения
Например, норматив площади важен для контроля, но в отдельных ситуациях сотрудник может сознательно допустить отклонение.
Что система должна была учитывать
  1. Поддерживать несколько предварительных вариантов размещения будущих арендаторов;
2. Отделять подготовку варианта от изменения фактических данных в системе и базе данных;
3. Связывать информацию вокруг объекта: арендаторы, помещения, нормативы и тд;
4. Использовать существующие данные из базы при подготовке отчётности;
5. Предупреждать об отклонениях, не блокируя допустимые исключения.
Первая итерация дизайна. В первой версии я слишком буквально перенёс существующий процесс в интерфейс
На старте я разделил работу с размещением на несколько сущностей: планирование, черновики, бронирование и заявки. Такое разделение повторяло терминологию заказчика и помогало технически развести разные состояния интерактивной карты.

Решение покрывало требования, но пользовательский путь получился длинным. Чтобы утвердить один вариант, сотруднику приходилось последовательно переходить между несколькими разделами и частично повторять уже введённые данные.
Схема первой версии
Формально этапы отличались, но для пользователя являлись одной задачей — подготовить вариант размещения и зафиксировать его после согласования.
Тестирование первой версии. Сотрудники отдела путались между разделами
Я собрал интерактивный прототип и передал его сотрудникам отдела для самостоятельного прохождения основных сценариев. После этого мы провели встречу, разобрали возникшие вопросы и понаблюдали, как заместитель руководителя выполняет задачи в прототипе. Дополнительно я проверил структуру на коллегах внутри команды.

Всего решение прошло два раунда проверки: первоначальной и переработанной версии.
Что обнаружил
Пользователи путали разделы
Не понимали, где заканчивается планирование и начинается бронирование.
Путь требовал лишних переходов
Для одной задачи нужно было проходить через черновики, бронирование и заявки.
Действия были разбросаны
Отчёты, выгрузки и действия с объектами находились в разных частях системы.
Структуру приходилось объяснять
Даже после погружения пользователи сомневались, в каком разделе нужно продолжить сценарий.
Главный вывод
Проблему нельзя было решить подписями и дополнительными инструкциями. Нужно было убрать само разделение, которое заставляло пользователей задумываться о внутренней структуре системы.
Внесение изменений и тестирование второй версии
После первого этапа UX тестов была переработана структура разделов, упростил некоторые сценарии и уменьшил количество действий в рамках одного экрана. Пользователь больше не переносит данные из черновика в бронирование и заявку. Он готовит варианты, согласовывает один из них и утверждает уже заполненный черновик.
Результат второго раунда
На повторной проверке сотрудники перестали путать разделы и сразу понимали, как подготовить и утвердить вариант. После обсуждения переработанная структура была согласована для разработки.
Финальная версия — три ключевых решения
Решение 1. Объект как единый рабочий контекст
В карточке объекта собрал общую информацию, показатели площадей, арендаторов, свободные помещения и интерактивный поэтажный план.
Решение 2. Подготовка нескольких вариантов размещения
Сотрудник выбирает объект, организацию и помещения непосредственно на интерактивном плане. Система рассчитывает площадь на одного сотрудника и предупреждает об отклонении от норматива.

Один запрос может содержать несколько вариантов. Каждый сохраняется отдельным черновиком с комментарием, после чего его можно распечатать и передать на согласование.
Решение 3. Автоматизированная отчётность
В системе можно сформировать Excel-отчёт по объекту, арендатору или периоду, а также подготовить PowerPoint-презентацию с планом конкретного объекта и легендой размещённых организаций.

Шаблоны соответствуют существующей форме отчётности, поэтому сотрудникам не нужно заново переносить планы и раскрашивать помещения вручную.
Все стадии оформления заявки
Сценарий одобрения распланированных помещений
Страница с общим списком заявок, которые были заполнены. Черновик можно одобрить (что внесет изменения в БД), либо удалить. Также из модального окна с подробной информацией о Черновике можно распечатать карту и подробную информацию с размещением организации для предоставления этой информации заказчику (арендатору)
Сценарий выгрузки таблиц и презентаций
Модальное окно с донастройкой таблицы для выгрузки. Таблицы формируются по четкому ранее согласованному шаблону, а дополнительные поля позволяют донастроить таблицу и презентацию под необходимый формат и период
Компромиссы. Система учитывает, что реальный процесс не всегда укладывается в жёсткие правила
Норматив предупреждает, но не блокирует
Сотрудник видит отклонение площади на человека, но может продолжить размещение.
Занятое помещение может участвовать в будущем варианте размещения
Организация иногда готовит размещение заранее, зная, что текущий арендатор скоро освободит помещение.
Историю изменений не включили в MVP версию проекта
История действий могла быть полезна, но сценарий признали редким для небольшой команды пользователей. В рамках доступных сроков приоритет получили ежедневные операции с объектами, размещением и отчётами.
Подготовка к разработке. Согласовывал сложную логику до разработки и сопровождал продукт до рабочей реализации
Разработчики участвовали в проекте с ранних этапов. Я регулярно обсуждал с ними реализуемость сценариев, особенно работу интерактивных карт и синхронизацию выбранных помещений с данными системы.

Для передачи подготовил компонентную базу, состояния интерфейса, интерактивный прототип, комментарии к переходам и видеоразбор всего продукта. Во время реализации проводил встречи по логике сценариев и отвечал на вопросы команды.
Смена команды
После смены PM и части разработчиков я погружал новых участников в предметную область, объяснял связи между объектами, арендаторами, черновиками и заявками, а также презентовал решения заказчику. Часть координационных задач временно перешла ко мне и исполнительному директору.
После сборки я провел дизайн-ревью и зафиксировал расхождения в общей таблице. Замечания разделил на критические, средние и косметические, чтобы команда сначала исправила ошибки, влияющие на сценарии и данные.
В самом конце в команде с младшим дизайнером отрисовали более 60 000 кв.м поэтажных планов объектов в векторе для интерактивных карт, которые тоже, в свою очередь, были подготовлены к разработке
Фактический результат
Продукт полностью разработан и передан заказчику. Сейчас сотрудники наполняют систему реальными объектами, арендаторами и планами через рабочий интерфейс.

Я проверил работающую реализацию: данные создаются и редактируются, интерактивные карты работают, а основные сценарии соответствуют согласованным макетам.
Ожидаемый эффект
После полноценного наполнения система должна сократить объём ручной сверки данных, упростить подготовку вариантов размещения и исключить ручное раскрашивание планов при формировании отчётности.
Почему нет метрик?
Проект выполнялся как заказная разработка и после передачи не сопровождался нашей командой. На момент завершения кейса продукт ещё наполнялся данными, поэтому фактические показатели после запуска пока недоступны.
На что бы смотрел, если бы продолжал работу над проектом?
1. Реальная экономия времени и ручной работы. Сколько времени теперь занимают регулярные задачи и насколько сократилось количество ручных операций, сверок и работы во внешних файлах.
2. Удовлетворённость пользователей. Насколько сотрудникам стало удобнее работать после перехода на систему: что действительно упростилось, что продолжает мешать и хотели бы они что-то изменить после регулярного использования.
3. Качество и актуальность данных. Стало ли меньше расхождений и ошибок в информации, насколько проще поддерживать данные актуальными и приходится ли сотрудникам по-прежнему перепроверять их в других источниках.
Made on
Tilda