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