Privacy modes

Система защиты контента

+20%

Self-upgrades

-80%

Тикетов в саппорт

>70%

Принятие фичи B2B

Коротко о главном

Спроектировал модульную систему уровней доступа для защиты конфиденциальных документов. Внедрил авторизацию через SSO, доменные ограничения и встроенные сценарии апселлов, снизив нагрузку на саппорт на 80% и остановив отток крупных клиентов.

Обзор проекта

Бэкграунд

У FlippingBook была базовая модель защиты контента, которая позвояла настроить доступ по ссылке с возможностью добавить пароль. Enterprise-клиенты, которые шарили конфиденциальные документы, отчёты и презентации, нуждались в большем. К 2022 году продукт активно рос в крупном B2B сегменте, и текущих настроек стало критически не хватать.

Проблема

Сейлзы еженедельно теряли крупные сделки. Отсутствие настроек доступа входило в топ-3 причин отказа.

Саппорт утопал в тикетах с типовым запросом: «как ограничить доступ к флипбукам?».

Команда

Дизайнер, CEO, PM, Сейлз, Саппорт, Фронтенд, Бэкенд

Моя роль

Sr. Product Designer

UX Owner Researcher Product designer

Таймфрейм

2022–2025

Продуктовый контекст

FlippingBook — платформа для контент-шаринга, которой пользуются 48 000+ команд по всему миру. 3+ млн читателей в месяц. Порядка 200 клиентов из Fortune 500. Продукт соединяет традиционные документы с современной интерактивностью: безопасная, гибкая платформа для создания, кастомизации и дистрибуции интерактивных флипбуков со встроенной аналитикой и трекингом.

Отправная точка

Главная проблема

Клиенты уходят из-за отсутствия гибких настроек приватности

Типичный юзкейс

Финансовый директор готовит квартальный отчёт. Он загружает файл в наш сервис и ставит общий пароль. Ссылку отправляют участникам правления. Через неделю один из сотрудников случайно пересылает эти данные в общий рабочий чат. В итоге секретные цифры видит вся компания, а клиент вынужден искать более безопасное решение у конкурентов.

Способ защиты контента

Только пароль

Потерянные лиды

~6 контрактов вмесяц

Нагрузка на саппорт

50+ тикетов в месяц

Что было на входе

Один режим: Пароль

Цель

С точки зрения дизайна

Построить масштабируемую архитектуру уровней доступа и логику апселлов

С точки зрения бизнеса

Закрепиться в Enterprise-сегменте и закрыть возражения по безопасности.

С точки зрения разработки

Спроектировать единый UI, который можно переиспользовать

Процесс

Я выстроил работу от сбора хаотичных жалоб до системного проектирования новой информационной архитектуры.

Процесс был разбит на две фазы:

  1. Определение болей, проверка гипотез юзабилити тестами и согласование скоупа MVP.

  2. Проработка UX, разработка дизайна, hand-off, контроль технической реализации, пост релизная аналитика и последующие итерации.

1 •

Discovery

Research

Внутренний аудит

Research

Конкурентный бенчмаркинг

VALIDATING

JTBD, гипотезы и user flow

STRATEGY

Компромиссы и техдолг

ALIGNMENT

Договариваюсь со стейкхолдерами

2 •

Delivery

ARCHITECTURE

Архитектура режимов

ARCHITECTURE

Проектирование апселл-путей

Validating

Юзабилити-тестирование

SYNCRONIZATION

Эволюция режимов

TIMELINE

Запуск и влияние

Финальное решение

Сравнение

На примере раздела Customizer

Режимы приватности

Их разностороннее влияние на продукт

Результаты

B2B сделок

$XXXk+

Churn rate

–45%

Support load

–80%

Рефлексия

Что бы я сделал иначе

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

Backlog

- Интеграция с логами безопасности (Audit Logs) для отслеживания утечек ссылок внутри Enterprise-компаний. - Автоматизация удаления устаревших списков доступа по истечении срока действия контракта с клиентом.