Редизайн раздела «Прайс-листы»

Задача

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

На момент старта проекта от пользователей через техподдержку и Product Owner регулярно поступал схожий фидбек:

• прайс-листы сложно адаптировать под разные проекты;
• при работе с разными объектами приходится дублировать данные или вносить изменения вручную;
• из-за этого возникают ошибки в расчётах и расхождения в данных.

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

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

Что изменилось после редизайна

• прайс стал единым источником данных для проектов, отчётов и смет;
• пользователи получили возможность адаптировать цены и видимость позиций под конкретный проект без создания разрозненных копий;

Вывод

Ценность редизайна была не в обновлении экранов, а в новой модели работы с данными: она уменьшила ручные обходные сценарии и сделала финансовые расчёты более предсказуемыми.

По глубине бизнес-логики и количеству сценариев он сопоставим с отдельным приложением

• команда iOS-разработки

1. Контекст и роль

101 — приложение для управленческого учёта, адаптированное под компании, занимающиеся ремонтом и строительством.

Кто пользователь:

• заказчики (индивидуальные/корпоративные);
• руководители компаний-исполнителей;
• руководители проектов;
• исполнители (бригадиры, рабочие).

Продукт объединяет всех участников процесса и помогает фиксировать выполненные работы, рассчитывать себестоимость и управлять выплатами.

Кто работал над проектом

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

Через неделю Product Owner официально назначил меня дизайнером проекта. В дальнейшем я отвечал за развитие раздела единолично — от пересборки логики до передачи в разработку.

2. Проблема до редизайна

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

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

Такое решение масштабировалось только в условиях одного активного проекта.

3. Цели проекта

Ключевые направления работы:

• Поддержка множественных прайс-листов

Возможность создавать и управлять отдельными прайсами в рамках одной компании.

• Иерархическая структура и управляемость данных

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

• Ролевая модель и изоляция данных

Разграничение прав доступа и видимости информации.

• Интеграция в рабочие процессы

Использование прайсов в проектах, сметах и отчётах без потери актуальности данных.

• Архитектурная гибкость для масштабирования

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

4. Ограничения и сложность

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

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

5. Процесс и ключевые решения

5.1. От одного прайс-листа к масштабируемой системе

Изначально в продукте существовал один прайс-лист на компанию.

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

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

Решение — перейти к поддержке множественных прайс-листов в рамках одной компании:

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

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

Инструменты управления прайс-листами компании

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

5.2. От набора прайсов к управляемой гибкости

Поддержка нескольких прайс-листов решила проблему масштабирования, но в реальном использовании привела к росту дублирования: пользователи создавали отдельные прайсы под каждый сценарий вместо переиспользования данных:

• с замороженными ценами;
• с повышением;
• с сокращённой структурой.

Количество прайсов увеличивалось, а сопровождение усложнялось.

Следующим шагом стала пересборка логики применения.

Решение — перейти к модели базового прайса с гибкостью на уровне проекта:

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

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

В результате удалось:

• сократить дублирование;
• сохранить стандартизированную структуру;
• поддержать разные бизнес-сценарии без усложнения корпоративного справочника.

Руководитель получает инструменты контроля прайса на уровне проекта

5.3. От архитектуры к повседневному использованию

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

Задача: замкнуть систему и встроить обновлённую модель прайсов в реальные рабочие процессы.

Решение — пересобрать сценарии создания отчётов и смет:

• в проектах используется назначенный прайс с учётом его локальных настроек;
• интерфейсы адаптированы под новую структуру данных и мобильные паттерны взаимодействия;
• при выборе позиций пользователь получает достаточный объём информации для принятия решения без перехода в отдельные разделы.

В результате прайс-лист перестал быть самостоятельным инструментом настройки и стал частью ежедневной работы.

Это позволило:

• сделать создание отчётов и смет более предсказуемым;
• сократить количество ошибок и расхождений;
• закрепить прайс как единый источник данных в продукте.

Таким образом, решения из 5.1 и 5.2 замкнули полный цикл:

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

Проверка сценариев на пользователях

После сборки ключевых сценариев я провёл серию юзабилити-тестов на действующих пользователях продукта (руководители проектов и исполнители). Участникам предлагалось выполнить типовые задачи:

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

При этом выявились точки напряжения:

• пользователи не всегда сразу понимали, в какой момент изменения становятся локальными для проекта;
• возникали вопросы к прозрачности состояния “изменённого” прайса относительно базового.

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

6. Итерации и развитие

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

Первая итерация

В релиз вошла базовая инфраструктура:

• обновлённый раздел «Прайс-листы»;
• массовое редактирование;
• назначение прайс-листа проекту;
• обновлённые сценарии выбора позиций в отчётах и сметах.

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

Осознанные ограничения

• В первой версии прайс проекта представлял собой динамическую копию прайса компании;
• Настройка цен и скрытие позиций на уровне проекта были отложены;
• Однако структура данных и интерфейс изначально проектировались с учётом этих сценариев. Это позволило заложить масштабируемость без последующей переработки логики.

Принятие решений

Приоритизация функций проводилась совместно с дизайнерами с использованием ICE и согласовывалась с Product Owner в рамках планирования итераций.

Потенциал развития

В дальнейшем система может выйти за рамки внутреннего инструмента:

• юридически значимое подтверждение прайса со стороны заказчика;
• рекомендации при создании позиций на основе агрегированных данных других компаний, способствующие стандартизации и прозрачности рынка.

7. Результаты и личный вклад

В результате поэтапной переработки прайс-листы перестали быть изолированным справочником и стали системным инструментом, встроенным в ключевые пользовательские сценарии — от настройки и стандартизации до ежедневной работы с отчётами и сметами.

Ключевые результаты:

• прайс-листы стали регулярно использоваться в повседневной работе как исполнителей, так и руководителей, что привело к росту вовлечённости и Retention D30 на 22%;
• снизилось количество ошибок и расхождений в данных за счёт перехода к единому источнику прайса и устранения ручного дублирования;
• повысилась предсказуемость и прозрачность финансовых расчётов, так как пользователи начали работать с согласованной структурой данных вместо разрозненных версий прайсов.

Моя роль и ключевые выводы

В проекте я выступал ведущим дизайнером раздела и отвечал за продуктовую логику, архитектуру данных и пользовательские сценарии: работал с фидбеком пользователей через Product Owner, формулировал гипотезы и проверял их через прототипирование и итерации.

Модель изначально проектировалась мной с учётом масштабирования: это позволило снизить риски будущих доработок и избежать переработки базовой логики.

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

Продуктовый вывод

Кейс подтвердил, что в сложных B2B-сценариях ценность дизайна часто создаётся не за счёт новых экранов, а за счёт правильной модели взаимодействия с данными. В этом проекте редизайн сработал именно потому, что изменил базовую логику раздела: прайс стал устойчивой частью рабочих процессов, а не справочником, который пользователи вынуждены обходить ручными правками.