Бизнес-эффект
Сокращение Time-to-Market для настройки SEO оптимизации сайтов, устранение Downtime страниц при публикации и устранение рисков безопастности
Моя роль
Я была единственным дизайнером на проекте.
- Проводила глубинки сама и ставила задачи команде исследователей на основе полученной информации.
- Проектировала архитектуру ролей, файлов и SEO.
- Лидировала производство иллюстраций и коммуникационных материалов подрядчиками.
- Согласовала со стейхолдерами и Службой информационной безопастности новую схему ролей.
- Вместе с техлидом заложила дизайн-систему (Figma + Storybook).
Что такое Конструктор Лендингов Яндекса?
Конструктор лендингов Яндекса создавался как инструмент для быстрой проверки маркетинговых гипотез. Он позволял за несколько часов собрать страницу и запустить тест.
Со временем бизнес увидел потенциал low-code-подхода, и конструктор стали использовать для запуска полноценных сайтов. Изменился масштаб задач, но архитектура продукта осталась прежней.
Система не поддерживала требования к управлению доступами, безопасности и стабильной публикации. Часть сценариев приходилось реализовывать через обходные решения, крупные команды с жёсткими NDA не могли работать в платформе, а проекты, начатые на кастомной разработке, не возвращались. Перепубликация страниц могла приводить к временным потерям трафика.
Исследование
Переезд на новый стек стал возможностью пересобрать фундаментальные UX-проблемы, которые накапливались годами. Я инициировала исследование и сфокусировалась на двух ключевых ролях — менеджерах и исполнителях.
На основе результатов исследования мы сформировали пул гипотез, оценили их по RICE и отобрали наиболее перспективные.
Далее проверяли их через глубинные интервью и прототипирование, чтобы снизить риск ошибок до начала разработки.
Выводы
Глубинные интервью подтвердили ключевые гипотезы о проблемах пользователей.
Менеджеры сталкиваются с рисками при публикации (downtime и потеря SEO-трафика) и хотят контролировать изменения перед выходом в прод. Исполнители испытывают сложности с постановкой задач, доступами и тратят много времени на ручные SEO-настройки.
Исполнители испытывают сложности с постановкой задач, доступами и тратят много времени на ручные SEO-настройки.
Решение 1. Публикация без downtime
Было
Старая логика публикации работала по принципу «удалил страницу на проде, скопировал на её место страницу из песочницы». В момент обновления страница временно исчезала, что создавало риск потери трафика.
Стало
Я спроектировала новую логику бесшовной перезаписи: контент из песочницы накатывается поверх продовой версии без удаления страницы. URL сохраняется, публикация происходит без удаления.
Результат
- Downtime — 0 секунд.
- Риск потери трафика при обновлении контента устранён.
Результат
- Сократилось время запуска новых сайтов.
- Проекты получили возможность полноценно оптимизировать страницы для поиска без участия разработчиков.
Решение 2. SEO-инфраструктура и Time-to-Market
Было
Ранее SEO-задачи решались через костыли или ручную правку кода.
В системе не было сущности «сайт», поэтому настройками нельзя было централизованно управлять — их приходилось делать для каждой страницы отдельно или через разработку.
Стало
Я ввела новую сущность «сайт» и вынесла SEO-настройки на уровень сайта.
Добавила интерфейсы для управления robots.txt, sitemap и кастомными страницами 404, что позволило централизованно управлять SEO-инфраструктурой без привлечения разработчиков.
Решение 3. Гранулярные роли + прозрачность
Результат:
- Выдача ролей до продовых проектов выросла, 28% новых ролей — точечные.
- Исполниетли понимают, как запросить роль и как поделиться страницей для ревью внутри команды.
Стало
Я пересобрала модель ролей на более гранулярную (доступ до проекта, папки или страницы), чтобы устранить «барьер страха» у менеджеров перед делегированием. Согласовала со службой безопастности механизм работы со страницами в песочнице чтобы упростить процесс внутреннего ревью через временные доступы. Добавила прозрачности: индикатор текущей роли прямо в интерфейсе Конструктора и связку с IdM, чтобы при запросе доступа данные о проекте пробрасывались автоматически.
Было
Фактические права не соответствовали названиям ролей и отсутствовала их индикация в интерфейсе, что заставляло пользователей интерпретировать ограничения системы как технические баги. Объем доступов для исполнителей был слишком широким поэтому менеджеры переносли
Доступ к странице в песочнице
Информация о текущей роли
Результат:
- Появилась возможность делиться ссылками на конкретную сущность.
- Пользователь может быстро найти нужную страницу и проверить ключевые настройки прямо в списке, не открывая каждую страницу.
Стало
Я реализовала Deep Linking — ссылка открывает дерево сразу на нужной глубине.Также добавила настраиваемые колонки в файловом менеджере, чтобы пользователи могли видеть ключевые параметры страниц и ориентироваться в структуре проекта без открытия каждой страницы.
Решение 4. Навигация и Deep Linking
Было
Ранее ссылка открывала только корень файловой системы, поэтому пользователям приходилось вручную искать нужную страницу в дереве. Дополнительно файловый менеджер показывал минимум информации о страницах, и для проверки настроек приходилось открывать их по очереди.
Модерируемое тестирование
Провели юзабилити тестирование на mvp с группой заинтересованных пользователей. Основная цель — понять, насколько интуитивно понятен новый интерфейс, доступны ли сценарии.
Нашли несколько точек роста:
- исправили сценарий копирования,
- добавили открытие редактора страницы по клику на её обложку в файловом менеджере,
- добавили тултипы при наведении на url страниц в разделе «Недавнее».
Остальные страницы и сценарии
Бизнес-эффект
Сокращение Time-to-Market для настройки SEO оптимизации сайтов, устранение Downtime страниц при публикации и устранение рисков безопастности
Моя роль
- Я была единственным дизайнером на проекте.
- Проводила глубинки сама и ставила задачи команде исследователей на основе полученной информации.
- Проектировала архитектуру ролей, файлов и SEO.
- Лидировала производство иллюстраций и коммуникационных материалов подрядчиками.
- Согласовала со стейхолдерами и Службой информационной безопастности новую схему ролей.
- Вместе с техлидом заложила дизайн-систему (Figma + Storybook).
Редизайн файловой системы Конструктора лендингов
Конструктор лендингов — внутренний инструмент Яндекса, в котором создаются страницы с 2,5 млрд визитов пользователей в год
Контекст и проблемы Конструктора Лендингов Яндекса
Конструктор лендингов Яндекса создавался как инструмент для быстрой проверки маркетинговых гипотез. Он позволял за несколько часов собрать страницу и запустить тест.
Со временем бизнес увидел потенциал low-code-подхода, и конструктор стали использовать для запуска полноценных сайтов. Изменился масштаб задач, но архитектура продукта осталась прежней.
Система не поддерживала требования к управлению доступами, безопасности и стабильной публикации. Часть сценариев приходилось реализовывать через обходные решения, крупные команды с жёсткими NDA не могли работать в платформе, а проекты, начатые на кастомной разработке, не возвращались. Перепубликация страниц могла приводить к временным потерям трафика.
Исследование
Переезд на новый стек стал возможностью пересобрать фундаментальные UX-проблемы, которые накапливались годами. Я инициировала исследование и сфокусировалась на двух ключевых ролях — менеджерах и исполнителях.
На основе результатов исследования мы сформировали пул гипотез, оценили их по RICE и отобрали наиболее перспективные.
Выводы
Глубинные интервью подтвердили ключевые гипотезы о проблемах пользователей.
Менеджеры сталкиваются с рисками при публикации (downtime и потеря SEO-трафика) и хотят контролировать изменения перед выходом в прод. Исполнители испытывают сложности с постановкой задач, доступами и тратят много времени на ручные SEO-настройки.
Исполнители испытывают сложности с постановкой задач, доступами и тратят много времени на ручные SEO-настройки.
Далее проверяли их через глубинные интервью и прототипирование, чтобы снизить риск ошибок до начала разработки.
Решение 1. Публикация без downtime
Было
Старая логика публикации работала по принципу «удалил страницу на проде, скопировал на её место страницу из песочницы». В момент обновления страница временно исчезала, что создавало риск потери трафика.
Стало
Я спроектировала новую логику бесшовной перезаписи: контент из песочницы накатывается поверх продовой версии без удаления страницы. URL сохраняется, публикация происходит без удаления.
Результат
- Downtime — 0 секунд.
- Риск потери трафика при обновлении контента устранён.
Результат
- Сократилось время запуска новых сайтов.
- Проекты получили возможность полноценно оптимизировать страницы для поиска без участия разработчиков.
Решение 2. SEO-инфраструктура и Time-to-Market
Было
Ранее SEO-задачи решались через костыли или ручную правку кода.
В системе не было сущности «сайт», поэтому настройками нельзя было централизованно управлять — их приходилось делать для каждой страницы отдельно или через разработку.
Стало
Я ввела новую сущность «сайт» и вынесла SEO-настройки на уровень сайта.
Добавила интерфейсы для управления robots.txt, sitemap и кастомными страницами 404, что позволило централизованно управлять SEO-инфраструктурой без привлечения разработчиков.
Решение 3. Гранулярные роли + прозрачность
Доступ к странице в песочнице
Информация о текущей роли
Результат:
- Выдача ролей до продовых проектов выросла, 28% новых ролей — точечные.
- Исполниетли понимают, как запросить роль и как поделиться страницей для ревью внутри команды.
Стало
Я пересобрала модель ролей на более гранулярную (доступ до проекта, папки или страницы), чтобы устранить «барьер страха» у менеджеров перед делегированием. Согласовала со службой безопастности механизм работы со страницами в песочнице чтобы упростить процесс внутреннего ревью через временные доступы. Добавила прозрачности: индикатор текущей роли прямо в интерфейсе Конструктора и связку с IdM, чтобы при запросе доступа данные о проекте пробрасывались автоматически.
Было
Фактические права не соответствовали названиям ролей и отсутствовала их индикация в интерфейсе, что заставляло пользователей интерпретировать ограничения системы как технические баги. Объем доступов для исполнителей был слишком широким поэтому менеджеры переносли
Результат:
- Появилась возможность делиться ссылками на конкретную сущность.
- Пользователь может быстро найти нужную страницу и проверить ключевые настройки прямо в списке, не открывая каждую страницу.
Стало
Я реализовала Deep Linking — ссылка открывает дерево сразу на нужной глубине.Также добавила настраиваемые колонки в файловом менеджере, чтобы пользователи могли видеть ключевые параметры страниц и ориентироваться в структуре проекта без открытия каждой страницы.
Решение 4. Навигация и Deep Linking
Было
Ранее ссылка открывала только корень файловой системы, поэтому пользователям приходилось вручную искать нужную страницу в дереве. Дополнительно файловый менеджер показывал минимум информации о страницах, и для проверки настроек приходилось открывать их по очереди.
Модерируемое тестирование
Провели юзабилити тестирование на mvp с группой заинтересованных пользователей. Основная цель — понять, насколько интуитивно понятен новый интерфейс, доступны ли сценарии.
Нашли несколько точек роста:
- исправили сценарий копирования,
- добавили открытие редактора страницы по клику на её обложку в файловом менеджере,
- добавили тултипы при наведении на url страниц в разделе «Недавнее».
Остальные страницы и сценарии