ServiceLead — кабинет партнёра

Работающий продукт, который нужно было переосмыслить

ServiceLead — CPA-сеть в сфере бытовых услуг: партнёр приводит трафик (заявки на услуги), сеть обрабатывает их силами колл-центра и мастеров и платит партнёру за результат. Продукт живой, с базой активных партнёров.

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

Отдельная сложность — не сломать привычки действующих партнёров при переходе на новую версию.

Партнёры с разным опытом

Личный кабинет обслуживает партнёров, которые сильно отличаются по опыту, объёму трафика и способу работы. Один интерфейс должен работать и для новичка, который только настраивает первый оффер, и для опытного партнёра с десятками активных потоков и командой.

Что предстояло сделать

Переработать кабинет целиком — все ключевые разделы: авторизация, главная, потоки, офферы, лиды, статистика, профиль, тикеты, финансы, телефония, домены, новости.

Сердце продукта — поток: связка Проект + Оффер + Инструмент + настройки с уникальным ID. Партнёр создаёт потоки, управляет ими и на них зарабатывает — то есть сценарий создания потока это не «один из экранов», а центральный механизм всего кабинета. И именно он был устроен хуже всего.

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

Где болело сильнее всего

Собрала опросник для действующих партнёров — не «нравится / не нравится», а вопросы про то, где партнёр буксует и что делает в обход интерфейса. Дальше лид и продакт финализировали формулировки, менеджеры принесли обратную связь от партнёров, разработка выгрузила статистику с бэка. Выводы разбирали вместе.

• 01 Создание потока разваливалось под инструмент: число шагов прыгало от инструмента к инструменту, а одни и те же поля назывались по-разному («Номер телефона», «Телефон»). Предсказуемости не было
• 02 Статистика и финансы жили отдельно от повседневных задач — партнёр не видел связку «действие → результат»
• 03 Разные типы партнёров требовали разной плотности данных, но интерфейс подстраивался слабо

Разделы с плотными данными

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

Статистика

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

Финансы

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

Лиды

Поток лидов с фильтрами и статусами обработки — партнёр видит, что происходит с каждой заявкой.

Весь кабинет — 12 разделов

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

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

В команде было семь человек: продакт, дизайн-лид, разработка и я — продуктовый дизайнер. Финальные продуктовые решения принимал лид, я отвечала за дизайн: сценарии, архитектуру, UI, дизайн-систему.

Спроектировала карту продукта, каркас единого флоу и словарь полей. Собрала дизайн-систему на слотах. Гипотезы обсуждали втроём с лидом и продактом, дальше я итерировала макеты. Разработка помогала оценивать выполнимость на ранних этапах — это экономило время на переделках.

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

Что успели за 6 месяцев

• 01 Единый флоу создания потока — 7 фиксированных шагов вместо процесса, который менялся под каждый из ~20 инструментов
• 02 150+ экранов — проработаны все ключевые разделы продукта и их состояния
• 03 Дизайн-система на слотах — единый источник правды для команды, быстрая передача в вёрстку
• 04 Документация продукта — рабочая база знаний по логике и решениям

Довела проект до передачи финальных экранов в вёрстку. На этом этапе работу остановили — команду сократили при реорганизации компании.

Что было сложно

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

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