GOR – сервис для инвентаризации зелёных насаждений, который должен был заменить тяжёлые GIS-инструменты в типовых рабочих сценариях: сборе данных, проверке объектов, правках и выгрузке отчётов. Задача была сделать понятный веб-интерфейс, в котором с участками, слоями и паспортами объектов смогут работать и профессиональные операторы, и сотрудники заказчика без опыта в геодезии.
Проект собирался как коммерческий MVP. Я вёл UX/UI полностью: отвечал за логику ролей, сценариев, прототипы, интерфейс и подготовку к передаче в разработку.
Вводные собирал через рабочие сессии с PM и геодезистом-экспертом: разбирали типовые сценарии QGIS, требования к данным, роли пользователей, ограничения карты, таблиц, паспортов объектов и выгрузки отчётов.
Задача бизнеса
- Основная альтернатива — QGIS: профессиональный инструмент для геодезистов, но избыточный для типовых сценариев заказчика.
В GOR нужно сохранить ключевую логику программы, но сделать её проще и доступнее - Привести инвентаризацию к единому стандарту полей, статусов и типов объектов, чтобы данные совпадали с регламентами
- Сократить время подготовки результата для заказчика за счёт экспорта и отчётов без ручной сборки
- Сделать продукт доступным для разных ролей и снизить зависимость от узких специалистов и долгого онбординга
Моя задача
- Сделать сложную GIS-логику понятной для сотрудников заказчика без опыта и для профессиональных геодезистов
- Построить интерфейс вокруг логики «Участок – Объект – Выгрузка», чтобы сократить путь от ввода данных до результата
- Собрать сценарии для ролей (клиент/оператор/админ) с понятными правами и зонами ответственности
- Задать единые правила взаимодействия во всём продукте, чтобы режимы, инструменты и состояния читались без отдельного обучения
Системные роли
После разбора рабочих сценариев с PM и геодезистом я разделил пользователей на 4 роли. Так стало понятно, какие действия, права и зоны ответственности нужны в MVP.
| Роль | Задачи | Цели | Ключевое действие |
|---|---|---|---|
| Админ | Управление компаниями/пользователями/подписками, контроль проектов и работ | Запуск и поддержка сервиса, контроль качества данных и процессов | Создать компанию/участок, добавлять пользователей и управлять доступами |
| Клиент | Просмотр и проверка данных, правки объектов, выборки, экспорт | Получить корректные данные и отчёт в нужном формате | Проверить участок, утвердить работы и выгрузить результат |
| Оператор | Сбор и внесение объектов, правки геометрии и паспортов, импорт данных | Быстро заполнить участок и привести к стандарту | Добавить/отредактировать объекты на карте |
| Менеджеры | Координация задач, контроль статусов, коммуникация, подготовка участка к сдаче | Сдать проект без срывов и переделок | Проверить данные и подготовить участок к выгрузке |
Job Stories
Job Stories помогли связать вместе роли, боли и гипотезы решений. Через них я проверял, какие функции действительно нужны в MVP, а какие можно не выносить в первую версию.
| Когда (обстоятельство) | Я хочу (мотивация) | Чтобы (результат) | Боль | Гипотеза решения |
|---|---|---|---|---|
| Нужно создать участок под новый проект | завести участок и структуру слоёв | начать работу без долгой настройки | непонятно, с чего стартовать и что обязательно | пошаговая структура создания + единая логика «участок → объекты → слои» |
| Нужно отредактировать объект | быстро править данные и геометрию | не терять контекст карты и участка | правки “размазаны” по разным экранам, легко ошибиться | карточка/паспорт в шторке + работа поверх интерфейса/карты |
| Нужно проверить данные в таблице | сверить объекты и атрибуты | находить ошибки и править массово | таблицы и карта живут отдельно, тяжело сопоставлять | синхронизировать таблицу с картой и слоями в одном рабочем экране |
| Нужно добавить сотрудника/оператора | выдать доступ и роль | чтобы человек сразу видел нужные разделы | путаница в правах и кто что может менять | роли и доступы через структуру компании/пользователей |
| Нужно собрать выборку слоёв | настроить выбор объектов по правилам | быстро получать нужный “срез” данных | фильтры не повторяются и каждый раз делаются заново | выборки как сохраняемые пресеты + конструктор условий |
| Нужно экспортировать данные | выгрузить участок в нужном виде | получить результат под требования заказчика | непонятно, что попадёт в файл и в каком масштабе | экспорт с настройками и предпросмотром результата до выгрузки |
Прототипы
Проект шёл в три этапа: сначала логика и сценарии, детальная проработка состояний, финальный UI. Прототипы использовались как инструмент согласования логики до визуальной детализации.
- Базовые прототипы – каркас разделов, ролей и ключевых сценариев работы с участками, слоями и объектами
- Детализированные прототипы – состояния, таблицы, формы паспортов, режимы карты, логика правок и ошибок. На этом этапе я довёл UX и сценарии до предфинального состояния
- Финальные макеты – единый визуальный язык, цветовые акценты, компоненты, панели, карта как центральный модуль, подготовка к передаче в разработку
Решения
Функционал сервиса
Как устроен сервис и как он реализует работу с задачами и отображением данных
Общий вид
Я собрал сервис как рабочий кабинет с фиксированной навигацией и реестром участков и объектов. Это сократило время на вход в проект: пользователь быстро находит нужный участок, видит его состояние и переходит к работе без лишних промежуточных экранов
Вспомогательная информация
Вынес просмотр, редактирование и добавление данных в боковые шторки, чтобы пользователь не терял контекст карты и участка во время работы. Это сократило лишние переходы между экранами и сделало правки быстрее
Интерактивная карта
Сделал карту главным рабочим экраном и связал её с таблицей и карточкой объекта в одной логике: Пользователь видит данные сразу в двух представлениях: на карте и в таблице, и может быстро переходить от проверки к правке без разрыва сценария в рамках привычного для визуальных инструментов интерфейса.
Это важно, потому что для инвентаризации нужно одновременно видеть геометрию объектов, их атрибуты и положение на участке.
Сценарий работы
Экраны взаимодействия с сервисом в реальном сценарии работы
1) Создание компании
Сделал создание компании и участков поэтапным, чтобы пользователь видел текущий шаг, не терялся в обязательных полях и мог вернуться к незаполнённым данным позже. Это упростило старт работы с участками и доступами.
2) Работа операторов: создание объектов
Собрал единый сценарий добавления объектов для точки, линии и полигона. Это упростило работу операторов: один сценарий закрывает и ручной ввод, и массовую загрузку из файла, а объект сразу связывается с участком и координатами.
3) Просмотр паспорта объекта
Паспорт объекта открывается поверх рабочей области, поэтому клиент, менеджер и оператор могут проверить параметры и вложения без перехода на отдельные страницы. Это ускорило сверку данных и сохранило контекст работы с картой.
Интерфейс карты
Карта — центр продукта и основной способ работы с участком
Общий вид и функционал
Карта, слои и таблица работают через единый экран. Это позволяет оператору вести правки по объектам, а клиенту — проверять состав и атрибуты без отдельных экранов и ручной сверки.
Режим редактирования
Вынес редактирование объектов в отдельный режим, потому что правки геометрии требуют точности и не должны смешиваться с обычным просмотром. Инструменты разделил по типам объектов: точка, линия, полигон, и сохранение вынес как выход из режима. Это сделало правки предсказуемыми и снизило риск случайных действий.
Выборки
Сделал выборки как сохраняемые пресеты фильтров для контроля, проверки и подготовки отчёта. Конструктор сделан как сборка формулы из команд и значений по выбранным слоям. Это сократило повторяющиеся действия: один раз настроил условия и дальше используешь их как рабочий инструмент.
Экспорт
Сделал экспорт с настройками и предпросмотром результата. Пользователь сразу видит, что попадёт в файл, и может подогнать область, формат и ориентацию под требования отчёта без ручных доработок. В MVP это закрывает «конечную точку» работы: подготовить результат для заказчика прямо в системе и в нужном формате.
Адаптивы под планшет
Я проектировал сервис под десктоп и планшет: для карты, таблиц и точной геометрии был нужен большой экран и крупные интерактивные зоны.
Мобильную версию не выносили в MVP сознательно: для карты, таблиц, слоёв и точной геометрии телефон создавал бы высокий риск ошибок. Вместо этого сфокусировались на десктопе и планшете — устройствах, где оператор может работать с крупными интерактивными зонами и сохранять точность правок.
По итогу получилось 426 макетов под десктоп и планшет.
Мануал
Подготовил 127-страничный мануал по продукту для всех ролей.
Он объясняет логику сервиса, работу с паспортами и таблицами, режимы карты, выборки и экспорт, а также типовые ошибки и как их исправлять
Он помогал быстрее входить в продукт и снижал зависимость от долгого обучения.
Итоги
За 6 месяцев я собрал MVP сервиса для инвентаризации зелёных насаждений вокруг ключевых рабочих сценариев: ввода данных, правок, проверки и выгрузки. Главный фокус: сделать GIS-логику понятной для разных ролей и сократить зависимость от тяжёлых специализированных инструментов.
- Собрал продукт вокруг «участка» как основной единицы работы: единая логика участков, слоёв и объектов упростила работу с данными для 4х ролей: клиента, оператора, администратора и менеджера
- Сделал карту основным рабочим экраном: это сократило разрыв между визуальной проверкой и работой с данными в таблице
- Развёл просмотр и редактирование по режимам: это сделало правки предсказуемыми и снизило риск случайных изменений
- Подготовил материалы для передачи в разработку и внедрение: 200+ прототипов, 426 макетов под десктоп и планшет, UI-Guide с компонентами и 127 страничный мануал помогали команде быстрее запустить MVP и вводить новых пользователей в продукт
Главный вывод: в сложных GIS-сценариях пользователю важнее предсказуемая логика работы, чем полный набор профессиональных инструментов: где участок, где объект, где его параметры, как его изменить и как получить результат. Поэтому MVP был сфокусирован не на копировании QGIS, а на переводе типовых рабочих задач в простой и понятный веб-интерфейс для 4 ролей.