Docspro

Платформа для автоматизации юридических процессов и подготовки документов. 

Docspro стартовал как внутренний стартап юридической компании: трое технарей три месяца работали без продуктового вектора. Когда я пришел единственным дизайнером, в команде не было ни процесса проверки гипотез, ни понимания, куда двигаться. При этом домен был новым — юриспруденцию пришлось осваивать в темпе реальных задач. Со временем на меня легла полная ответственность за продукт: я прошел путь от «играющего тренера» до PM, вырастив команду до 11 человек.

LegalTech · Startup · B2B SaaS · 2018–2020 · Product Designer/Product Manager

Контекст

Главная боль рынка была очевидна: юристы тратили часы на ручной ввод одних и тех же данных в типовых документах. Любая опечатка или расхождение между договором и приложением могла обернуться серьезными последствиями. В среднем согласование пакета документов занимало 7 дней — документ ходил по кругу, возвращался на правки и снова уходил на проверку.

Вторая проблема — структурная: в одном документе соседствовали сумма сделки, персональные данные и стандартные условия, а разным ролям (от стажера до руководителя) требовался разный уровень доступа к этим данным. Существующие решения (RocketLawyer, HotDocs, WonderLegal) не закрывали эту потребность: либо давали доступ ко всему, либо не позволяли выстроить логику под процессы конкретной компании.

Был и внутренний вызов. Разработчики взяли за основу фронта готовую дизайн-систему Atlassian. Я был против с первого дня: логика Jira и Confluence не совпадает с логикой документного редактора. Веса в команде у меня тогда не хватило, чтобы развернуть решение, впоследствии все переписали с нуля, ровно как я предупреждал.

Процесс

40

интервью

20

юзабилити-тестов

Первым делом мне нужно было разобраться в домене. Я провел серию глубинных интервью с юристами внутри компании-фаундера и с внешними пользователями — в общей сложности 30+ интервью, часть под кураторством Ивана Замесина и 20+ юзабилити-тестов, переводя инсайты в дизайн-решения. Параллельно изучал конкурентов и искал зазор, который рынок оставил открытым.

Двигаться начал итеративно.

Сначала табличный вид — быстро и без лишнего риска, чтобы показать прогресс и снять напряжение вокруг команды, которая три месяца топталась на месте. Затем перешел к редактору и конструктору шаблонов. Каждое решение проходило через юзабилити-тестирование — 20+ тестов на реальных пользователях: юристах, которые каждый день готовят и согласовывают документы.

Пространство документов

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

Единое пространство: папки, теги, статусы и связи между документами. Фильтрация по статусу слева позволяет одним кликом увидеть, например, все документы, застрявшие на согласовании.

Конструктор шаблонов

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

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

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

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

Передача данных между документами

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

В зависимости от выбора значения в одном поле в документах автоматически меняются целые блоки текста: выбрал тип доверителя «Физическое лицо» — и формулировки во всем пакете перестроились под этот вариант.

Настройка автозаполнения: поля группируются в цветные связи внутри сущностей. Значение, введенное в одном документе, автоматически подставляется во все поля своей связи по всему пакету.

Результат для конечного пользователя

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

Опросный лист и готовый документ

Справочники

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

Справочник сотрудников: табличный редактор с настраиваемыми колонками, сортировкой, выравниванием и импортом из CSV. Каждая запись — источник данных для любого шаблона в системе.

Согласование

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

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

История комментариев в документе.

Ролевая модель и админка

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

Это закрыло структурную проблему из начала кейса: руководитель видит сумму сделки и финансовые данные, рядовой сотрудник — только текст документа, без чувствительных полей. Данные защищены от утечки на уровне самой архитектуры доступа.

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

Конструктор ролей в админке.

Результаты

с 7 дней до 1 дня

сократилось среднее время согласования 

до 0%

снизились ошибки в критически важных пунктах договоров

Docspro — проект, где я впервые отвечал за продукт целиком, а не только за макеты. Главный урок — про уверенность: правоты недостаточно, решения нужно продавливать доказательствами. История с дизайн-системой Atlassian научила меня показывать, а не убеждать: аргумент, который можно потрогать, весит больше, чем аргумент, который можно проигнорировать.

И то, чем я горжусь по-настоящему — механика связанных шаблонов. Она родилась не из насмотренности, а из глубокого погружения в чужую боль: когда настолько понимаешь проблему пользователя, что видишь решение, которого еще никто не сделал.