
Редизайн Ответы Mail
VK / Ответы Mail
VK | Ответы Mail
Ответы Mail — это портал, где пользователи ежедневно задают вопросы и получают ответы на любые темы. Помогает быстро делиться опытом, находить решения бытовых задач и общаться с сомневающимися или знающими пользователями.

Визуальное устаревание: Интерфейс не обновлялся визуально много лет, из-за чего выглядел громоздким и перегруженным. Высокий уровень «визуального шума» мешал фокусироваться на контенте и снижал привлекательность сервиса для новой аудитории. Пользователи отмечали отсутствие темной темы, сами пользователи решали этот вопрос через плагины браузера.
Техническое и продуктовое легаси: За годы развития проект оброс устаревшими пользовательскими сценариями и техническим долгом. Это замедляло внедрение новых функций, усложняло поддержку продуктовой системы и негативно влияло на скорость работы страниц.
Ограничения: Исторически сложивжийся партер портала в ограничений в количестве написания контента (поста или ответов) исходя из количества баллов.
Изменение вектора развития из-за развитых LLM: С поиском фактов и прямых ответов стали отлично справляться нейросети, поэтому продукт терял смысл как просто утилитарная справочная. Возникла необходимость сфокусироваться на пользовательском контенте — превратить платформу в живую социальную сеть, где люди ищут не просто сухую информацию, а эмоции, реальный личный опыт и общение с другими людьми.
Переосмыслить продукт и перевести его из устаревшего справочника ответов в современную социальную платформу с фокусом на живой контент, снизив визуальную нагрузку и избавившись от продуктового легаси.
Переосмыслил структуру карточки поста и блоков с ответами. Упростил считываемость контента, выстроил понятную иерархию комментариев и добавил наглядные функции реакций, голосов и быстрой оценки ответов.
Обновленную страницу тестировали через А/В, по результатом увидели сохранение сохранение метрик по СTR, adrev и глубины просмотра. Так же пользователи отметили свежесть визуала, но были и те, кому привычен старый дизайн.


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

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

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

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


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


Собрали первую итерацию библиотеки компонентов на основе Paradigm. Унифицировал базовые элементы постов, ответов, навигации, что позволило ускорить передачу макетов в разработку и не быть похожими на основные продукт группы VK.



21 мая 2025 года состоялся официальный перезапуск обновленного портала. На старте мы столкнулись со стандартными вызовами масштабирования — временным проседанием отдельных метрик и повышенной нагрузкой на модерацию. Эти процессы удалось оперативно стабилизировать совместно с технической и продуктовой командами.
На основе обратной связи от ядра пользователей мы выявили ключевую проблему UX в новой ленте: крупные развернутые посты занимали слишком много места, позволяя отображать всего 1–2 карточки на экране. Кроме того, акцент в хедере на «пространствах» (по аналогии с Reddit) усложнял идентификацию авторов, что было критично для сложившейся культуры сообщества.

Компактный режим ленты: Быстро спроектировал и внедрил компактнувид постов, что увеличило количество контента на одном экране и снизило негативный фон.
Переработка хедера: Вернул фокус на авторство постов, этип решением убралось обезличенность постов.
Оптимизация монетизации: За счет внедрения компактного вида удалось гармонично встроить дополнительные рекламные слоты без ущерба для пользовательского опыта.
VK | Ответы Mail
После перезапуска и смены вектора портала в сторону социальной сети возникла необходимость адаптировать продуктовые метрики под новую модель потребления контента и возвращению метрик к дорелизным значением.
Метрики показывали низкие значения по глубине просмотра и вовлеченности, видели что пользователи приходили за разовым ответом из поиска и после покидали портал.
На мобилке отсутствовали простые и нативные механизмы для подписки на авторов и интересные темы («Пространства»), из-за чего новый функционал по подпискам и пространствам было неактуальном или о нем не знали.
Вырастить ключевые метрики вовлеченности и глубины просмотра, сформировать у пользователей четкое понимание разделов и возможностей портала, а также помочь им легко собрать персональную ленту через подписки на авторов и тематические «Пространства».
Проблема: После релиза редизайна, на мобильных платформах заметили низкие переходы по основным разделам. В основном дальше поста и главной ленты пользователи не ходят.
Гипотеза: Вынос навигации основных разделов в мобильной версии вниз экрана увеличит кол-во переходов на пользователя, поскольку все основные разделы продукта будут в пределах 1-го тапа. Помимо этого, улучшит пользовательский опыт.
Целевые метрики:
Проанализировал общие паттерны популярных сервисов и порталов, использующие одно или две навигации (одно с ключевыми разделами, второе вспомогающее), выделил общие поведения, логику, которую мы можем переиспользовать.

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

