Перевёл разрозненную оплату по каждому объекту (квартира, паркинг, кладовка) в единый цифровой контур: экран-хаб со сводкой по всем объектам, статусами платежей, детализацией начислений и возможностью оплатить всё сразу. Цель — сделать оплату ЖКУ простой, прозрачной и быстрой.

Что изменилось: хаотичные переходы между объектами и непонимание состава суммы → структурированный раздел с общей картиной задолженности, историей и документами «под рукой».

Роль: Senior Product Designer
Платформы: iOS / Android
Команда: PM, аналитик, iOS dev, Android dev, backend dev, QA
Срок: 2,5 месяца
Контекст: B2C / Smart Home / Mobile / MVP

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

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

Что я сделал: провёл исследование текущего поведения и интервью с пользователями, синтезировал боли и сегменты, спроектировал новую структуру раздела «Взаиморасчёты», разработал экран-хаб со статусами и детализацией, добавил графики потребления и фильтры, внёс изменения в дизайн-систему и провёл handoff в разработку.

Ключевое решение: объединить все объекты на одном экране, показать сводку («Переплата», «Ожидает оплаты») и дать возможность оплатить всё сразу, а перед оплатой — показать детальную расшифровку начислений (услуги, тарифы, объём, льготы, пени).

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

Статус: решение передано в разработку и запущено в MVP. Метрики post-launch подтвердили эффективность подхода (подробнее в разделе «Результат»).

Мобильное приложение «умного дома» — это единая точка управления для жителей жилых комплексов: здесь и управление устройствами, и сервисы ЖКХ, и коммуникация с управляющей компанией. Раздел платежей исторически был одним из самых востребованных, но при этом самым проблемным.

Старый раздел «Квитанции» строился вокруг каждого объекта недвижимости отдельно: у пользователя могло быть несколько объектов (квартира, паркинг, кладовка), и для каждого приходилось открывать свой экран, искать актуальную квитанцию, проверять детали и проводить оплату. Никакой сводной информации не было.

Из-за этого:

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

Новый раздел «Взаиморасчёты» должен был стать единым хабом, который объединяет все объекты, показывает статусы по каждому, даёт прозрачную детализацию и быструю оплату — и тем самым закрывает потребности и пользователей, и бизнеса.

До редизайна сценарий оплаты выглядел так:

1. Пользователь заходит в раздел «Квитанции».
2. Видит список своих объектов (например, квартира, паркинг, кладовка).
3. Выбирает объект → открывается экран с историей квитанций.
4. Ищет нужную квитанцию (часто не понимая, какая актуальна).
5. Открывает PDF, пытается разобраться в начислениях (формат неудобен для мобильных).
6. Если решает оплатить, нажимает кнопку оплаты, переходит в платёжный шлюз.
7. Повторяет всё для каждого объекта отдельно.

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

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

Раздел платежей — одно из ключевых touch-точек с продуктом. Если он неудобен, пользователь теряет доверие ко всей экосистеме.

Кроме того:

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

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

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

Моя зона ответственности:

• Планирование и проведение качественных интервью (вместе с исследователем).
• Анализ логов поведения пользователей в старом разделе (совместно с аналитиком).
• Сегментация аудитории и формулировка инсайтов.
• Разработка гипотез и прототипов.
• Сравнение концептов (табличное, по критериям).
• Проектирование UX-сценария и UI.
• Создание интерактивного прототипа для тестирования.
• Внесение изменений по результатам тестов.
• Обновление дизайн-системы (новые компоненты, цветовые токены).
• Подготовка спецификаций и handoff-документации.
• Согласование компромиссов с командой.

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

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

На что я опирался

• Аналитика текущего раздела (воронка оплат, точки выхода).
• Логи обращений в поддержку.
• Глубинные интервью с 12 пользователями (разные сегменты).
• Короткий опрос (100+ респондентов) для количественной оценки болей.
• Бенчмарк платежных разделов в других приложениях (банки, ЖКХ-сервисы).

Сегменты пользователей

• Молодые семьи (25−40 лет) — активно пользуются приложением, хотят скорости и прозрачности, оплачивают с телефона.
• Пенсионеры (60+) — часто оплачивают через терминалы или банки, в приложении путаются, им важна детализация.
• Арендаторы — оплачивают по счетам, но не всегда понимают, какие услуги включены, нуждаются в подтверждении оплаты для арендодателя.
• Собственники с несколькими объектами — самая сложная группа: им нужно видеть общую картину и оплачивать всё сразу.

