Beneflo

Переход на новую логику взаимодействия вывел платформу на новый уровень эффективности.

−30%скорость онбординга

Модульная система и автоматизированные пресеты сократили время онбординга новых корпоративных клиентов на 30%. Это заменило долгую ручную настройку и заметно ускорило выход платформы на новые рынки.

−25%снижение ошибок

Благодаря автоматической валидации и подсказкам при вводе количество ошибок в финансовых данных снизилось на 25%. Это минимизировало риск некорректных начислений и существенно разгрузило поддержку и HR-команды.

−27%стоимость разработки

Системные паттерны и переиспользуемые решения снизили стоимость разработки новых экранов на 27%. Команда собирает новые сценарии из проверенных блоков, а не проектирует их каждый раз заново.

Я подключилась к Beneflo на этапе пилота и развития после запуска: продукт уже работал, но его нужно было готовить к масштабированию на новых корпоративных клиентов. Это B2B2C-платформа на стыке fintech и HRtech — работодатель настраивает и покупает пакеты бенефитов, сотрудник ими пользуется, а за расчётами стоят страховые и финансовые провайдеры.

Как senior-дизайнер я отвечала за admin experience, путь сотрудника и паттерны, на которых платформа могла расти: валидацию, состояния и визуализацию бюджета. Три стороны, регулируемый финансовый домен и много правил — при этом интерфейс должен был оставаться понятным каждому из участников.

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

Ошибки в финансовых данных стоили дорого — неверные начисления, лишняя нагрузка на поддержку и HR, потерянное доверие клиента.

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

Продукт жил на двух сторонах — настройка у администратора и понимание у сотрудника. Каждый путь проектировался так, чтобы снять точки трения до того, как они превратятся в ошибку или вопрос к HR.

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

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

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

Проект требовал плотной работы с аналитиками и финансовыми консультантами, чтобы точно отразить юридические нюансы в дизайне.

Пара мыслей, которые я унесла из проекта и продолжила бы, останься я на нём дольше.

Хотелось глубже видеть, где именно администраторы спотыкаются при настройке — не по ощущениям, а по данным, — чтобы точнее дорабатывать пресеты и подсказки. И объяснять сотруднику доступные бенефиты через его собственный контекст, а не одинаково для всех. Отдельная тема — правила переиспользования компонентов и состояний: чтобы растущая платформа не расползалась на локальные решения, а системность, ради которой всё затевалось, сохранялась.