Привет! Я Софа, ведущий 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-продукта — это сэкономленное время, а не прямая прибыл. Достаточно тяжело найти эти метрики, чаще всего они субъективны и не имеют прямой корреляции с деньгами. Их нужно уметь выявить
Спасибо за внимание, всех люблю!
Автор: sonyapapulova
