Самолет.
Регистрационный центр

О чем проект

Самолёт обратился в IdaProject с задачей переделать внутрянку для своего регистрационного центра. В этой системе операторы ведут сделки с недвижимостью: создают карточки физических и юридических лиц, формируют заявки, прикрепляют документы (ДДУ, соглашения об изменении условий ДДУ, протоколы и так далее) и подписывают их электронно — через SignMe, Госключ, токен

До редизайна сотрудники сидели в интерфейсе примерно из 2010 года. Задача — переработать логику отображения данных и привести всё к актуальной дизайн-системе Самолёт 3.0

С чего начинал

В проект я зашёл единственным дизайнером со стороны Иды. Команда заказчика — аналитик, разработчик и ПМ — все со стороны Самолёта

Никакого нормального ТЗ или прототипа в Figma на старте не было. Прислали Excel-файл со схематичными экранами. Когда я его открыл, вопросов стало в разы больше, чем ответов

Что сделал: выгрузил все прототипы из Excel скриншотами в Figma и вместе с дизайн-лидом начал оставлять прямо на этих скринах уточняющие комментарии для заказчика. Получился такой живой документ со множеством вопросов и ответов. Далее уже на основе ответов начал собирать новый интерфейс на готовых компонентах ДС

Для проекта была документация в Jira, но она описывала старую систему. Для новой я по сути был первооткрывателем — функционал часто додумывался на ходу и интерфейс улучшался итеративно

Как был устроен процесс

Каждый день — получасовой синк с аналитиком и разработчиком. На созвонах задавал уточняющие вопросы, просил показать, как тот или иной сценарий работает в текущей системе

Аналитика я особенно мучал по флоу подписания документов — там было сложно с точки зрения логики ролей и типов подписи. Поля расставить — это не проблема, а вот понять, кто, что, когда и каким способом подписывает — это потребовало много итераций

Приёмка макетов шла в два контура: сначала команда Самолёта говорила ок / не ок, потом макеты уходили на кросс-ревью к дизайнерам Иды. С дизайн-лидом отдельно созванивались по конкретным кускам интерфейса — обсуждали, как сделать лучше

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

Ключевые решения:

Карточка физлица и юрлица

Разнёс данные по табам: «Основные данные», «Сертификат», «История изменений»

В «Основных данных» — три смысловых блока: данные физлица (ФИО, СНИЛС, ИНН, пол, дата и место рождения), удостоверение личности (тип документа, серия, номер, кем выдан, адрес) и контакты. Длинная страница с визуальной группировкой вместо вкладок или степпера. Для операторов, которые заполняют такие карточки десятками в день, важнее предсказуемость и скорость, чем компактность

В «Сертификате» — данные о сертификате (контрагент, удостоверяющий центр, файл сертификата, тип выпуска сертификата и адрес для его доставки, если сертификат выпускается с курьером, а не в офисе)

Флоу создания заявки и пакетного подписания

Самая сложная часть проекта. Разбил процесс на четыре шага:

Создание заявки — выбор способа покупки, плательщика, комментарий. Документы и заявления — прикрепляются документы (ДДУ и другие), вводятся реквизиты: номер, серия, дата выдачи. После добавления документ можно подписать со стороны разных участников сделки — отдельно или дальше пакетно. Пакетное подписание — финальный шаг. Здесь по каждому документу для каждого подписанта выбирается тип подписи: SignMe, Госключ, токен. Можно гонять каждый документ отдельно, можно отправить пакетом. История изменений — данные о сделке, информация от Росреестра, юр- и физлицо

Самой интересной частью было выстроить именно второй и третий шаг — логику, кто и чем подписывает, какие типы подписи доступны для физлица, какие для юрлица, и как это всё уживается в одном интерфейсе без визуального шума

Работа со списками

В системе много больших таблиц: физлица, юрлица, комплексы, контрагенты, заявки. Здесь не изобретал велосипед — взял рабочие паттерны и аккуратно их применил:

Поиск над таблицей слева. Фильтры отдельной кнопкой, открываются в дровере справа. Сортировка по нажатию на заголовок колонки. Массовые действия и выгрузка в XLS — под таблицей

Компоненты таблиц под эту специфику докручивали — это пошло обратно в ДС Самолёт 3.0

Адрес объекта

Отдельная история — форма ввода нового адреса объекта недвижимости. Там нужно было дать оператору возможность ввести адрес со всей детализацией по справочникам: ОКАТО, ОКТМО, индекс, регион, район, населённый пункт, улица, дом, корпус, строение, квартира, тип квартиры. Плюс возможность развернуть/свернуть блок, чтобы не пугать длиной формы тех, кому нужно ввести что-то простое

Про дизайн-систему

База — Самолёт 3.0. Использовал её как готовый набор компонентов, но под специфику регцентра пришлось докручивать визуал таблиц. Сама ДС параллельно развивалась усилиями других дизайнеров на других задачах, мои доработки шли в общий пул

Что в итоге

Все макеты ушли в разработку. На момент завершения моей части проект был в реализации

Из обратной связи — комментарий ПМа со стороны Самолёта:

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

Рефлексия

Чем горжусь — за два месяца с нуля влез в незнакомый сложный домен (ЭЦП, кадастр, ДДУ, флоу подписаний) и провёл редизайн всей внутрянки. Постоянный кросс-ревью, постоянные уточнения, защита решений перед бизнесом — всё это было новым опытом, и я с ним справился

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

Что забрал в дальнейшую работу — компонентный подход к проектированию, навык структурировать работу над незнакомым продуктом через ежедневную коммуникацию с командой, и опыт презентаций бизнес-стейкхолдерам