Сначала бизнес, потом юзеры: продуктовый подход к внутренним инструментам на примере PWA-конструктора

Привет! Я Софа, ведущий b2e дизайнер в Perfomance Lab, и я считаю, что внутренние продукты недооценены, а процесс их создания в корне отличается от b2c/b2b.

Сегодня речь пойдёт про последнее упомянутое решение — PWA-конструктор, который помогает нашим медиабаерам проверять свои гипотезы быстрее и создавать более 20 приложений каждый день. Я расскажу, зачем мы начали его делать и с какими сложностями столкнулись.

О какие грабли мы споткнулись

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

Сначала мы споткнулись о привычный продуктовый подход. Казалось бы, нужно пойти к пользователям, собрать проблемы, провести глубинные интервью... Но в B2E (Business-to-Employee) сегменте это не всегда работает эффективно. Высок риск пойти на поводу у привычек коллег и создать сервис под копирку из старого набора костылей, повторив все ошибки конкурентов.

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

Какой был процесс: шаг за шагом

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

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

Этап 1: Понимание задачи бизнеса

• Синхронизация со стейкхолдерами. Нам нужно было собрать их видение: на что должен повлиять сервис и какой ожидается результат (спойлер: деньги).

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

• Оценка ресурсов и сроков.

Этап 2: Понимание задачи пользователей

• Сбор User Flow. Сначала нужно было понять, как вообще устроен продукт под капотом и где он ломается на уровне логики.

• Прототипирование. Мы собрали первые экраны и начали их итеративно «причесывать». Приходилось согласовывать то к бэкендерам (сверяться с логикой), то к баерам (за обратной связью).

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

• Тестирование решений. Добавление тех самых минорных мелочей, которые снижают когнитивную нагрузку.

(Далее подробнее о каждом этапе)

Задачи бизнеса: почему стейкхолдеры важнее юзабилити?

Если главная задача бизнеса — заработать, значит ли это, что сервис должен приносить прямую прибыль? Не совсем. Во внутренних продуктах нет прямой монетизации. Эффективность измеряется не в рублях, а в сэкономленном времени и повышенной производительности (в нашем случае — отдела медиабаинга).

Важный урок: влияние стейкхолдеров здесь сильнее юзабилити. И с этим нужно смириться. От многих удобных решений пришлось отказаться. Например, если для быстрого запуска сервиса баеру достаточно заполнить всего два поля, а руководство требует добавить еще пять - добавляем.

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

• Скорости создания одного PWA.

• Количестве новых тест-кейсов.

• Количестве созданных проектов.

Задачи пользователей: уходим в PWA

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

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

Почему решили делать PWA? Модерация нативных приложений в сторах стала жестче, из-за банов бизнес терял деньги на простоях. Наша гипотеза заключалась в переходе на PWA-приложения. Да, мы теряем часть функционала сторов, но обходим долгую модерацию, ускоряя запуск кампаний с недель до часов. Короче говоря — уступаем в качестве, но выигрываем в скорости.

Интерфейс: от БД к людям

Мы начали с ресерча конкурентных PWA-конструкторов: выявили паттерны и нашли сценарии, которые они не учитывали (например, загрузка видео/баннеров в стор, логика интервальных пушей, автоматизация заполнения). Стало ясно, что мы можем дать больше ценности.

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

В итоге баерам больше не нужно было вникать в структуру БД. Они начали работать с привычными сущностями (оффер, гео, пиксель).

Что мы изменили на этапе прототипов и тестов:

С макетами мы постоянно подходили к коллегам и просили «потыкать», чтобы отловить ошибки. Что в итоге внедрили:

• Защита от дурака с пушами. Пользователи часто забывали их настраивать. Внедрили обязательные шаги и визуальные превью пушей — ошибки ушли. Также объединили разовые и интервальные пуши в одну таблицу с фильтрами (раньше они лежали в разных разделах). Добавили возможность грузить бейдж, иконку и баннер.

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

• Быстрый поиск. Внедрили фильтр по статусам приложений.

• Гео-паки (Компании). Раньше добавлять 20 стран приходилось вручную. Мы ввели систему «компаний», к которым привязываются гео. Теперь достаточно выбрать 1 компанию из списка. К каждому гео можно привязать свой оффер, выстраивая воронку.

• Превью в один клик. Раньше ссылка на предпросмотр выдавалась только через 3 этапа сохранения. Сделали 1 кнопку, которая сразу открывает аппку и копирует ссылку в буфер.

• Медиа-контент. Добавили загрузку горизонтальных скриншотов, баннеров и видео для стора.

• Ограничения логики. Раньше можно было накрутить рейтинг «90 из 5» или оставить 40 ответов разработчика на 10 отзывов. Поставили лимиты.

• Домены из базы. Пользователь больше не создает домен с нуля, а подтягивает существующий из БД.

• Экспорт данных. Добавили выгрузку таблиц в HTML и CSV для аналитики (до этого люди просто делали скриншоты экрана!).

Пару примеров

Дизайн-система: За основу взяли Material Design. Отказались от сложной кастомизации ради скорости релиза.

Результат для компании

Запуск внутреннего конструктора PWA устранил главное «узкое горлышко» в виде долгой разработки. Мы перевели процесс из ручной сборки в автоматизированный конвейер. Отдел медиабаинга теперь может самостоятельно тестировать гипотезы без привлечения разработчиков.

К чему это привело:

• Радикально снизилась стоимость проверки гипотез.

• Специалисты могут запускать трафик в день появления идеи (а не через несколько недель).

Выводы для дизайнера

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

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

• Метрики успеха B2E-продукта — это сэкономленное время, а не прямая прибыл. Достаточно тяжело найти эти метрики, чаще всего они субъективны и не имеют прямой корреляции с деньгами. Их нужно уметь выявить

Спасибо за внимание, всех люблю!