Отразил макеты и описание со скроллом и подскроллом на верх страницы на основных разделах:

Подготовил макеты для разных размеров экрана и спецификацию по компоненту.

Детали эксперимента: использовался инструмент Omicron, длительность 14 дней, охват 100% аудитории.
Перевод навигации в доступную область экрана дал статистически значимый рост по ключевым продуктовым метрикам вовлечения:
Для нас тут главное, что кнопку “Создания поста” не потеряли и метрики по долям созданных постов не уменьшилось.
Эксперимент подтвердил гипотезу: физическая доступность навигации и ключевых действий кратно повысила вовлеченность аудитории и конверсию в создание контента. Таббар раскатан на 100% пользователей мобильной версии.
После завершения эксперимента метрики в MyTracker показали рост трафика и количества переходов в раздел «Пространства» по сравнению, когда он был скрыт в бургер-меню.
Проблема: После перезапуска у раздела «Пространств» низкое количество переходов и подписок. Нам важно подсветить пользователям, что у нас появились тематические разделы, где может быть смежные или интересные.
Гипотеза: Плашка «Пространства» на странице поста позволит легко переходить к схожему контенту и подписываться на темы, а кнопка «Вступить» станет дополнительной точкой конверсии для неавторизованных пользователей.
Целевые метрики:
Проанализировал паттерны на контентных платформах (Reddit, VC, Хабр). Главный паттерн – подсвечивать тематические сообщества в процессе скролла контента, не перегружая первый экран.
После анализа разных сервисов выделил пул задач, которые в макетах необходимо отразить и описать:


Подготовил макеты аналогичного поведения и логики плашки на странице поста.


После фиксации требований и спецификации подготовил макеты и передал фичу в разработку для проведения A/B-теста.

Детали эксперимента: использовался инструмент Omicron, длительность 7 дней, охват 20% аудитории.
Внедрение плашки дало значимый прирост по ключевым целевым действиям вовлечения в «Пространства»:
Эксперимент с внедрением плашки пространств доказала свою эффективность в привлечении внимания к тематическим разделам и росте подписок. Функционал раскатан на 100% пользователей.

Проблема: На портале высокий порог входа для формирования «своей ленты». Чтобы подписаться на интересного автора, пользователю нужно совершить лишнее действие — перейти в профиль (на мобилке), что прерывает процесс осознанности и мотивации подписаться, к тому же на новой странице появятся факторы отвлечения. Проблема затрагивает лояльных читателей, активных пользователей так и новых.
Гипотеза: Если рядом с ником автора добавить кнопку «Подписаться» с мгновенным действием, а после подписки предлагать переход к другим постам автора («Ещё от автора»), то это увеличит конверсию в подписки и переходы в профили. Пользователю проще совершить простое действие в моменте возникновения интереса.
Целевые метрики:
Проанализировал решения разных сервисов с похожей механикой (Дзен, VC, Medium, Telegram, YouTube). Главный паттерн рынка — кнопка подписки находится в зоне естественного внимания при чтении и не требует перехода на отдельный экран.
Ценность для продукта – рост аудитории главный стимул для авторов создавать качественный контент и регулярно возвращаться на платформу.
Эффективность разработки – задача требовала точечных UI-изменений без переработки бэкенд-логики, так как механизм подписок уже был реализован на платформе.
После анализа рынка и первых набросов требований выделил пул задач, которые в макетах необходимо отразить:
После фиксации требований подготовил макеты и передал фичу в разработку для проведения A/B-теста.

Детали эксперимента: использовался инструмент Omicron, длительность 7 дней, охват 50% аудитории.
Устранение лишнего шага и внедрение целевых действий в момент проявления интереса дали кратный рост показателей вовлечения:
Бесшовное действие в месте возникновения внимания снизило барьер входа, помогло пользователям быстрее сформировывать списк подписок и повысило интерес к авторам. Функционал раскатан на 100% пользователей.
VK | Ответы Mail

За полтора года активного развития Ответов накопился дизайн-долг: интерфейсы перегрузились, а многие компоненты отклонились от стандартных гайдлайнов Paradigm из-за особенностей продукта.
Чтобы ускорить работу над макетами и подготовить UI к бесшовному внедрению тёмной темы, потребовалось создать автономную локальную библиотеку и оптимизировать архитектуру UI-кита.
Задачи рефакторинга:
Перейти на атомарный подход структуры библиотеки;
Переработать базовые цвета и актуализировать токены под тёмную тему;
Унифицировать и актуализировать стили типографики;
Объединение решений VKUI и Paradigm с уникальными кастомными компонентами;
Провести аудит, очистку и структурировать накопившиеся иконки и компоненты со всех страниц сервиса;
Внедрить использование Figma Slots для сборки сложных конструкций.

