Privacy modes
Система защиты контента
+20%
Апгрейдов
-60%
Обращений в саппорт
>70%
Enterprise adoption
Что было на входе
Процесс
Я выстроил работу от сбора хаотичных жалоб до системного проектирования информационной архитектуры. Процесс был разбит на две фазы: глубокое исследование с определением MVP и юзабилити-тестами, а также детальная проработка дизайна с финальной технической синхронизацией.
1 •
Дискавери
Research
Конкурентный бенчмаркинг
Анализ рынка
Завёл триал-аккаунты в DocSend, Pitch, Notion и Flipsnack. Для последних двух сервисов пришлось доставать платные корпоративные профили, потому что на триале Enterprise-настройки закрыты. В каждом сервисе создавал тестовые документы, настраивал доступ, отправлял ссылку себе, пробовал переслать её постороннему (инкогнито) и смотрел что происходит при попытке обойти защиту. Каждый экран настроек сохранял в Figma. После собрал сравнительную таблицу в Notion по четырём направлениям: ролевая модель, способ верификации читателя, гибкость шеринга ссылок, ограничения по тарифам.
Notion
У них развитая релавая модель: Guest, Member, Admin, права на уровне отдельного блока страницы. Технически впечатляет, но для флипбука это оверинжиниринг. Нашему пользователю нужно за 10 секунд решить кто увидит документ. Матрица прав для этого явно избыточна.
DocSend & Pitch
Здесь нашёл решение которое зацепило больше всего. Читатель переходит по ссылке, вводит корпоративный email, получает одноразовый пин-код на почту, попадает в документ. Email сам становится ключом доступа и заодно источником данных о читателе.
Flipsnack
Проверил их админку тем же способом. Защита ограничивалась паролем и не публичной ссылкой. У них нет ничего похожего на верификацию через email или по SSO, хотя Enterprise-рынок уже требует эти фичи.
Ключевой инсайт
Анализ показал, что крупному бизнесу нужен гибкий контроль над контекстом распространения документов. А статичный пароль это лишь один из инструментов, которого Enterprise-клиентам недостаточно. Им важно разграничивать доступ: от полностью открытого SEO-каталога до закрытого драфта или защищенного эмбеда, который физически не откроется за пределами корпоративного портала.
ALIGNMENT
Договариваюсь со стейкхолдерами
Процесс согласования
Информационную архитектуру и логику переключения режимов я пересобирал 6 раз. Мы внутри команды искали самое удачное решение по UX, а CEO активно участвовал в процессе и лично отсматривал каждый вариант. Первые концепты он отклонял, поэтому мы крутили логику до тех пор, пока она не стала прозрачной.
Кросс-функциональный синк
Финальное решение мы вынесли на большое обсуждение со стейкхолдерами: лидами разработки, сейлзов и саппорта. В нашей компании каждый мог повлиять на результат, поэтому нам важно было собрать фидбек со всех сторон. При утверждении нейминга я опирался на результаты своего ресёрча рынка. Мы вместе смотрели, как приватность устроена в других продуктах, чтобы использовать привычные паттерны. В итоге CEO предложил рабочую версию названий, которая устроила всю команду. Позже маркетологи переиспользовали этот нейминг для продуктового лендинга.
Тестирование и финализация
После того как команда утвердила концепт, я задизайнил новые компоненты для дизайн-системы и собрал интерактивный прототип. На нем я провел коридорное юзабилити-тестирование, чтобы проверить основные гипотезы. Тесты полностью подтвердили логику интерфейса.
Результат
После этого я зафиналил макеты для всех разделов сервиса и передал их в разработку. На этапе реализации я полностью курировал процесс через дизайн-ревью, а развитием следующих итераций занимался уже позже.
STRATEGY
Определение скоупа
Приоритизация
Разработка SSO с нуля стоила бы бизнесу слишком дорого и заняла бы месяцы (недопустимо при горящих сделках). Я настоял на сплит-релизе: - Фаза 1 (MVP): Выкатить базовую архитектуру режимов (особенно Protected Embed, который закрыл 80% потребности B2B-клиентов в интранетах). - Фаза 2: Сложные Enterprise-интеграции (SSO/Email) отложить до момента, когда архитектура докажет свою ценность.
Итог
Приоритезация происходила по фреймворку RICE. Это позволило выпустить рабочий продукт в короткие сроки, остановить отток лидов и сэкономить месяцы дорогой разработки на старте.
2 •
Деливери
ARCHITECTURE
Архитектура режимов
Архитектура
Выстроил базовые режимы по шкале от открытого к закрытому: - Public — доступен всем, индексируется поисковиками. - Shareable link — доступ по ссылке (без индексации). - Password — доступ по единому паролю. - Protected embed — встраивание только на разрешённые домены. - Private — доступен только внутри аккаунта.
Логика взаимодействия
Собрал модульную систему на базе больших radio buttons: каждый режим — отдельная карточка с настройками. Юзер кликает на режим и сразу видит его параметры без переходов и модалок. Вертикальный список работает как шкала защиты: юзер интуитивно «скользит вниз к закрытому». Модульность позволяла встраивать новые режимы без переделки всей панели.
Итог
Пароль остался как самостоятельный режим, но параллельно мы заложили возможность вешать его как дополнительный слой защиты на другие режимы (Protected embed, а позже и Email restriction). Это сохранило привычный флоу для старых юзеров, но дало гибкость Enterprise-клиентам.
ARCHITECTURE
Проектирование апселл-путей (PLG)
Growth Design
Особый фокус сделал на заблокированные состояния (Locked States) для младших тарифов. Вместо скрытия недоступных enterprise-режимов, вывел их в интерфейс с иконкой замка. При ховере на (i) появляется тултип с ценностью режима и кнопкой «Upgrade». Юзер узнаёт о фиче ровно тогда, когда она ему нужна.
Что это дало
Утилитарное меню стало инструментом Product-Led Growth. По данным трекинга, эта механика дала +15–20% прироста к органическим Self-Serve апгрейдам.
SYNCRONIZATION
Синхронизация с разработкой
Матрица состояний
До отрисовки UI я собрал полную матрицу состояний: 7 режимов × 7 тарифов × 3 контекста шаринга. Зафиксировал все эдж-кейсы: - Что происходит при даунгрейде тарифа? - Как ведет себя пароль при переключении режима?
Что это дало
С фронтами сразу обсудили ограничения стека. Именно это привело нас к модульной системе с большими карточками — фронты подтвердили, что такой паттерн легко скейлить. Ни один макет не уходил в разработку без полного описания стейтов.
Validating
Юзабилити-тестирование
Прототипирование
Собрал в Figma интерактивный прототип высокого уровня (Hi-Fi) с использованием переменных и логических условий. Это позволило симулировать реальную настройку: юзеры могли переключать режимы, видеть, как меняется логика доступа, и взаимодействовать с Locked States.
Инструменты и масштаб
Провел 8 модерируемых сессий через Zoom. Чтобы проверить решение на разных масштабах, пригласил не только Enterprise клиентов, но и фрилансеров на базовых тарифах. Это помогло убедиться, что сложность настроек не «убивает» юзабилити для простых сценариев. - Задача: Настроить доступ так, чтобы документ видела только внутренняя команда, не используя при этом пароль. - Метрика: Time on Task и отсутствие критических ошибок (без подсказок).
Итог
8 из 8 успешно справились. Медианное время — 1:20. Новая иерархия считывалась мгновенно, а логика пароля как опционального слоя защиты не вызвала вопросов. Гипотезы подтвердились на этапе прототипа, что сэкономило недели разработки.
TIMELINE
Запуск и влияние
Запуск
Privacy MVP успешно выкатили в 2022 году. Новую модель доступов раскатали на все точки продукта бесшовно. Еще во время разработки v1 более 10 крупных аккаунтов подтвердили свой запрос на SSO. Но V1 настолько хорошо закрыла базовую боль (уронив тикеты в саппорт на 80%), что приватность перестала быть «красной зоной» для бизнеса. Компания смогла перебросить ресурсы на другие фичи. К полноценной Фазе 2 (SSO и Email) планово вернулись в 2024–2025 годах.
Результаты
- Саппорт: Обращения по доступу упали с 40–50 до 8–10 в месяц уже в первом квартале 2020 года.
- Продажи: Возражение «у вас нет настроек приватности» полностью ушло из разборов воронки. Провел демо-сессию для сейлзов, после чего они начали продавать саму панель доступов как фичу.
- Adoption: Больше 70% корпоративных аккаунтов начали юзать комбинации из двух и более режимов в первые месяцы после запуска.
- Монетизация (PLG): Locked States дали ~15–20% прироста self-serve апгрейдов по данным трекинга CTA.
- Масштабирование: С запуском Фазы 2 продукт закрыл полный Enterprise-стек доступов, перейдя в класс полноценных B2B-платформ.
Итоговое решение
Архитектура ДС
7 слайдов
Прототип
Результаты
Time to Market
Внедрение
Ускорение на
~45%
В $ эквиваленте
$XXXk+
В продукте
100%
Послевкусие
Рефлексия
Стратегическая ценность
Сейлзы получили мощный аргумент для закрытия сделок с Enterprise клиентами, а Саппорты освободились от кучи однотипных вопросов про настройку доступа к флипбукам.
Чего не ожидал
Проектирование всех пересечений (режимы × планы × контексты) сожрало больше времени, чем отрисовка самого UI. Если бы делал это сейчас, отдал бы генерацию таблицы состояний и краевых случаев AI-инструментам, чтобы быстрее перейти к валидации.
Что сделал бы иначе
Сейчас пароль висит и как самостоятельный режим, и как надстройка для других режимов. Выделение защиты (пароля) в полностью независимый слой модификаторов дало бы еще более чистую ментальную модель. Сначала юзер решает «кто имеет доступ», а потом «нужна ли парольная защита».
