Skiply

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

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

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

Старый продукт во многом повторял технические ограничения и унаследованные банковские процессы. Если из-за них сценарий становился сложнее, я вместе с командой искал возможность изменить само ограничение, а не интерфейс вокруг него. Так один из сценариев регистрации сократился с 32 экранов до 12.

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

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

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

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

С осени 2025 года по лето 2026-го наша программа ИТ-трансформации получила более 25 отраслевых наград.

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