Разделили систему на 4 изолированных файла библиотеки – Атомы, Иконки, Молекулы, Компоненты с четкой иерархией связей для снижения нагрузки на Figma и удобной параллельной работы.
Из файла «Атомы» подтягиваются фундаментальные стили: цветовые токены, типографика, переменные отступов и настройки теней.

В «Молекулах» собрали базовые интерактивные элементы: кнопки, аватарки, табы, ячейки, инпуты и формы для иконок, перенесенные и адаптированные из библиотеки Paradigma.

В «Компонентах» зафиксировали сложные сборные конструкции: посты, ответы, меню, навигацию, инфоплашки и нотификации.

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

Внедрил Figma Slots в компонеты с частой сменой контента (тело поста и ответа, поля ввода, меню, модальные окна, списки пользователей и пространств), чтобы кастомизировать наполнение без отвязки компонентов от родителя.

После релиза редизайна портала, тёмная тема стала самым запрашиваемым функционалом как со стороны пользователей, так и со стороны стейкхолдеров. Чтобы реализовать запрос без раздувания сроков разработки, совмесил внедрение темы с созданием новой библиотеки компонентов.
Сохранил исходную структуру и названия цветовых токенов, изменив только их значения для тёмной темы. Это позволило разработке включить поддержку темы без переподвязки компонентов в коде.
Переработал порядка 90 цветовых токенов, подобрав уникальные акцентные и фирменные оттенки. Это помогло задать выразительный визуальный стиль «Ответам» и отстроиться от базовой корпоративной палитры Paradigm и других продуктов компании (VK, VK Video, почта Mail).

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

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

Запуск тёмной темы вызвал мгновенный отклик у аудитории: в первый же день релиза её включили более 15 000 пользователей, что составило порядка ~1% DAU и подтвердило высокий спрос на ночной режим чтения.
Для разработки внедрение обновлённой токенизации и единой структуры позволило сократить трудозатраты на сборку макетов и новых сценариев в два раза — оценка задач снизилась с 2 Story Points до 1 SP. Полная синхронизация токенов между Figma и кодом минимизировала риск визуальных расхождений в интерфейсе и заложила гибкую архитектуру, позволяющую легко добавлять новые цветовые токены в будущем.
Переход на слотовую систему (Slots) существенно ускорил сборку продуктовых концептов за счёт гибкой подмены контента внутри сложных компонентов. Проработанная палитра токенов светлой и тёмной темы с единым неймингом упростил проверку экранов для дизайнеров и разработки.
Оптимизация базовых компонентов — сокращение количества избыточных вариантов и слоёв заметно снизила нагрузку на страницах Figma и ускорила загрузку тяжелых рабочих макетов. Для нашей команды из двух дизайнеров новая библиотека стала единым удобным фреймворком, который кардинально упростил ежедневное проектирование и повысил комфорт работы над новыми фичами.
Ozon
Изменить процесс управления продвижением товарами в инструменте «Продвижение в поиске»
Продвижение в поиске — инструмент, который помогает повысить позицию товара в поисковой выдачи. Товары из продвижения в поиске будут конкурировать за более высокие места в поиске.
С помощью дизайна упростить использование инструмента, сделать его масштабируемым и увеличить покрытие товаров ставками в инструменте.
Перед проработкой дизайна были проведены интервью на понимание текущей работы инструмента и как с ним взаимодействуют. В исследовани участвовали 6 компаний, основные пункты после исследования:
Так же была выгружена аналитика по количеству кампаний у продавцов, и выяснилось, что почти у 70% всего одна кампаний кампания продвижения в поиске. По этим данным были сделаны выводы, что вначале именно на эти 70% будем раскатывать новый дизайн инструмента, так как остальные продавцы группируют свои товары как раз через кампании. Далее для 30% нужно будет реализовать функционал группировки товаров.
Проанализировав текущий инструмент, а так же исследований и аналитике был подготовлен 1-й вариант концепта, он включал в себя такой функционал как:

С этим вариантом провели 3 интервью, и вот что получилось узнать:
После обратной связи бы проработан 2-й вариант концепта, где было проработано:


Этот вариант до интервью не дошел, но дошёл до оценки у разработчиков. На стадии MVP много чего из спроектированно вырезали, таблицу оч сильно сократили, не сможем сразу добавлять все товары продавца в продвижение, в графике сможем отразить только данные по продажам и расходу данного инструмента, рекомендаций соответственно тоже не умеем показывать на первой реализации. Так как не будет включение и выключение продвижения на конкретном товара, то сразу появилась гипотиза, что будет не удобно продавцам все время убирать товар из продвижения через удаление.
С разработкой и продуктами зафиксировали функционал, который будет в первой версии, договорились, что выкатывать функционал будем не сразу на всех, а частично: сначала дадим доступ для 10 лояльных продавцов, потом на 500 шт., дальше на 3000 и в конце на остальных 70%.
Для MPV я проработал:
Визуал графиков. Оставили только продажи и расход, а так же связующие с ними метрики.

