Компания использовала дорогостоящее вендорское решение, которое работало на «костылях». Работая в сервисе, сотрудники страдали из-за долгого и запутанного CJ

Спроектировал интерфейс для сотрудников
и операторов, которые следят за процессом выпуска подписи. Новый сервис позволил ускорить процесс выпуска подписи примерно
на 80% и отказаться от вендорского решения

Проблематика

Результат

Сервис выпуска электронных подписей

Контекст

В Билайне, как и во многих других компаниях, документооборот существует в цифровом формате. Чтобы подписать цифровой документ человек должен использовать электронную подпись – специальный код/файл, который доказывает, что документ подписал конкретный человек.

Помимо меня над проектом работали PO, архитектор, системный аналитик, 3 фронтенд- и 3 бэкенд- разработчика, QA-инженер

Как продуктовый дизайнер, я должен был спроектировать сервис с нуля, причём это касалось интерфейса для двух ролей – сотрудника и оператора, который занимается модерацией выпуска электронных подпсией.

Электронные подписи могут быть двух видов – неквалифицированные (НЭП) и квалифицированные (КЭП). Первые используются во внутреннем документообороте, вторые – во время работы с внешними агентами от лица компании. У аккредитованных IT-компаний есть специальный отдел – Удостоверяющий Центр (УЦ), который занимается выпуском электронных подписей. По запросу УЦ моя команда взялась за разработку сервиса для выпуска КЭП.

Как я приступил к задаче

Провёл серию брифов с заказчиком. Выявил следующие проблемы:

Больше всего бизнес страдал из-за того, что текущий сервис вендорский. Уходило много ресурсов
на внесение изменений. Свой сервис позволил бы в перспективе значительно сэкономить.

При этом пользователь текущего сервиса также сильно страдал. Во-первых, в последних версиях интерфейса наблюдается множество «костылей», которые усложняют CJ. Во-вторых, сервис поддерживал КЭП только на физическом носителе (называется ЛКЭП от слова «локальный»),
а это сопровождалось их постоянными потерями и перевыпусками. Для УЦ и их пользователей было стратегически важно перейти на облачные подписи (ОКЭП), для которых не нужен физический носитель. Однако в сервисе вендора это было бы сделать значительно дороже, чем в своём

Пользователи сервиса

Получил информацию по пользователям сервиса, которые выпускают КЭП. Это менеджеры
и руководители среднего и высшего звена, которые подписывают документы от лица компании почти каждый день.

Я провёл серию глубинных интервью и выявил следующие барьеры пользователей:

Главный вывод – для пользователей сервис очень сложный. Поскольку это руководители, то они нередко просят подчинённых выпустить подпись из их ЛК. Соответственно – надо было максимально упростить сервис.

Также я зафиксировал основные потребности пользователей и выделил эпик сторю:

Как я решал проблемы пользователей

Сначала описал схему процесса выпуска КЭП:

Сделал 1 страницу в сервисе. Когда у пользователя есть заявка, то у него отображается карточка
со статусом в верхнем блоке. Из неё он может перейти в модалку с информацией по заявке

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

Предложил концепцию из 2 экранов, который разделён на табы. В первом табе отображаются подписи, во втором – информация по этапу заявки

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

Процесс был объёмным, но обязательным, поскольку основывался на требованиях МинЦифры. Например, сотрудник не мог подписать сразу оба документа. По закону оператор должен сначала проверить заявление, а только потом пользователь может подписать бланк

Показать блоками страницу сервиса и внутри модалки

Блок с заявкой отображет её текущий статус. Когда статус сменяется, то сотрудник получает уведомление

Справа от таймлайна находится развёрнутая информация
по заявкке. Например, сейчас пользователь должен подписать заявление

В раскрытой заявке слева отображается таймлайн всего процесса, чтобы пользователь чётко понимал текущий этап

После того, как пользователь прошёл процесс, заявка исчезает
и появляется карточка выпущенной
электронной подписи

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

Помимо этого на карточке отображается статус подписи. Документы, которые подписывал сотрудник, находятся в контекстном меню

Как показало исследование, для пользователя очень важно иметь инструкцию под рукой, поэтому раздел «вопросы-ответы» перенесли в сам сервис

А что до проблем операторов?

Чтобы запустить сервис необходимо было также разработать интерфейс для оператора УЦ:

Эту часть задачи я также начал с исследования пользователей. Кто такие операторы? Как они работают? Какие проблемы испытывают?

Провёл серию экспертных интервью, по итогам которых сформировал корневую US и выделил потребности операторов:

Я выделил 3 основные проблемы операторов:
1) Им приходится проверять личные данные, которые пользователи заполняли вручную. В такой ситуации пользователи, конечно же, допускали массу ошибок
2) Заявки никак не сортируются. Вдобавок поиск на портале формально есть, но он не работает
3) Информация по заявке в текущем интерфейсе разрознена. Операторам приходится тратить много времени на проверку данных заявки, прежде чем они примут решение

Предложил следующие «обезболы»:

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

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

После того, как сотрудник убедился, что данные сопадают, то он инициирует заявку
на выпуск ОКЭП. Оператору в этом случае ничего вручную проверять не нужно

Заявки отсортированы по этапам процесса. Наверху представлены более ранние заявки –
их УЦ должен проверить в первую очередь

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

Добавил возможность не только принять/отклонить заявку, но и отправить
на доработку с комментарием

Добавили поиск, который на этапе MVP позволяет искать заявки сотрудников по их почте и табельному номеру

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

Проверка решений

Протестировал интерфейс на всех представителях ЦА.
Для сотрудников, которые выпускают подпись, показатель SEQ составил: 6,6 / 6,6 / 6,3.
Для операторов, которые модерируют процесс, SEQ был равен: 6,3 / 6,6 / 7

После внесения минорных правок, я написал спецификацию к макетам и передал их в разработку

Чего добились после запуска сервиса