Документы — как встроить правила учёта в сценарий
Документооборот, который повторяет реальные операции селлеров и не даёт совершить ошибку
Команда
Product Designer (я), Product Manager, Front‑End, Back‑End, QA
Результат
−70% обращений в поддержку по цифрам в отчётах, связанным с документами
Контекст
Когда я пришёл в компанию, Hub только начинали делать — собственную ERP для селлеров маркетплейсов, способную заменить МойСклад в связке с первым продуктом компании Connect
Hub
EPR‑система заточенная под нужды селлеров на маркетплейсах
Connect
Сервис, позволяющий сихнронизировать данные между ERP и маркетплейсом
МойСклад
ERP‑система, с которой изначально работал сервис Connect как доп. модуль
До этого Connect работал с МойСклад как дополнительный модуль. Hub становился самостоятельной ERP и частью экосистемы продуктов компании. Это давало возможность заложить в систему правила и сценарии, характерные именно для селлеров маркетплейсов, а не переносить чужие. В документах это было особенно важно
Проблема
01
В поддержку обращались по поводу некорректных цифр в отчётах
02
При расследовании причина обычно находилась в документах. Например, пользователь мог создать приёмку без заказа поставщику: цепочка документов не отражала фактическую операцию, и данные в отчётах становились некорректными
Основная задача
Задача была шире, чем сделать документы понятнее. Нужна была модель, в которой часть ошибочных действий вообще нельзя совершить
Исследование
Сначала я проверил, где возникает проблема
Методы:
- Анализ конкурента — как связанные документы устроены в МойСклад
- Анализ поддержки — обращения, где документы приводили к неверным цифрам
- Наблюдение — задания на создание цепочек документов, реальные сценарии
Находка
Большинство пользователей справлялось с заданиями. У начинающих селлеров иногда проявлялся другой сценарий: они не создавали нужный документ, потому что не понимали, что он нужен
Вывод
Проблема была не в невозможности выполнить действие, а в отсутствии контекста — что уже создано и чего ещё не хватает
Как менялись гипотезы
Было
Сделать цепочку документов строгой: заказ → оплата → отгрузка → возврат платежа → приёмка
Логика: если нельзя пропустить документ, нельзя собрать неверную цепочку
Стало
Отгрузка бывает раньше оплаты
Один заказ дробится на несколько отгрузок
Возврат платежа и приёмка товара не обязаны совпадать по времени
Вывод
Разделить обязательные зависимости и реальный порядок работы, вместо того чтобы вести пользователя по одной цепочке
Решение #1
Связанные документы вместо линейной последовательности
Заказ → Отгрузка 1 + Отгрузка 2 — параллельно, без единой цепочки. Оплата может появиться независимо от отгрузки
Связи определяют, что можно сделать, но не заставляют проходить документы в одной последовательности
Решение #2
Блок связанных документов
В каждом документе появился единый блок: что уже есть, чего не хватает, статус, номер, дата, сумма, переход
Решение #3
Унифицированная структура документа
Шапка → связанные документы → основные поля → дополнительные поля → таблица → файлы и комментарии
Данные, которые раньше находились в дополнительных полях, вынесены на первый план
Ограничения
Бизнес-правила
Запрещено: создать приёмку без заказа поставщику. Разрешено: несколько отгрузок на один заказ, оплата независимо от отгрузки. Система защищает учёт от некорректных действий и сохраняет реальные сценарии работы селлера
Проверка и итерация
Проверили
Работу с большими документами — не на макете, а в разработке
Нашли
Фиксированная высота таблицы неудобна при большом числе позиций
Изменили
При прокрутке таблица раскрывается на весь экран (заполняет свободный контейнер)
Результат
−70% обращений в поддержку
Обращения: по цифрам в отчётах, связанным с документами Сравнение: Hub + Connect и МойСклад + Connect, сопоставимый период, данные поддержк
Ограничение интерпретации
Это не контролируемый эксперимент, показатель не доказывает причинный эффект дизайна
Моя роль
Сделано мной
Исследование, формирование модели связанных документов, допустимые сценарии, проектирование интерфейса, сопровождение рзаработки
Совместно с PM и разработкой
Бизнес-правила, модель данных и API
+7(927)623-11-14
t.me/balladdesign
balladdesign@gmail.com