Проработаны состояния переходов между новым и старым UI

Отразил и проработал состяния без товаров, флоу добавления товаров и ошибку, если что-то не добавилось

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

Так же обновил и упростил окно изменения ставки. Оно стало значительно занимать меньше места и чуть более информативной из-за сбитости контента.

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

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

Флоу отчетов. Есть 2 типа отчетов, они скачиваются асинхронно, поэтому для отчетов должна быть страницы со сформировавшимися отчетам их статусами и тп.


Весь проект строился на корпортативной библиотеке компонентов, а так же мною создавалась локальная библиотека элементов

Разработанный функционал выкатили на прод, сначала на 10 продавцов, потом на 500. Собрали обратную связь и аналитику для формирование бэклога и корректировки макетов для обновления функционала. Было проведено интервью на 5 респондентах.

Что хорошего:
Критичное: Отсутствие возможности включать/ выключать продвижение по SKU. Этого мы ожидали, этот функционал будет дорабатываться в следующую очередь.
Что неудобно:
Для следующей итерации согласовали сделать следующий функционал:
Вкл/выкл продвижение у товара и массово у товаров. В планах функционал сразу выкатить и дать доступ уже на 3 тысячи продавцов;
Доработать фильтры. Появляются сохраненные фильтры, добавляются новые метрики и свойства для фильтрации;
Проработать функционал избранных товаров. Это как раз для тех 30% продавцов, которым необходимо группировать товары
Проработать выбор дат/периодов для таблицы и графика. По аналитике сделали вывод, что чаще всего используют значения: вчера, 28 дней и 3/7 дней (идут +/- в ровень).

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

Ozon
Проектирование раздела “Продвижения” в мобильном приложении Seller App
Трафареты — инструмент для продвижение товаров продавцов в поиске, категориях, карточках товара, а также других страницах на специально выделенных местах. Настраивается автоматически через алгоритмы, оплата за показы или клики. Трафареты работают по модели аукциона. Кампании с бо́льшими ставками у товаров выиграют в аукционе за показы или клики. Кроме этого дополнительно учитываем качество проработки карточки товара и факторы, которые влияют на позицию в поиске.
Есть часть продавцов, которые заходят в раздел продвижение через мобильный браузер, посмотреть как работают кампании, изменить бюджет, вкл/выкл кампанию. Мобильный адаптив не идеальный, так же есть приложение Seller App, в котором нет раздела продвижение.
Так же есть более 70 тыс. потенциальных продавцов, которые пользуются мобильным приложением, но не используют инструменты продвижения своих товаров на Ozon. Аналитика показала, что продавцы, которые заходят на выходных в рекламных кабинет, по медиане тратят на рекламу больше, чем остальные.
Прорастить функционал продвижения товаров инструмента «Трафареты» в мобильное приложение SellerApp.
В начале, ко мне пришли с задачей, не было четко сформулированных требований, поэтому, по просьбе продукта, я спроектировал почти весь функционал, что есть на дестопе для мобильного приложения (далее Апка). В неё входило управление двумя инструментами Трафареты и Продвижение в поиске.





После, поняли что данное решение разрабатывать года, согласовали MVP версию, для неё решили делать урезанный функционал инструмента Трафареты с простым флоу: создать кампанию с автоматическим добавлением товаров по категории, просматривать метрики, менять дневной бюджет, вкл/выкл кампанию. После согласования требований передо мной стояли следующие задачи на MVP:
На основании уже сделаный экранов, я начал более детально прорабатывать экраны для разработки, описывать как работает почти каждый элемент, тап по элементу, валидации, ошибки данных, когда база отвалилась или же нет соединения с интернетом.
Проработал шаги создания кампании. В первом шаге часть полей предзаполняются автоматически, добавление товаров осуществляется по выбранной категории, так же добавлены фильтры бренда и цены. Категория довольно сложный элемент, для разработки его так же было необходимо тщательно описать и показать все возможные состояния.




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



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

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

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


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




Данный функционал был реализован в мае этого года и раскатан на всех продавцов. Собрали обратную связь от продавцов, основной поинт был в том, что нет подробных показателей о кампании, нельзя управлять ставками на товар и управлять самими товарами. Новички принесли кампании 16% от общей рекламной выручки мобильном приложении. Было заведено более 30к кампаний, более 20к кампаний приносят деньги кампании.
Следующим в разработку подготовил макеты по метрикам кампании за конкретный день или период.

