Настройки приватности

Исследование

Я пошел к командам Sales и Support, чтобы собрать контекст вокруг жалоб и посчитать реальные потери бизнеса. Сначала составил скрипт вопросов для сейлзов про сорванные сделки. Затем залез в Jira и ZenDesk, выгрузил обращения клиентов за последние полгода и с помощью Claude раскидал их по категориям. Это помогло найти точные паттерны и сформулировать боли наших пользователей.

Этапы

Сперва разобрал воронку продаж с лидом Sales. Выяснил, что крупные клиенты отваливаются на этапе Security Check, когда узнают, что у нас есть только пароль. Потом проверил 150+ обращений в саппорт, объединил их в массив данных и проанализировал с помощью Claude. В итоге выделил паттерн: юзеры искали способы управления доверием. Им важно было контролировать, кто, когда и откуда открывал их ссылку.

Концептуальная проблема

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

Анализ рынка

Завёл триал-аккаунты в DocSend, Pitch, Notion и Flipsnack. Для последних двух сервисов пришлось запрашивать корпоративные профили, потому что на триале Enterprise-настройки закрыты.

В каждом сервисе создавал тестовые документы, настраивал доступ, отправлял ссылку себе, пробовал переслать её коллегам и проверял что происходит при попытке обойти защиту.

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

Notion

Они используют развитую ролевую модель: Guest, Member, Admin. А права настраиваются на уровне отдельного блока страницы. Технически впечатляет, но для флипбука это оверинжиниринг. Нашему пользователю нужно за 10 секунд решить кто увидит документ. Матрица прав для этого явно избыточна.

DocSend & Pitch

Здесь нашёл решение которое зацепило больше всего. Читатель переходит по ссылке, вводит email, получает OTP-код на почту и только потом попадает в документ. Email становится ключом доступа и заодно источником данных о читателе.

Flipsnack

Их настройки приватности ограничивались паролем и непубличной ссылкой. У них нет ничего похожего на верификацию через email или по SSO, хотя Enterprise-рынок уже требует эти фичи.

Ключевой инсайт

Анализ показал, что крупному бизнесу нужен гибкий контроль над контекстом распространения документов. А статичный пароль это лишь один из инструментов, которого Enterprise-клиентам недостаточно. Им важно разграничивать доступ: от полностью открытого SEO-каталога до закрытого драфта или защищенного эмбеда, который физически не откроется за пределами корпоративного портала.

Job Statement

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

Гипотезы

1. Если заменить пароль на понятные готовые пресеты приватности, пользователи станут чаще трогать эти настройки. Мы сможем проверить это по росту процента защищенных файлов в общей базе сервиса.
2. Проектирование пяти режимов по принципу нарастания защиты снизит когнитивную нагрузку. Пользователь интуитивно выберет уровень безопасности без чтения инструкций, что подтвердится отсутствием критических ошибок.
3. Демонстрация продвинутых режимов на базовых тарифах создаст PLG-эффект. Пользователь увидит решение своей боли и сам инициирует переход на дорогой тариф. Гипотеза подтвердится, если вырастет количество самостоятельных апгрейдов из меню Privacy.

Как проверял

Набросал user-flow и базовые логические схемы под каждый сценарий, обсудил их с PM и CEO, а затем вместе приоритизировали фичи по матрице RICE. Встретились с разработчиками, показали готовые схемы и обсудили сложность реализации. Благодаря этому мы быстро определили какие решения идут в MVP.

Что вошло в MVP

В первую версию мы включили пять режимов приватности. Сложные настройки доступа (Restricted Access по email и SSO) мы осознанно вынесли во второй этап разработки, чтобы быстрее проверить ценность обновленной архитектуры на реальных пользователях.

Технические ограничения

Во время обсуждений мы столкнулись с жесткими ограничениями бэкенда. Разработка полноценного Restricted Access с логикой рассылки одноразовых OTP-кодов по email требовала настройки почтовых серверов и серьезно сдвигала сроки релиза. Интеграция с корпоративным SSO выходила ещё дороже. В то же время сейлзы подтвердили, что на старте смогут закрывать сделки и без SSO, если мы дадим клиентам базовую защиту от копирования.

