Из Excel-логики в рабочий продукт

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

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

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

В тесной связке с CEO мы формировали первоначальное видение продукта. Я переводил его в первые экраны и визуальный язык, на основе которых складывалась дизайн-система.

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

Например, в задаче с загрузкой файла первая версия слишком выделяла дополнительное действие. Мы перенесли его к действиям таблицы, снизили акцент и собрали решение из компонентов дизайн-системы.

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

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

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

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

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

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

Ещё на этапе MVP правила ценообразования жили в Excel-формулах. Ценовые зоны и сегменты наследовали условия, а итоговая цена складывалась из нескольких уровней логики.

Здесь я переиспользовал подход Figma. Все связанные объекты находятся на одном канвасе, а зум позволяет менять масштаб от общей схемы до конкретного правила.

Подход был понятен CEO. Мы не могли отдельно оценить эффект дерева, но негативной обратной связи на это решение не получали.

Pricing Architecture связала правила с ценовыми зонами, сегментами и группами товаров. Вместе с PDT она показывала, где применяется условие, что от чего наследуется и как формируется итоговая цена.

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