Дальше в проработке функционал управлением товарами, просмотра метрик по товарам и редактирование ставок.

Ozon
Проектиование и развитие функионала кабинета Ozon ОРД
ord.ozon.ruOzon ОРД – это платформа для сбора и передачи информации о распространяемой в интернете рекламе в ЕРИР (единый реестр интернет-рекламы) с помощью маркера. Маркер – уникальный код, по которому отслеживается реклама в период кампании. В нём зашифрованы идентификаторы оператора рекламных данных и креатива.
Проект поддерживаю более года. Когда РНК заявил о новом законе о рекламе, наша компания решила создавать свой ОРД и я был подключен к проекту. Я спроектировал функционал MVP для получение аккредитации и лицензии, так же прорабатывал большие прототипы для демонстрации РНК и дальше уже для проведение исследований. А дальше уже дооснощали функционалом и поддерживали соответствие API ЕРИР-а.
Наш продукт всегда на связи с нашими клиентами, есть чатик в телеге с ними, переодически закидываем туда ссылку Pathway для быстрых исследований и квартально проводятся UX-интервью.
С увеличения объемов отчетов, для передачи данных в ЕРИР, стало неудобно в актах прописывать информацию о каждом креативе, их даты размещения, их показы, страницу актов во многих случаях можно скроллить бесконечно. О сложностях говорили нам пользователи на интервью и ещё писали в поддержку об этом. Так же ЕРИР начал оптимизировать свои данные и выкатил обновления API касаемо данных о креативах в актах.
Поддержать изменения API ЕРИР-а и обновить интерфейс Актов так, чтоб было удобно было управлять статистикой креативов.
Обновить и проработать страницу настройки заполнения актов;
Реализовать в Актах привязку статистики по креативам;
Проработать новый раздел “Статистика” и добавление записей о креативах.
После полугода, как кабинет был доступен пользователь, выяснили, что заполнение актов необходимо было доработать. Пользователи писали о длинной портянке, мы сами на это обратили внимание, что приходящее по API усложняло считывание из-за длинны страницы. В добавок ко всему, изменилась API ЕРИР-а (на их стороне тоже был запрос на изменение передачи и хранения данных). В акт необходимо было внести данные о самом акте между контрагентами, а так же данные по всем необходимым изначальным договорам. В текущем решении сложно и заполнять и управлять введёнными данными, хоть при открытии, допустим, для редактирования акта, там весь “аккардион” с записями закрыт. Ещё сложность в поиске определённого креатива, нет понимания отчитались о нем в акте или нет.


После анализа информации, проведения качественных исследований и проанализировав изменение API ЕРИР-а было принято решение сделать новый раздел “Статистика”, где будут заполняться итоговые данные о креативе после кампаний, и эта статистика по креативу будет привязана сначала к изначальному договору, а потом уже к акту. И это должно работать в обратную сторону, в разделе “Статистика” необходимо будет отражать привязку креативов к актам и договорам.
Как будет выстроен флоу: пользователь заводит статистику по креативу, заполняет данные по площадке, показам, периоду и стоимости, дальше, когда нужно отчитываться за период ЕРИР-у, заводят акт, где указывают изначальный договор и к этому изначальному договору привязывают статистику за определённый период.
Первым делом, было необходимо проработать таблицу и фильтры раздела. Если креатив прикрепили к акту и договору, то в таблице это так же указываем, отражаем ID, название и линк на них. Все что не влезает в ячейку при наведении отражаем в тултипе.

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

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

После выбора договора, необходимо заполнить Сумму и НДС, нельзя предзаполнять форму нулём и заполнять НДС, тк ноль – уже число и оно может быть в договоре. Все что касается финансов, лучше предоставить настройку пользователям, чтоб они были уверены в том, что заполняют. Дальше из-за технических ограничений необходимо добавить/сохранить акт, тк запрос в базу отправляться только после сохранения и дает дальше возможность привязать статистику по креативам. Здесь же отразил состояние ячеек в таблице.

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

После сохранения вся информация о договорах и статистике сохраняются в нашей базе, а затем отправляются в ЕРИР.
Функционал выкатили, собрали обратную связь, теперь пользователям гораздо проще следить за креативами, за которыми следует отчитаться ЕРИР-у или же уже отчитались. Была обратная связь от агентств, что в статистике не хватает колонок с датами создания/изменения, кто создал/изменил, тк в агентствах в одном кабинете могут сидеть несколько человек. Соответственно для таких столбцов нужно будут новые фильтры, а так же добавили функционал управления столбцами в таблице. Что собственно в следующим релизе и выкатили.