Продуктовое решение

Мы пошли на осознанный компромисс ради скорости релиза. Вместо сложной почтовой верификации в MVP пошел режим Protected Embed. Технически привязать открытие книги к конкретному URL-адресу для разработчиков было намного проще. Это закрыло 80% потребностей B2B-клиентов, которым нужно было защитить интранет от утечек контента.

А авторизацию через почту и SSO мы зафиксировали в бэклоге как техдолг для второй фазы.

Интерфейсный костыль

Чтобы не тормозить выпуск фичи, в интерфейсе пришлось оставить компромиссное решение. Мы позволили пользователям задавать пароль как отдельным режимом, так и добавлять его поверх Protected Embed. С точки зрения архитектуры UI это костыль, но он позволил фронтенду переиспользовать старую логику паролей, сэкономил недели разработки и помог нам быстрее выкатить MVP в продакшн.

Итог

Компромисс с разработкой сэкономил компании месяцы дорогого бэкенд-производства на старте. Мы успешно выкатили базовый MVP в короткие сроки (3 мес.), снизили отток B2B-клиентов и защитили горящие сделки.

Логику авторизации по почте и SSO мы заморозили в бэклоге и вернулись к ней уже на следующем этапе, когда пришло время масштабировать систему.

Процесс согласования

Я прошёл шесть итераций по информационной архитектуре и логике переключения режимов. Мы с PM искали удачное решение по UX, а CEO активно участвовал в процессе и лично отсматривал каждый вариант. Первые концепты он отклонял, поэтому мы крутили логику до тех пор, пока она не стала прозрачной для всех.

Кросс-функциональный синк

Я вынес финальное решение на большое обсуждение со стейкхолдерами: лидами разработки, сейлзов и саппорта. В нашей компании каждый мог повлиять на результат, поэтому нам важно было собрать фидбек со всех сторон.

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

Результат

В итоге я зафиналил макеты для всех разделов сервиса и передал их в разработку с подробным описанием всей логики и краевых случаев. На этапе реализации я курировал процесс через дизайн-ревью.

Логика интерфейса

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

Снижение когнитивной нагрузки

Вертикальный список работает как шкала защиты: пользователь интуитивно скользит взглядом сверху вниз, от публичного документа к приватному. Такая модульная структура позволила нам легко закладывать новые сложные сценарии (вроде Restricted Access) без переделки всей панели.

Пароль остался как самостоятельный режим, но параллельно мы дали возможность настроить его как дополнительный слой защиты поверх других сценариев (Protected Embed, а позже и Email restriction). Это технически компромиссное решение сохранило привычный флоу для старых пользователей и дало быструю гибкость Enterprise-клиентам.

Product-Led Growth

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

Компонентное решение

Особый фокус был сделан на Locked States для младших тарифов. Я спроектировал и добавил в UI-кит новые системные стейты для компонентов Privacy. Теперь у любого режима появился визуальный язык блокировки, который можно переиспользовать в других продуктовых разделах.

Self upgrade

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

Перспективы развития

Апселл механика раскрылась на максимум на втором этапе развития продукта, когда мы выкатили Restricted Access. Эти режимы приватности стали главным триггером для B2B-клиентов на младших тарифах, подталкивая их к осознанному переходу на Team и Enterprise планы прямо из панели настроек Privacy.

Что это дало

Утилитарное меню настроек превратилось в полноценный инструмент Product-Led Growth. По данным продуктового трекинга, внедрение заблокированных стейтов и контекстных тултипов дало ~20% прироста к органическим Self-Serve апгрейдам внутри личного кабинета, без привлечения команды сейлзов.

Прототипирование

Я собрал в Figma интерактивный прототип с использованием переменных и conditional logic. Настроил симуляцию реального интерфейса: переключение пяти базовых режимов приватности, динамическое изменение параметров внутри карточек и кликабельные Locked States. Это позволило проверить ключевые сценарии до передачи макетов в разработку.

Инструменты и масштаб

