Проектирую сложные цифровые продукты, которыми удобно пользоваться.

Моя роль: от выбора решения до реализации

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

Задача была не в полном редизайне продукта, а в улучшении конкретного этапа — перехода от регистрации к созданию первого устройства.

Проблема: аккаунт создан, использование не началось

Для начала работы с AdGuard DNS недостаточно зарегистрироваться: нужно добавить устройство и настроить на нём DNS. Потери пользователей происходили на обоих этапах.

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

В этом кейсе фокус — на первом этапе. Создание устройства и успешная настройка DNS — разные события, и результат одного нельзя выдавать за улучшение другого.

Гипотеза: один понятный следующий шаг

Если сразу после регистрации адаптировать дашборд к первому визиту, убрать второстепенные действия и оставить один основной призыв «Подключить устройство», больше новых пользователей создадут первое устройство.

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

Решение: отдельное состояние для первого визита

1. Один основной призыв вместо трёх. Раньше подключение предлагалось в приветственном баннере, пустом графике и блоке сервера. В новом состоянии основная кнопка находится в центральном блоке дашборда, а приветственное сообщение объясняет, с чего начать.
2. Объяснение вместо статистики без данных. Стартовый блок сообщает, что статистика появится после подключения устройства. Из первого состояния убраны выбор периода, переключение общей защиты и предложение изменить тариф.
3. Разные состояния для разных ситуаций. Новый пользователь и пользователь, удаливший все устройства, не должны видеть одинаковый экран. После регистрации показывается упрощённое стартовое состояние. После удаления устройств сохраняется привычный дашборд с историей статистики и возможностью подключить устройство заново.

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

Работа с разработчиками и проверка реализации

Мой вклад не ограничивался макетами. Я участвовал в выборе вариантов решения, работал с разработчиками и проверял реализацию на соответствие согласованному дизайну.

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

Результат: больше пользователей создают первое устройство

После обновления доля новых пользователей, создавших первое устройство, выросла на 9,8 процентного пункта.

В 2026 году сравнили два периода по 28 дней — до и после изменений. Других изменений в эти периоды не было. Абсолютные значения конверсии и объёмы выборок не раскрываются по NDA.

Результат относится к созданию первого устройства. Он не подтверждает рост завершённых настроек DNS, удержания или выручки.

Что осталось за рамками этого решения

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

Это потенциальные направления, а не выполненные изменения или результаты данного кейса.

Задача: спроектировать новый сценарий пробного доступа

Раньше в AdGuard DNS не было сценария подключения триала. Предстояло создать новый путь: дать пользователю возможность попробовать продукт и понять условия дальнейшей подписки.

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

Единый интерфейс должен был учитывать разные типы аккаунтов, тарифы, валюты и правила оплаты.

Моя роль: от конкурентного анализа до проверки реализации

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

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

Конкурентный анализ: не только экраны, но и правила подключения

Изучил сценарии пробного доступа у DNS- и облачных сервисов, в том числе Cloudflare, DNSimple, Google Cloud и BunnyDNS. Сравнивал, когда они запрашивают карту, как показывают стоимость и ограничения, объясняют отмену и предупреждают о переходе к оплате.

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

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

Решение: условия, выбор и следующий шаг в одном сценарии

1. Показать, что произойдёт дальше. Временная последовательность объясняет начало триала, напоминание перед его завершением и последующее действие: автоматический переход к платной подписке либо завершение пробного доступа.
2. Учесть контекст аккаунта. Для персонального аккаунта предвыбран тариф Personal, для бизнес-аккаунта — Team. Выбор можно изменить. Рядом показаны стоимость и основные лимиты тарифа.
3. Разделить сценарии с картой и без неё. В сценарии с картой прямо указано автоматическое продление подписки, если её не отменить. Для оплаты в рублях триал подключается без ввода карты, а платная подписка не начинается автоматически. Меняются не только валюта, но и пояснения и завершение сценария.
4. Сохранить возможность отказаться. Пользователь может не подключать триал и закрыть предложение. В макетах зафиксировано, что закрытие окна работает так же, как пропуск предложения.
5. Адаптировать сценарий к разным экранам. Подготовлены десктопная, планшетная и мобильная версии, а также тёмная тема. На узком экране выбор тарифа, условия и последовательность событий собраны вертикально без исключения существенной информации.

От согласования до запуска

Участвовал в согласовании решения и передаче макетов разработчикам, затем проверял реализацию на соответствие согласованному дизайну.

Сценарий реализован и работает в продакшене — пользователи уже оформляют триал. Работа завершилась не макетами, а запуском новой функции продукта.

Результат: новый путь от пробного доступа к оплате

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

По данным за 2025 год, около 5% оформленных триалов конвертировались в оплату, около 95% — нет. Абсолютные показатели не раскрываются по NDA.

Эти данные описывают работу новой функции, а не прирост к существовавшему ранее сценарию: до запуска триала в AdGuard DNS не было.

Мой вклад — перевод поставленной задачи в целостный пользовательский сценарий и сопровождение решения до реализации.

Инициатива: заметить проблему без готовой задачи

Работа началась не с входящего задания. Я самостоятельно изучил статистику сайта AdGuard DNS и выявил, что более 60% пользователей используют мобильные устройства: на Android приходится 33%, на iOS — около 30%.

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

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

Проблема: адаптивная вёрстка ещё не делает интерфейс удобным

На смартфоне важно не просто уместить десктопные блоки по ширине. Пользователю нужно видеть статистику, выбирать нужные данные и управлять аккаунтом в ограниченном пространстве экрана.

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

Цель — пересмотреть мобильные сценарии, а не только уменьшить десктопные экраны.

Декомпозиция: от общей проблемы к конкретным изменениям

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