Devino Telecom
Продукт для обслуживания и продаж во всех современных каналах связи: чат на сайте, WhatsApp, Telegram, Apple Business Chat и другие. Обращения из всех каналов выстраиваются в единую очередь, могут распределяться в зависимости от бизнес-процессов компании и имеют единую систему аналитики
Первая версия приложения была собран быстро, что на стороне дизайна, что со стороны фронта. Когда начались работы по рефакторингу передо мной стояли задачи по исследованию и изменению интерфейса.
Провести исследования изменяемых разделов;
Переработать раздел «Команды» с внедрением нового функционала;
Разработать раздел «Профиль»;
Переработать статистику;
Переработать Онлан-чат на сайте;
Разработать параллельно мобильную версию разделов;
Улучшение дизайна пользовательского опыта.

По результатам исследований раздела «Команды» были выявленны несколько недочетов:
Левая колонка групп занимает много полезного места и вмещает в себя маленькое название; неочевидно, как редактировать группу; есть проблема с определением автоназначением групп, когда сотрудники первой группы уже закончили рабочий день;
Карточки сотрудников занимают много пространства и имеют минимальную информацию;
Контейнеры в который находится контент, занимают много полезного места.
Переработать группы, в которые входят агенты;
Переработать карточки агентов;
Расширить информацию о агенте и группах;
Внедрение новый фитч.

Пересобрал меню, сделал его меньше, оставлены только иконки. Исключительно администраторы могут видеть весь перечень меню, обычные агенты видят только раздел «Чаты» и «Агенты».
В процессе работы было принято решение перименовать раздел с «Команд» на «Агентов», а сами группы, в которые числились агенты из «Групп» в «Команды». Все блоки и карточки были переделаны, плюс добавлен новый правый блок «Информации», в которую вынесена информация и контролы изменения команда и самих агентов. Мной были отрисованы дефолтные аватарки для агентов в новом стиле.

«Команды» полностью переосмыслены, добавлены аватарки для лучшего распознавания (потому что много кто не читает текст), добавлено количество участников в команд, увеличено место для названия команд, был разработан функционал настройки времени работы команды, этот кейс решает проблему описанную выше.

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

Разработать сам раздел профиль с данными агента, тк данные редактируются в разделе «Агенты», что неудобно и не логично;
Разбить на подразделы;
Заложить функционал рабочего времени агента.

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

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

В мобильной версии было не лучшим решением объединять вместе информацию/пароль/выбор языка, поэтому было принято решение разбить на подразделы. Раздел уведомлений в мобильной версии я не рассматривал, так как это sdk и только в браузерах.
По результатам исследования я выделил несколько пунктов, которые необходимо сделать:

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

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

Для фильтра периода были частично изменены дефолтные значения. При проведении исследования я выявил, что данные значения использую чаще всего, для всего остального есть кастомные значения. Так же для статистики был разработан компонент range-calendar.

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

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

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

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

Для раздела разработана мобильная версия. К сожалению, я пока что не придумал, как сделать адаптив мониторинга агентов. Есть вариант реализовать раскрытие карточки агента и в нем будет график его активности. Но, возможно, решение будет неудобным, так как необходимо просматривать показатели агента поочередно и всей картины администраторам будет сложно увидеть, надо тестировать. И было принято решение с бизнесом, что данный функционал не внедрять в мобильную версию.

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

Я разработал новую для приложения механику по выбора канала для обращения. Изменил внешний вид онлайн-чата, как шапку, так и тело. Внедрил блок сбора информации о клиенте. Сделал технические сообщения, например о том, что к диалогу присоединился оператор или наоборот вышел из него.
Разработал дефолтные аватарки для агентов, которые будут видеть клиенты, так же для бота был сделан индивидуальный аватар, чтоб пользователь визуально понимал с кем идет переписка (но это будет работать только для онлайн чата, так как для остальных каналов компании задают единую аватарку в виде логотипа компании).
Для пользователя приятно понимать, когда ему набирают сообщение и его заявкой кто-то занимается, поэтому был внедрен функционал отображения набора тескта оператором. Аналогично работает и в обратную сторону, агенты видят, когда клиенты пишут сообщения.
Еще отдельный функционал это выключения звука самого виджета, поступали запросы что такой функционал необходим, оказывается некоторых пользователей нервируют сервисные звуковое оповещение на сайте.

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

