Конструктор документов — часть экосистемы из 14 продуктов, которые автоматизируют закупки, договорную работу и внутренний документооборот. Изначально инструмент делали для внутренних сотрудников (бухгалтеров, категорийных менеджеров, методологов), но после презентации на уровне топ-менеджмента было принято решение развивать его как самостоятельный продукт с потенциалом выхода в B2C.

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

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

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

Структура интерфейса — четыре панели или две?
В начале разработки product owner предложил разбить интерфейс на четыре зоны: левая панель, правая панель, верхняя панель и центральная область с документом. Логика была понятна — много функций, нужно где-то их разместить.

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

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

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

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

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

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

• 1 час → 15 минут на создание документа
• 14 продуктов используют компоненты из этого проекта
• Сотрудники перешли на внутреннюю систему, отказавшись от зарубежного софта
• MVP запущен в рабочую эксплуатацию
• Продукт готовится к развитию как самостоятельное B2C-решение

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