🔥
Количество платных подписок увеличилось на 8% в течение месяца после релиза.
🔑
Раздел стал ключевым рабочим инструментом для пользователей, работающих с большими массивами данных
💼
Производительность операций кратно выросла за счёт табличной модели и массовых действий.
1. Вступление
Контекст
После пересборки раздела «Прайс-листы» в мобильном приложении система стала архитектурно зрелой и гибкой: были реализованы поддержка множественных прайсов, проектная изоляция данных и интеграция в рабочие процессы
Проблема: отсутствие роста
Продукт находился в стагнации: количество новых платных подписчиков компенсировалось числом отписавшихся.
Product Owner выдвинул гипотезу:
часть потенциальной аудитории не готова работать с большими массивами данных с телефона.
Для руководителей и подрядчиков прайс-листы — это по сути таблицы с десятками и сотнями позиций. Мобильная среда физически ограничивает скорость и точность работы.
Предполагалось, что запуск полноценной десктоп-версии раздела может:
- привлечь новую аудиторию, ориентированную на работу с ПК;
- повысить ценность продукта для текущих пользователей;
- усилить удержание за счёт роста эффективности работы.
Задача:
создать инструмент, который по удобству и скорости работы с данными не уступает привычным табличным решениям и интегрирован в бизнес-процессы продукта.
Речь не о переносе экранов, а о создании профессиональной рабочей среды.
Один и тот же сценарий в разных средах. Разница — в плотности данных и скорости работы.
2. Моя роль в проекте
- Единственный дизайнер направления;
- Отвечал за UX и логику взаимодействия;
- Проектировал десктоп-версию на основе мобильной архитектуры;
- Работал напрямую с Product Owner;
- Синхронизировался с разработчиком ежедневно;
- Проводил ручное тестирование (QA в команде не было).
3. Проблема
Проблема на уровне продукта
Продукт 101 не рос:
- ограничивался мобильной средой
- не воспринимался как полноценный профессиональный инструмент для работы с большими массивами данных
Проблема на уровне бизнеса пользователей
Для клиентов прайс-листы — это операционный инструмент управления.
Им важны скорость обработки данных, прозрачность структуры и простота внедрения в рабочие процессы.
Мобильный формат:
- снижал производительность при работе с большими объёмами информации;
- усложнял масштабирование внутри компании;
- повышал барьер адаптации для сотрудников, привыкших к десктопным системам.
Проблема на уровне UX
Мобильная версия корректно реализовывала бизнес-логику, но сама среда ограничивала эффективность:
- карточный формат не позволял видеть данные целостно и сравнивать строки;
- операции выполнялись последовательно и требовали большего количества действий;
- взаимодействие с иерархией категорий разрывало рабочий контекст.
Система оставалась функциональной, но не производительной.
4. Цели проекта
💡
Создать десктоп-версию раздела «Прайс-листы», которая:
- работает с большими массивами данных эффективнее, чем мобильная версия
- становится ещё одним аргументом в пользу подписки
Ключевые направления
- Эффективное управление данными: табличный режим с высокой плотностью информации и наглядным сравнением строк;
- Быстрые массовые операции: редактирование и перемещение позиций без лишних действий;
- Прозрачная навигация: иерархия категорий доступна сразу, минимизирует потерю контекста;
- Поддержка профессиональных сценариев: горячие клавиши, drag-and-drop, множественное выделение;
- Минимизация кликов и переключений: ускоряет работу и снижает когнитивную нагрузку пользователя.
5. Ограничения
| Ограничение | Что усложняло |
|---|---|
| Архитектура данных уже реализована | Нельзя менять модель прайсов и структуру категорий, нужно работать поверх существующей логики |
| Ресурсы команды | Один дизайнер и один разработчик — каждый шаг требовал высокой концентрации и оптимизации времени |
| Отсутствие QA | Тестирование сценариев ложилось полностью на меня, включая выявление багов и проверку согласованности интерфейса |
| Итеративный запуск | Релиз проходил постепенно (ЗБТ → ОБТ), нельзя было замораживать продукт на долгий цикл полировки |
| Консистентность с мобильной версией | Десктоп не должен был противоречить привычной логике, но при этом нужно было использовать преимущества большого экрана |
| Сжатые сроки | Требовалось быстро показать рабочую версию, чтобы Product Owner мог оценить ценность десктопа для пользователей |
6. Процесс и ключевые решения
6.1 Формирование десктопной модели взаимодействия
Переосмысление среды
Проектирование началось не с визуала, а с анализа среды.
Я опирался на собственный опыт работы с десктопными инструментами и изучил паттерны продуктов, где ключевая ценность — работа с большими массивами данных (CRM-системы, табличные интерфейсы, складской учёт).
Из этого анализа сформировался набор принципиальных отличий десктопной среды от мобильной:
Это стало основой новой модели взаимодействия.
Hi-Fi wireframes и проверка гипотез
Я собрал hi-fi wireframes, используя существующие элементы дизайн-системы и добавив несколько новых компонентов.
Один из ранних hi-fi wireframes. На этом этапе все ключевые паттерны впервые были собраны в едином пространстве.
❓
Будет ли этот набор паттернов работать как единая система, а не как механический перенос отдельных решений?
Чтобы проверить это, я перешёл от статичных макетов к функциональному прототипу.
Функциональный прототип
С помощью Figma Make я за два дня создал интерактивный прототип, воспроизводящий реальные сценарии работы с прайс-листами.
В прототипе реализованы:
- редактирование данных inline с мгновенным пересчётом зависимых показателей;
- поиск по позициям;
- массовое выделение;
- drag-and-drop между категориями;
- массовое изменение значений через контекстное меню.
Фрагмент работы интерактивного прототипа. Демонстрация типовых сценариев: редактирование таблицы, поиск, перемещение, массовое редактирование
Это подтвердило, что модель жизнеспособна не только концептуально, но и в динамике реального сценария.
Синхронизация с командой
Прототип получил положительную оценку от Product Owner.
Благодаря упрощённому визуальному стилю обсуждение было сосредоточено на UX-решениях, а не на графике.
Демонстрация разработчику позволила:
- оценить реализуемость решений;
- выстроить приоритеты от базового функционала к расширенному;
- определить необходимые инструменты и фреймворки.
Это подтвердило жизнеспособность модели и стало переходом к детальной проработке UI и документации.
Дополнительная проверка гипотез
Для валидации модели я провёл точечное тестирование: пять человек, не связанных с продуктом, получили прототип и список задач. Они записывали экран с комментариями во время выполнения сценариев.
Все участники:
- успешно справились с задачами;
- корректно использовали массовые операции и inline-редактирование;
- интуитивно применяли знакомые десктопные паттерны.
Возникали краткие паузы при первом взаимодействии с интерфейсом — ожидаемое поведение для B2B-инструмента с высокой функциональной плотностью.
Критичных проблем не выявлено. Модель взаимодействия читается и масштабируема.
6.2 Архитектура рабочего пространства
После подтверждения модели важно было превратить набор паттернов в устойчивую систему. Для этого я сформулировал принципы организации рабочего пространства.
1. Разделение уровней управления
a. Уровень контекста и режима: управление прайсом: навигация, поиск, создание сущностей
Определяет контекст и режим работы с прайсом
b. Структурный уровень: дерево категорий и действия над иерархией
Работа со структурой, а не с данными
c. Операционный уровень: таблица — основное рабочее пространство: редактирование, сортировка, аналитика
Работа с содержанием
d. Контекстный уровень: действия над объектом или группой через меню
Локальные действия без перегрузки интерфейса
2. Контекстность вместо перегруженности
Действия распределены по уровням контекста и появляются только в момент, когда становятся релевантными.
Интерфейс остаётся визуально чистым в состоянии покоя и раскрывает сложность по мере необходимости. Это позволяет работать с большими массивами данных без ощущения перегруженности.
3. Непрерывный рабочий поток
Во всех сценариях пользователь остаётся внутри одного рабочего пространства — меняется только состояние интерфейса, а не среда работы.
4. Масштабируемость модели
Архитектура интерфейса предусматривает рост функциональности без пересборки взаимодействия.
Система масштабируется за счёт распределения ответственности по уровням, а не за счёт усложнения одного экрана.
- новые локальные действия добавляются в контекстные меню;
- новые режимы — на уровень управления прайсом;
- новые поля — в структуру таблицы без изменения модели работы.
В результате сформирована модель десктопного прайс-листа, ориентированная на производительность, масштабируемость и устойчивость к росту функциональности.
7. Итерационный цикл развития
После запуска модель начала проверяться в реальной эксплуатации и перешла в итерационный формат развития.
Работа велась без выделенного QA, поэтому основное внимание уделялось целостным пользовательским сценариям.
Компактная команда позволяла быстро проходить путь от гипотезы до обновления.
Модель не просто была спроектирована — она постепенно шлифовалась в реальной работе, сохраняя архитектурную целостность.
Оптимизация рабочего потока
После релиза стало заметно, что пользователи часто создают большое количество позиций подряд — например, перепечатывая данные из бумажных прайсов.
В исходной версии для каждой новой позиции требовалось возвращаться к кнопке «+ Позиция» в верхней части экрана, что нарушало рабочий поток.
Что было изменено
- В нижней части таблицы появилась постоянная строка для ввода новой позиции.
- Кнопка «+ Позиция» переводит фокус в это поле и прокручивает экран к нему.
- Навигация по полям осуществляется через Tab и Enter — по аналогии с табличными процессорами.
Таким образом, создание большого количества позиций стало происходить без смены зоны внимания.
Обновление получило положительные отзывы пользователей и активно используется в работе.
8. Результаты и влияние на продукт
Запуск десктопной версии стал не просто расширением платформы, а изменением позиционирования раздела «Прайс-листы» — из вспомогательного инструмента в полноценную рабочую среду.
Количественный результат
В течение первого месяца после релиза число новых платных подписок выросло на 8% по сравнению с предыдущим периодом.
Рост нельзя полностью приписать только десктопной версии, однако запуск нового рабочего инструмента стал значимым фактором повышения ценности продукта.
Качественные изменения
Помимо метрики, были зафиксированы поведенческие изменения:
- пользователи начали переносить основной объём работы в веб-версию;
- сократилось количество запросов на экспорт данных для внешней обработки.
Раздел стал восприниматься как полноценная альтернатива Excel, а не как мобильное дополнение.
Стратегическое влияние
Проект подтвердил гипотезу Product Owner:
часть аудитории действительно не готова работать с большими массивами данных на мобильных устройствах.
Десктопная версия:
- расширила целевую аудиторию;
- усилила удержание текущих пользователей;
- повысила воспринимаемую ценность подписки.
Личный вывод
Этот проект стал для меня важным опытом проектирования сложного десктопного инструмента с высокой функциональной плотностью. Основной задачей было не просто адаптировать мобильную логику под большой экран, а спроектировать гибкую и производительную модель взаимодействия пользователя с данными.
В процессе работы я активно использовал функциональное прототипирование, в том числе с применением AI-инструментов. Это позволило быстрее проверять гипотезы, точнее формулировать требования и оценивать реализуемость решений до начала разработки.
В результате была создана рабочая среда, которая выдержала реальную эксплуатацию, органично развивалась в итерационном цикле и стала частью роста продукта.