Хороший плюс данной разработке онлайн-чата является, что она легко внедряется в мобильный адаптив и не обязательно, чтоб фронты специализировались по мобильной разработке (например чтоб вызвать системный функционал с выбором того или иного элемента). И сам онлайн-чат адаптивный, он подстаивается под высоту экрана пользователей. Если высота экрана меньше 704 px (дефолтная высота онлайн-чата), то при открытии от автоматически подсчитывает высоту, которую может занять.
Devino Telecom
Онлайн сервис мультиканальных коммуникаций. Распространяет персонифицированные сообщения информационного или рекламного характера от имени компании с помощью таких каналов как: SMS, Viber, WhatsApp и других.
Devino.Online был разработан из-за не масштабируемости старой платформы, а новые продукты и услуги компании внедрять необходимо. Моей задачей в проекте было поддержание и развитие личного кабинета, чтобы приложение работало по подходу self-service, без привлечения сотрудников компании.
Передо мной стояли задачи по развитию Адресной книги, развитие процесса проведения рассылок, внедрение новых услуг и улучшение пользовательского опыта.
Маштабировать адресную книгу по тендециям рынка;
Разработка нового шаблона создания рассылок на примере канала SMS;
Разработать и внедрить функционал по новым продуктам компании, таких как А/В-тестирования и конструктор сегментартора;
Проведение исследований по внедряемому дизайну и функционалу.

В процессе работы и исследований адресной книгой были выявлены несколько проблем:
простой функционал для залития базы и отправки рассылки, а сейчас для рынка необходима платформа для управлению своей базой;
для рынка важен функционал стоп-листов и отписавшейся базы, а данном функционале их нет;
в листе базы не удобно расположены контролы, особенно кнопка «Назад» в правой стороне;
Сегменты занимают много места, а если их в листе 10 шт. и более то они занимают большую часть экрана.
переработать страницу с листами и обогатить функционалом соответствующей тенденции рынка;
изменить страницу с листом подписчиков, разделить сегменты и список подписчиков.


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

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

По такому же функционалу можно добавлять подписчиков в уже существующий лист.

Проведя исследования я понял, что для наших клиентов сложен путь создания SMS рассылки, он кажется длинным и нелогичным. Перемещении по настройкам через хлебные крошки пользователям было не удобным. При опросе с коллегами выяснили, что пользователи предпочитают создавать именно SMS рассылка на одной странице, чтоб они видели все свои настройки.
Переосмыслить логику создания SMS рассылки;
Оснастить функционал иллюзией, что все настройки происходят на одной странице (тестировали, когда все настройки действительно на одной странице и она стала сильно перегружена и пользователи немного терялись);
Добавить визуал, в котором пользователи видят как из сообщение выглядит на телефоне с их настройками и макросами;
Изменить сводный лист для более лучшего считывание информации.

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

В третьей итерации я изменил визуал степов с горизонтального на вертикальный и получилась иллюзия, что пользователь находится на одной странице,а изменяются только настройки согласно названию степа. Данным функционалом были выполнены наши цели для создания нового шаблона для рассылки.
А/В тест - тип массовой и триггерной рассылки, позволяющий сравнить 2 или более варианта сообщения/письма на определенной части базы подписчиков, выбрать лучший вариант, и, при необходимости, отправить его по оставшейся части базы подписчикам, не задействованной в тестовых группах.
Функционал должен быть доступен для следующих каналов: SMS, Viber, Email, Push.
Зачем компании необходим данный функционал?
Участвовать в тендерах (A/B тесты требуют в многих email тендерах);
Дороже продавать email и другие каналы;
Конкурентное преимущество (способ привлечения новых клиентов за счет лучшего функционала, чем у конкурентов. Часто клиенты пользуются сторонними сервисами для лучшего подсчета данных или же разбития своей базы).
Какой функционал есть на данный момент:
Базовый функционал A/B тестов для массовых email рассылок. В текущем варианте, А/В тесты нельзя использовать для триггерных рассылок и других каналов, кроме email. Более того функционал имеет серьезные недостатки. Например: отсутствует отправка в ручную, отправка по всей базе, выбор времени рассылки и тд. и множество моментов для улучшения (напр: автоматический расчет тестовых групп, статистика и тд).
Пересмотреть функционал A/B тестов, определить что важно для клиентов, чего не хватает, а также посмотреть лучшие практики и решения на рынке.
Продумать процесс функционала A/B тестов для массовых и триггерных рассылок на примере Email канала.
Сделать статистический калькулятор для автоматического расчета тестовых групп.
Реализовать функционал и провести исследовани.
Для А/В теста необходимо была разработать функционал по настройке тестовых групп, настройку выбора элемента рассылки, функционал по работе с несколькими шаблонами email-писем, настройку выбора даты и времени отправки (так как было лучшем решением для канала сделать настройку времени последним шагом), а так же разработать статистику с возможностью выбора лучшего варианта или же завершением рассылки.

