Respondly — сервис подбора респондентов
Как спроектировать регистрацию и сбор согласий без лишних барьеров для пользователя
Отвечала за UX-архитектуру пользовательского пути, исследование потребностей, сценарии согласий, UX-копирайтинг и UI-кит, дизайн QA.
Цель: создать понятный и реализуемый MVP-сценарий для заказчика и респондента с учетом всех правовых норм и требований.
Результат: спроектировала MVP-сценарий регистрации и согласий, в котором пользовательские действия связаны с целями обработки данных и техническим логированием. Подготовила UX-основу для реализации продукта с учётом требований 152-ФЗ.
Контекст
Respondly — сервис, соединяющий заказчиков исследований с подходящими респондентами для CustDev, глубинных интервью и UX-тестирований.
Проблема: продукт создавался с нуля. Нужно было спроектировать регистрацию, скрининг и отклик на исследование, одновременно предусмотрев сбор и фиксацию согласий на обработку персональных данных.
Проблема: продукт создавался с нуля. Нужно было спроектировать регистрацию, скрининг и отклик на исследование, одновременно предусмотрев сбор и фиксацию согласий на обработку персональных данных.
UX-конфликт: чем больше информации и согласий пользователь видит на старте, тем выше нагрузка на первый шаг. Но упрощение сценария не должно приводить к сбору данных без понятной цели или необходимого согласия.
Цель: найти баланс между тремя требованиями.
- Для респондента: понятные условия участия, прозрачность обработки данных и контроль над предоставляемой информацией.
- Для бизнеса: релевантные заявки и управляемая воронка.
- Для разработки: однозначная связь между пользовательским действием, данными и записью согласия.
Решение:
Провела 14 интервью и опрос среди 50+ потенциальных респондентов.
Исследование помогло сфокусироваться на трёх вопросах:
– Когда пользователь готов делиться контактами?
– Какие сведения вызывают опасения и требуют дополнительного объяснения?
– Как объяснить условия участия и обработки данных до получения персональной информации?
Ключевой вывод: сначала пользователь должен понять, подходит ли ему исследование и зачем сервису нужны данные. Поэтому контактные данные были перенесены на более поздний этап.
– Когда пользователь готов делиться контактами?
– Какие сведения вызывают опасения и требуют дополнительного объяснения?
– Как объяснить условия участия и обработки данных до получения персональной информации?
Ключевой вывод: сначала пользователь должен понять, подходит ли ему исследование и зачем сервису нужны данные. Поэтому контактные данные были перенесены на более поздний этап.
- Изучила требования № 168-ФЗ, № 152-ФЗ «О персональных данных», скоординировала работу по копирайту и флоу с юристом;
- Сформировала информационную архитектуру регистрации и скрининга;
- Определила сценарии согласий с учётом момента сбора данных;
- Связала пользовательские действия с ERD и аудиторским логом;
- Структурировала лендинги как инструмент коммуникации продукта и дополнила минимальным UI-китом для быстрой масштабируемой вёрстки.
Метрики: конверсия по этапам воронки, доля отказа на каждом шаге согласий, время до целевого действия (TTA), глубина скролла, дополненные интервью для качественного контекста. Baseline для сравнения не было: система строилась с нуля.
От модели данных к пользовательскому сценарию
Задача: спроектировать путь, где каждое юридическое согласие технически обосновано, а не добавлено «на всякий случай».
Решение: вместе с PO я определила, какие данные нужны сервису на каждом этапе и для каких целей они используются.
Решение: вместе с PO я определила, какие данные нужны сервису на каждом этапе и для каких целей они используются.
На основе этой структуры выстроила последовательность пользовательского пути:
Знакомство с сервисом → скрининг → базовые согласия → дополнительные данные при необходимости → отклик на конкретное исследование → участие.
Для каждого согласия определила:
Знакомство с сервисом → скрининг → базовые согласия → дополнительные данные при необходимости → отклик на конкретное исследование → участие.
Для каждого согласия определила:
- на каком этапе оно требуется;
- с каким действием и данными связано;
- какую запись необходимо сохранить в аудиторском логе.
Результат: каждый чекбокс в интерфейсе имеет прямую привязку к полю в схеме данных и отдельную запись в аудиторском логе (дата/время, IP, версия документа, user_id) — это стало общим языком с разработчиком для обсуждения статуса реализации.
Почему не все согласия на первом экране
В ходе тестирования отказалась от варианта с единым блоком всех согласий на входе. Он был проще для первоначальной сборки, но одновременно перегружал первый шаг, смешивал разные цели обработки данных и требовал бы просить чувствительные сведения у пользователей, которым они не нужны.
Вместо этого согласия стали появляться прогрессивно:
Это решение усложнило модель данных, зато сделало связь между действием пользователя, целью обработки и юридической записью прозрачной.
Вместо этого согласия стали появляться прогрессивно:
- базовые — на обработку персональных данных, участие в исследованиях и передачу данных заказчикам;
- условные — на расширенные данные, например доход, наличие детей или сведения о здоровье;
- контекстные — на участие в конкретном исследовании, аудио- или видеозапись, NDA при необходимости.
Это решение усложнило модель данных, зато сделало связь между действием пользователя, целью обработки и юридической записью прозрачной.
Контакты после скринера, а не до
Проблема: ранний запрос выглядел для респондента как «плата за вход» и создавал страх: пользователь мог оставить контакты, а затем узнать, что не подходит под критерии исследования.
Решение: «сначала польза и проверка релевантности, потом контакты» одновременно снижало психологический барьер регистрации; не создавало лишних нерелевантных лидов; уменьшало ранние комплаенс-риски; делало конверсию более содержательной. Заявка означала не просто оставленный контакт, а пройденный путь до релевантного отклика.
Решение: «сначала польза и проверка релевантности, потом контакты» одновременно снижало психологический барьер регистрации; не создавало лишних нерелевантных лидов; уменьшало ранние комплаенс-риски; делало конверсию более содержательной. Заявка означала не просто оставленный контакт, а пройденный путь до релевантного отклика.
Интерактивная БАЗА для быстрй верстки
Сервис предполагает четыре направления лендингов на основе сегментации ЦА:
Чтобы не собирать каждую страницу заново, я создала минимальный гибкий UI-кит: повторяемые компоненты, базовые состояния и правила, достаточные для быстрой вёрстки и дальнейшего масштабирования через vibe coding. Это был не большой дизайн-системный проект, а прагматичный набор для MVP и следующих посадочных страниц.
- базовый — объясняет принцип работы Respondly;
- бизнесовый — показывает ценность сервиса для заказчиков исследований;
- кастомный — позволяет адаптировать подачу под конкретный сегмент или задачу;
- для респондентов — снижает тревожность и объясняет правила участия, оплату и обращение с данными.
Чтобы не собирать каждую страницу заново, я создала минимальный гибкий UI-кит: повторяемые компоненты, базовые состояния и правила, достаточные для быстрой вёрстки и дальнейшего масштабирования через vibe coding. Это был не большой дизайн-системный проект, а прагматичный набор для MVP и следующих посадочных страниц.
Поскольку продукт проектировался с нуля, исторических показателей для сравнения не было.
Для проверки решения использовала количественные показатели воронки и качественную обратную связь.
Что проверяли:
8 из 10 участников положительно оценили подход «сначала понять условия участия, затем предоставить контакты».
Отказ на этапе расширенных согласий составил 15%. Этот показатель рассматривался не изолированно, а с учётом того, какие данные запрашивались и зачем.
Что осталось для дальнейшей оптимизации
Следующий шаг: проверить, какие формулировки и элементы интерфейса создают затруднения.
Для проверки решения использовала количественные показатели воронки и качественную обратную связь.
Что проверяли:
- переходы между этапами пользовательского пути;
- отказы на шагах согласий;
- время прохождения скринера;
- причины остановки и опасения пользователей.
8 из 10 участников положительно оценили подход «сначала понять условия участия, затем предоставить контакты».
Отказ на этапе расширенных согласий составил 15%. Этот показатель рассматривался не изолированно, а с учётом того, какие данные запрашивались и зачем.
Что осталось для дальнейшей оптимизации
Следующий шаг: проверить, какие формулировки и элементы интерфейса создают затруднения.
Показатель | Результат | Как интерпретировать |
Лендинг → клик в скринер | 65–68% | Сильный переход из объяснения продукта в действие |
Скринер → базовые согласия | 55% | Основная точка трения и зона дальнейшей оптимизации |
Базовые → расширенные согласия | 90% | Около 53% пользователей от старта доходили до этого этапа |
Регистрация → отклик на исследование | 55% | Более содержательная конверсия после скрининга |
Отклик → фактическое участие | 63% | Показатель завершения пути до сессии |
Отказ на согласии на расширенные данные | 15% | Ожидаемый и полезный отсев при чувствительных данных |
Среднее время прохождения скринера | Около 3:10 | База для дальнейшего сокращения сценария |
Отзыв о формате «сначала польза, потом данные» | 8 из 10 | Качественный сигнал доверия, а не продуктовая метрика |
ВЫВОДЫ
В рамках проекта я:
- спроектировала пользовательский путь от знакомства с сервисом до отклика на исследование/заявку;
- разделила согласия по целям и моментам сбора данных;
- связала UX-сценарии с моделью данных и требованиями к аудиторскому логу;
- подготовила гибкий UI-кит для MVP и дальнейшего развития лендингов;
- заложила систему метрик для последующей оптимизации воронки.
Юридические требования часть UX-архитектуры.
Их необходимо учитывать при проектировании сценария и модели данных, а не добавлять в готовый интерфейс в виде набора чекбоксов.
Сложность реализации не всегда означает сложность пользовательского опыта. Внутренняя логика согласий стала детальнее, тогда как пользователь получал информацию по мере необходимости.
Качество заявки начинается до регистрации.
Скрининг до запроса контактов позволил выстроить путь вокруг релевантности исследования, а не простого сбора лидов.
Их необходимо учитывать при проектировании сценария и модели данных, а не добавлять в готовый интерфейс в виде набора чекбоксов.
Сложность реализации не всегда означает сложность пользовательского опыта. Внутренняя логика согласий стала детальнее, тогда как пользователь получал информацию по мере необходимости.
Качество заявки начинается до регистрации.
Скрининг до запроса контактов позволил выстроить путь вокруг релевантности исследования, а не простого сбора лидов.
Дизайн от «модели данных» более устойчивый путь для продуктов с высокими юр. рисками. Старт проектирования с составления ERD гарантировал, что ни один чекбокс не появился «для галочки»: у каждого есть техническое и правовое основание, что стало общим языком с разработкой.