Провел 12 модерируемых сессий через Zoom с записью экрана. В пул респондентов включил 4 B2B клиента, 4 B2C на младших тарифах и 4 коллеги из смежных команд. Разделение сегментов было необходимо, чтобы проверить, как усложнение архитектуры безопасности влияет на опыт различных групп пользователей.

Задачи для респондентов

1. Ограничить доступ к документу так, чтобы его можно было открыть только внутри корпоративного сайта компании.
2. В половине случаев нужно было использовать пароль как модификатор, так мы проверяли самый запутанный сценарий работы с Protected Embed.
3. Ограничить доступ всем, сделать флипбук недоступным для других пользователей (механика Draft).

Метрики

Успешность выполнения (Success Rate), время выполнения (Time on Task) и количество критических ошибок без подсказок модератора.

Итог тестирования

Все 12 респондентов успешно выполнили задачу. Медианное время составило ~35 секунд. Тесты подтвердили, что вертикальная иерархия режимов считывается сразу. Наложение пароля как дополнительного слоя поверх Protected Embed не вызвало затруднений. Проверка концепта на этапе прототипа исключила переделки логики в коде и сэкономила ресурсы бэкенд-разработки.

Анализ MVP и продуктовые выводы

По данным продуктовой аналитики, фича показала повышение уровня удержания (Retention) на ~15% среди B2B-пользователей. Protected embed закрыл базовые боли клиентов, но обратная связь из саппорта и переговоры на крупных сделках требовали двигаться дальше.

Проектирование Restricted Access

В конце 2024 года мы вернулись к бэклогу, чтобы разработать долгожданный режим приватности — Restricted Access.

Интерфейсно мы упаковали его внутрь уже существующей модульной панели в виде отдельной радио-карточки. Внутри нее мы спроектировали два таба для разных сценариев авторизации читателей: верификацию по индивидуальным Email / корпоративным доменам и вход через SSO. Это позволило нам сохранить компактность общего интерфейса кастомизации и не перегружать пользователя лишними сущностями.

UX-механика списков доступа

Основной вызов при проектировании интерфейса управления доступом по почте (Email/Domain) заключался в удобстве работы со списками. Менеджеры крупных компаний редко добавляют по одному человеку — они приходят с готовыми базами на сотни адресов. Я спроектировал кастомное поле ввода, которое на лету парсит скопированный текст из Excel или Slack. Система автоматически распознает разделители, валидирует адреса, отсекает дубликаты и мгновенно превращает массив текста в аккуратные теги-бейджи.

Сценарии для читателей

Помимо админки для автора, я полностью спроектировал экраны авторизации, которые видит конечный читатель при попытке открыть защищённый флипбук. Проработал логику двух сценариев: вход через корпоративный SSO и интерфейс ввода одноразового OTP-кода для верификации по email. Отдельно задизайнил все краевые случаи: состояния ошибок при вводе неверного кода, экраны с истекшим временем действия сессии и заглушки Access Denied для пользователей, чьих адресов не оказалось в списках компании.

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

Запуск

Privacy MVP выкатили в продакшн в Q1 2022 года. Новую модель настроек интегрировали во все точки продукта сохранив консистентный UX.

Еще на этапе проектирования v1 крупные аккаунты запрашивали интеграцию со SSO. Однако запуск MVP закрыл базовые риски безопасности и снизил объем обращений в саппорт на 80%. Это позволило бизнесу снять приоритет с этой задачи и временно переключить ресурсы разработки на другие продуктовые фичи. К полноценной Фазе 2 планово вернулись и запустили в Q2 2025 года.

Результаты

• Количество обращений по вопросам приватности снизилось с ~50 до ~10 в месяц после релиза MVP.
• Провел демо-сессию для стейкхолдеров на общем собрании, после чего сейлзы начали использовать новую панель как аргумент при заключении сделок.
• Более 70% корпоративных аккаунтов активировали комбинацию из двух и более режимов в первые три месяца после запуска.
• Внедрение Locked States внутри интерфейса обеспечило прирост self-serve апгрейдов на ~20% по данным трекинга кликов на CTA.
• Запуск новых режимов в 2025 году позволил нам заключить крупные сделки уже в следующий квартал.