В процессе разработки было выполнено несколько итерации, в макетах это отражено. После каждой проводились юзабилити исследования в виде интервью с нашими действующими клиентами, у которых должностные обязанности связанны с проведением массовых или триггерных рассылок.
С помощью интервью было видно, что пользователи часто не видели ту или иную настройку, например «Количество тестовых групп». Была выдвинута гипотеза, что настройка просто стоит не в том блоке, поэтому ее не видят. Многие пользователи не понимали «калькулятор групп», так как не было никаких подсказок по этому поводу и базы знаний. Так же 4 из 5 опрашиваемых в первой итерации говорили, что нет UTM-меток для каждого тестируемого варианта письма, они обращают внимание на данные UTM по проведению рассылок.
После сбора данных от исследований была проведена вторая итерация проектирования. Были внесены изменения в порядок элементов в блоках, был добавлен шаг с настройкой отправки рассылки, немного изменен калькулятор групп и расширен функционал работой с шаблонами (в прошлой итерации был нелогично проработан копирования шаблона в другой шаблон).

При исследовании все так же респондентам не было понятен функционал по калькулятору групп, ведь он просто отражает значения при выставлении необходимых параметрах и не было функционала как-то применить настройки выборки. Так же настройка лучшего варианта все равно настраивается в двух места, была выдвинута гипотеза, что лучше отразить данную настройку только в одном месте, а на данном шаге дать пользователю только выбор отправлять лучший вариант или нет.
Во время исследований было выяснено, что чаще всего клиенты отправляют равные тестовые группы, а произвольный размер групп редкий кейс для них. И ведь будет очевидно по данным, если одну группу сделать намного меньше, то польза от теста сводится к нулю.
С новыми данными было проведена работа по третьей итерации разработки.
Тип А/В теста был перемещен на следующий шаг, ведь все необходимые настройки и изменения происходят там. Была проведена работа по изменению настройки тестовых групп и самого калькулятора групп. А настройка лучшего варианта была вынесена в последний шаг создания рассылки.

Было принято решение оставить в функционале настройки тестовых групп только равное количество пользователей и изменять можно только размер группы «Вне выборки». Так же была добавлена табличка с данными о размерах групп, где изменяется так же только «Вне выборки».
Калькулятор был вынесен отдельным блоком, заполнение которого и применение будет влиять на тестовые группы.

Так же большая работа была проведена по статистике рассылки с А/В тестом, которая изменяется от момента создания до рассылки выбранного лучшего варианта. Были проработаны элементы в графике и таблице с максимально понятными для пользователей значениями, статусами , лейблами.
Каждая итерация была проработана основная идея, которая была реализована и протестирована на реальных пользователях.
Сегментатор - инструмент для разделения клиентской базы на группы по определенным признакам.
Функционал должен быть доступен для рассылкок SMS, Viber, Email и для адресной книги.
Зачем компании необходим данный функционал?
Правильная сегментация может значительно увеличить конверсии, продажи, лояльность и другие показатели клиентов. Удобный сегментатор в визарде рассылки и в адресной книге создаст дополнительную ценность продукта и конкурентное преимущество.
Какой функционал есть на данный момент:
Базовый функционал сегментатора находится в адресной книге в виде попап конструктора. Его минусы заключается в том, что сложно считывать условия о пользователях, сложная механика с логикой операторов «И», «Или», «Исключить» и вложенными блоками. Так же к первому созданному блоку из цепочки, невозможно добавить вложенный блок. Так же цепочка сегментатора на странице занимает очень много места.

Такая цепочка сейчас существует в виде попапа в адресной книге.
Изменить страницу «Получатели» в визарде создания рассылок.
Создать простой и читабельный конструктор сегментатора, чтобы условия мог считать и переиспользовать любой пользователь.
Разработать настройку создания или редактирования условий.
Провести исследования.
Перед разработкой были проведены исследовани, за респондентов были взяты менеджеры компании. По существующей реализации им было сложно считывать условия сегментирования и не понятны логические операторы.

Далее мной был разработан конструктор со скрытием тонких настроек условия, чтоб было проще считывать. В таком виде моя гипотеза не сработала, хоть и считывать все равно проще. Респонденты часто не в том порядке считывали условия и некоторые символы, например, вложенных блоков, не замечали.
В исследовании я попросил закрасить круги по диаграмме Венна, которая отвечает по параметрам логических операторов (И ИЛИ ИСКЛЮЧИТЬ). И пришел к выводу, что И с ИЛИ вызывают затруднение, и я решил упростить функционал.
Между блоками может использоваться только оператор ИЛИ, а И может использоваться только в самом блоке не показывая это, просто будет перечисление условий.
Логический оператор ИСКЛЮЧИТЬ будет использоваться как в самом блоке, просто исключать условия локально, а так же может использоваться как глобальное исключение из всех блоков разом. И такой блок может быть в конструкторе только один.

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