• Статистика. Компоновка заголовка и основных действий на узком экране.
• Фильтры. Мобильное окно настройки и логика выбора периода, серверов, устройств и стран.
• Участники. Форма приглашения с выбором роли и состояниями ошибок.

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

Решение: компактная навигация и отдельная настройка фильтров

1. Основные действия рядом с заголовком. В обновлённом экране статистики фильтры и обновление перенесены в одну строку с названием раздела. Отдельная строка управления больше не занимает место над графиком.
2. Фильтры в отдельном окне. Период, серверы, устройства и страны собраны вертикально. Предусмотрены исходное и заполненное состояния, сохранение выбора и сброс фильтров. Длинные значения сокращаются внутри поля, а множественный выбор обозначается количеством выбранных элементов.
3. Определённая логика селекторов. Для серверов и стран предусмотрен поиск, для множественного выбора — чекбоксы. По умолчанию список стран не включает значения без запросов; полный список доступен через «Показать ещё». Эти правила зафиксированы в аннотациях к макетам.
4. Ошибки рядом с полем. В форме приглашения участника показаны отдельные сообщения для неверного email, уже добавленного участника, повторного приглашения и приглашения самого себя. В ошибочных состояниях добавление недоступно, а отмена остаётся доступной.

Реализация: сопровождение изменений до запуска

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

Все показанные изменения реализованы и работают в продукте: мобильная статистика, фильтры и состояния формы приглашения участников.

Итог: собственная инициатива доведена до продукта

Я самостоятельно обнаружил повод для улучшения, сформулировал и декомпозировал задачу, спроектировал решения и сопровождал их до запуска.

Данных о влиянии изменений на удобство использования, выполнение сценариев, удержание или конверсию пока нет. Поэтому я не приписываю обновлению рост этих показателей.

Доля мобильной аудитории — исходный контекст, а не результат редизайна. Подтверждённый итог работы — внедрённые изменения интерфейса.

Проблема: отдельными аккаунтами школ сложно управлять

В городе было много школ, каждая со своим аккаунтом AdGuard DNS. Управление ими было разрозненным: ответственные могли забыть или не успеть оплатить подписку, а настройки родительского контроля отличались от школы к школе.

Запрос был шире, чем добавление ещё одного пользователя. Требовалось организовать совместную работу: определить, кто отвечает за оплату, кто управляет настройками, а кто только просматривает данные.

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

Исследование: пройти сценарии, а не только собрать экраны

Провёл конкурентный анализ Cloudflare и Bunny DNS, собрал доску с примерами реализации. Регистрировался в сервисах и изучал доступные сценарии — от создания аккаунта до управления участниками.

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

Подходы требовалось адаптировать к структуре аккаунтов, биллингу и правилам доступа AdGuard DNS.

Уточнение требований: одинаково понимать права ролей

В модели были предусмотрены три роли:

• Owner — владелец аккаунта, отвечает за биллинг и приглашает участников.
• Admin — управляет настройками, но не оплачивает подписку и не приглашает участников.
• Viewer — просматривает данные без изменения общих настроек.

При обсуждении реализации обнаружилось расхождение: фронтенд-команда считала, что Admin тоже может приглашать Viewer. Ошибка присутствовала и в описании задачи.

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

Решение: показывать контекст аккаунта и границы доступа

1. Осознанный выбор аккаунта. Предложил отдельный шаг выбора после авторизации для пользователей с несколькими аккаунтами. Так человек сразу видит, куда входит. Для переключения во время работы добавил выпадающее меню в боковой навигации и отметку Current у текущего аккаунта.
2. Разделение личных и общих настроек. Предложил разделить настройки пользователя и настройки DNS-аккаунта. Это помогает различать изменения для себя и изменения, затрагивающие остальных участников.
3. Биллинг как отдельный раздел. Вынес управление оплатой в отдельный пункт бокового меню, чтобы владельцу было проще найти настройки подписки.
4. Понятный режим просмотра. Для Viewer решили сохранить общие настройки видимыми, но недоступными для изменения. Пользователь может понять конфигурацию аккаунта, не получая возможности случайно её изменить. Плашка объясняет режим просмотра: если нужны другие права, необходимо обратиться за ролью Admin; если выбран не тот аккаунт — переключиться на нужный.

Проверка реализации: найти несоответствия в работающем продукте

Участвовал в тестировании на Dev и передал команде список расхождений. Проверка выявила несколько важных деталей:

• Неочевидное состояние отправленного приглашения. Предложил неактивное состояние иконки письма и поясняющую подсказку, чтобы интерфейс отражал статус действия.
• Неполные ограничения Viewer. На дашборде часть настроек оставалась доступной. Несоответствие исправили.
• Недостаточный акцент на собственном аккаунте. В списке выбора аккаунт с ролью Owner терялся среди остальных. Предложил поднять его наверх и выделить полужирным начертанием.

Сопровождал решение до запуска и участвовал в исправлении несоответствий реализации. Работа над письмами не входила в мой вклад: задачи по ним обрабатывались отдельно.

Результат: ролевая модель запущена в продукте

В AdGuard DNS реализованы роли Owner, Admin и Viewer, приглашение участников, выбор и переключение аккаунтов, разделение настроек и ограничения действий в зависимости от роли. После проверки реализации также вышли исправления выявленных несоответствий.

Мой вклад охватил путь от конкурентного анализа и уточнения требований до проектирования экранов, тестирования на Dev и сопровождения исправлений. После запуска я отслеживал пользовательскую обратную связь через Trustpilot; содержание отзывов в кейсе не раскрывается.

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

Дальнейшее развитие — отдельная задача

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

Это последующее развитие продукта, а не результат проекта ролевой модели.