Ключевые инсайты
1. Главная боль — «прыжки» между объектами
Пользователи с несколькими объектами тратят в 3 раза больше времени на оплату. Они не видят общую сумму и часто пропускают какой-то объект.
2. Непрозрачность состава суммы
В старой версии детализация была только в PDF, который неудобно читать на телефоне. Многие не понимали, за что конкретно платят (особенно пени, корректировки).
3. Статусы «переплата» и «ожидает оплаты» не выделялись
Пользователи могли не заметить, что по одному объекту переплата, а по другому долг. Это приводило к излишним платежам или просрочкам.
4. Потребность в документах «под рукой»
История квитанций и чеков нужна для контроля и возможных споров. Но в старом разделе она была разбросана по объектам.
5. Пользователи хотят оплачивать всё сразу
Если есть несколько объектов с долгами, логично дать кнопку «Оплатить всё» одной суммой.

Как он работает

1. Пользователь заходит в раздел «Взаиморасчёты».
2. Сразу видит сводку по всем объектам:

• Блок «Переплата» (если есть),
• Блок «Ожидает оплаты» (общая сумма долга и пообъектно),
• Блок «История начислений и платежей»,
• Блок «Документы» (квитанции, чеки).

3.Выбирает конкретный объект → открывается детализация:

• список услуг с тарифами, объёмом потребления, корректировками, льготами, пенями;
• график потребления (например, электричество по месяцам);
• быстрые фильтры (текущий месяц, предыдущий, год).

4.Нажимает «Оплатить всё» или выбирает конкретные объекты для оплаты.
5.Проводит оплату внутри приложения (платёжный шлюз), получает чек на e-mail.
6.Статусы обновляются в реальном времени.

Почему сценарий устроен именно так:

• Сводка на первом экране даёт мгновенное понимание финансового состояния.
• Статусы цветом помогают быстро идентифицировать проблемные объекты.
• Детализация заменяет чтение PDF и снимает вопросы.
• График потребления добавляет ценность для аналитики.
• «Оплатить всё» сокращает количество действий до одного.

Что было сделано

• Разработаны финальные макеты и интерактивный прототип.
• Проведены юзабилити-тесты (5 пользователей, все сегменты).
• Подготовлены спецификации для разработки.
• Обновлена дизайн-система: карточки статусов, шильдики, модальные окна, графики, цветовые токены.

Главные компромиссы:
1. Упростили графики потребления
Изначально планировались интерактивные графики с зумами и детализацией по дням. В MVP оставили линейные графики по месяцам — это покрывало основную потребность (видеть динамику) и было дешевле в разработке.
2. Не стали делать частичную оплату внутри одного объекта
Сценарий, когда пользователь хочет оплатить только часть услуг (например, только электричество), оказался сложным для первой итерации. Мы зафиксировали, что оплата идёт полной суммой по объекту, а частичная оплата — в следующую очередь.
3. Отложили автоплатежи и напоминания
Эти функции требуют интеграции с push-уведомлениями и календарём, что выходило за рамки квартала. Они попали в бэклог.
4. Не стали перерабатывать платёжный шлюз
Использовали существующий, но адаптировали UX: добавили предзаполненные данные, индикацию статуса.

MVP был запущен в течение 2,5 месяцев. Пост-релизные метрики за первый месяц подтвердили эффективность решений.

Что реально было достигнуто

• Путь до оплаты сократился на 30% (медианное время от входа в раздел до завершения платежа).
• Доля успешных оплат выросла на 15% (процент пользователей, начавших и завершивших оплату).
• Количество обращений в поддержку по вопросам платежей снизилось на 25% (за счёт прозрачной детализации).
• 50% пользователей с несколькими объектами используют кнопку «Оплатить всё».
• Обновлённая дизайн-система теперь включает компоненты для финансовых разделов, что ускорит разработку следующих фич.

Что изменилось для пользователя

• Больше не нужно «прыгать» между объектами.
• Понятно, сколько и за что платить.
• История и документы всегда под рукой.
• Оплата стала быстрой и предсказуемой.

Что изменилось для бизнеса

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

1. Прозрачность — главный драйвер доверия
Пользователь готов платить, если понимает, за что. Детализация и статусы важнее красивых анимаций.

2. Не пытайтесь объять необъятное в MVP
Чёткое определение скоупа и честные компромиссы позволяют запустить продукт вовремя и с основной ценностью.

3. Дизайн-система должна развиваться
Добавление новых компонентов (статусы, шильдики, графики) окупается в следующих задачах.

4. Исследования экономят ресурсы
Интервью и тесты подтвердили, что «оплатить всё» — это не просто хотелка, а реальная потребность. Мы не тратили время на непроверенные гипотезы.

5. Следующий логичный шаг — автоплатежи и персональные рекомендации
Теперь, когда база готова, можно учить систему предсказывать долги и предлагать удобные способы оплаты.