Продуктовый UX/UI-дизайнер | B2B SaaS | Сложные интерфейсы

---

• Email: nemokor@gmail.com
• Телефон: +7 950 787 10 56
• Telegram: @ruugh

  ---

  Опыт

  ISS Art — B2B SaaS для международных клиентов

  Product Designer | Сентябрь 2023 — Сентябрь 2025 (2 года)

  RIG — платформа для ремонта грузовиков (модель Uber)

  iOS + Android | Водители, механики, диспетчеры | Единственный дизайнер

  • Спроектировал мобильные приложения для водителей и механиков с нуля
  • Водитель создаёт заявку за пару минут: фото поломки, геолокация, описание
  • Механик видит ленту заказов рядом, отправляет оффер с ценой и временем
  • Сделал подсказки средних цен — механики перестали бояться "промахнуться"
  • Время от заявки до принятия механиком сократилось на 30–40%
  • 70–80% заказов теперь закрываются с фото и чек-листом (раньше всё на словах)
  • Провёл интервью с водителями, механиками и владельцами автопарков
  • Собрал дизайн-систему для iOS/Android с общей логикой

  Omskinform CMS — система для новостной редакции

  Web + Mobile | 20 пользователей, 5 ролей | Единственный дизайнер

  • Упростил процесс публикации — было 14 минут, стало 7
  • Добавил статусы и очереди задач — критические ошибки упали на 67%
  • Сделал медиабиблиотеку с автокропом — ошибки в баннерах −45%
  • Новые сотрудники раньше входили 2 недели, теперь 3 дня
  • Собрал UI Kit на 50+ компонентов (Ant Design) — фронтенд стал верстать в 2 раза быстрее
  • Настроил процесс с разработкой: дизайн-ревью, Token Studio, Storybook
  • Провёл 12 интервью с редакторами, наблюдал за их работой

  Poker Manager — CRM для покерных клубов (США)

  Web | 10+ клубов, 5000+ игроков | Единственный дизайнер

  • Раньше анонс турнира занимал 25 минут, теперь 10
  • Сделал теги для игроков — охват рассылок вырос с 30% до 70%
  • Собрал модуль рассылок с шаблонами — ошибки доставки упали с 1.8% до 0.4%
  • Сделал дашборды: владельцы видят выручку, активность, отток
  • Провёл 8 интервью с владельцами клубов, изучил их Excel-таблицы
  • Результат: Retention M+1 вырос на 12 п.п.

  Помимо проектов:

  • Внедрил практику дизайн-ревью на проектах
  • Менторил джуниор- и мидл-дизайнеров
  • Выступал на внутренних митапах по дизайн-процессам

  ---

  Eventagrate (ОАЭ) — виртуальные мероприятия

  Product Designer | Февраль 2022 — Сентябрь 2023 (1 год 8 мес)

  MetaKit — конструктор 3D-ивентов

  Админка + Web-клиент | до 500 человек на событии | Единственный дизайнер

  • Разбил платформу на модули — клиенты собирают ивент как конструктор
  • Подготовка события раньше занимала 14 дней, стало 4
  • Сделал проверку контента перед запуском — 90% технических проблем ушло
  • Операторы получили панель управления: камеры, чат, права участников
  • 80% клиентов настраивают ивенты сами, без нашей помощи
  • Запустили 15+ платных мероприятий, оценка клиентов 4.8/5

  Помимо проектов:

  • Менторил джуниор-дизайнера

  ---

  Мос Диджитал — веб-студия

  Senior UX/UI Designer | Октябрь 2020 — Февраль 2022 (1 год 5 мес)

  • Менторил 3 джуниоров: ставил цели по карте компетенций, проводил ревью, помогал расти
  • Наладил работу с фронтендом — меньше правок после вёрстки

  Проекты:

  • Система для профсоюзов (500+ сотрудников) — перевёл заявки и выплаты из Excel в нормальный интерфейс
  • Сервис доставки еды — от поиска до заказа, запустили с 20 ресторанами, 30% заказывали повторно

  ---

  Veonix — веб-студия

  UX/UI Designer | Июнь 2017 — Апрель 2019 (2 года)

  Сайты, личные кабинеты, интернет-магазины. 15+ проектов.

  ---

  Навыки

  Инструменты: Figma (Variables, Auto Layout), Token Studio, Storybook, Miro, Amplitude, Notion, HTML/CSS, Webflow

  AI в работе: ChatGPT/Claude для research и копирайтинга, эксперименты с LLM для валидации дизайн-систем

  Что умею: собирать дизайн-системы, проводить интервью и юзабилити-тесты, рисовать user flow и CJM, работать по JTBD

  ---

  Образование

  Омский государственный технический университет

  Дизайн

  Яндекс Практикум | 2025

  UX-исследования

  ---

  Языки

  Русский — родной | Английский — B1

  ---

  

  Eventagrate — студия иммерсивных технологий из Дубая. 65 человек, 500+ проектов в 30+ странах. Делают виртуальные ивенты для корпоратов в GCC.

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

  ---

  Моя роль

  Product Designer (end-to-end): - Discovery и синтез инсайтов (5 интервью) - IA под 5 ролей - UI ключевых флоу подготовки и live-модерации - Design system и компоненты - Тестирование итераций, контроль качества

  ---

  Проблема

  Eventagrate — агентство виртуальных мероприятий.

  Каждый проект = “новый продукт с нуля”.

  Бизнес: Нельзя обещать сроки, теряли сделки. Нельзя вести параллельно, упирались в потолок.

  Пользователи: "Хотим настраивать сами, без 20 созвонов". А ещё — страх live. Когда 2000 человек онлайн и что-то идёт не так, это публичный провал.

  Решение

  Модульная архитектура

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

  Модули: Roles & Permissions → Content → Moderation → Analytics

  Главное решение: роли вместо "универсальной админки"

  

  Универсальный интерфейс — это когда всем неудобно одинаково.

  Я разделил систему на 5 ролей. Каждая видит только то, что нужно для её работы. Organizer — конфигурация события, go-live Client Admin — управление со стороны клиента Content Manager — наполнение и управление стендами Moderator — чат/Q&A, инциденты Tech Admin — интеграции, системные настройки

  ---

  Основной флоу: подготовка события

  Раньше: 20+ созвонов → правки через разработчиков → непредсказуемые сроки

  

  Теперь: организатор собирает как конструктор:

  

  Ключевые экраны

  Dashboard — операционный центр

  Не аналитика для отчётов. Это экран для ответа на один вопрос: "всё ок или горит?"

  

  Chat Management — live-модерация

  Live-модерация это стресс. Любое действие — бан, скрытие, отключение комнаты — может быть ошибкой.

  

  

  Ключевое решение: safe actions.

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

  Q&A Moderation — очередь вопросов

  

  Q&A Moderation

  Приоритизация по upvotes, статус “in progress”, быстрые шаблоны ответов.

  Content Manager — self-service наполнение

  Клиенты хотели менять контент сами. Но боялись сломать что-то в live.

  

  Готовишь изменения → смотришь как будет выглядеть → публикуешь когда уверен. Откат в один клик.

  ---

  Design System

  Много экранов, 5 ролей — без системы всё расползётся за месяц.

  

  

  

  Design System

  Dark theme с "заглублением" — карточки темнее фона. Меньше контраста = меньше усталости в долгих сессиях мониторинга.

  Цвета:

  • Зелёный (#37CA8C) — primary actions, online/live статусы
  • Красный — только деструктивные действия, никогда для акцента
  • Нейтральные — всё остальное

  Компоненты: buttons (filled/outline/ghost), inputs (S/M/L), tabs с счётчиками, badges, tables.

  ---

  Результаты

  

  Как считали

  • Время подготовки — от старта до go-live (по таймлайнам проектов)
  • Self-service — доля задач без dev/саппорта
  • CSAT — пост-ивент опрос

  Business impact: - Быстрее закрывали сделки — могли обещать сроки - Меньше инцидентов и кранчей перед запуском - Выросла параллельность без роста dev-нагрузки

  ---

  Что понял

  Role-based > Universal. Инвестиция в разные интерфейсы окупилась. Люди перестали путаться, support tickets упали.

  Safe actions работают. Toggle + confirm для деструктивных действий — это не "недоверие к пользователю", это защита от стресса.

  DS экономит недели. В проекте с 5 ролями и десятками экранов без системы — хаос.

  ---

---

Ключевые навыки

• Что умею: собирать дизайн-системы, проводить интервью и юзабилити-тесты, рисовать user flow и CJM, работать по JTBD
• Дизайн: UI-киты, прототипы, анимация (Lotty,rive)
• Figma: компоненты, Auto Layout, Variables, Token Studio, интеграция со Storybook
• AI в работе: ChatGPT/Claude для research и копирайтинга, эксперименты с LLM для валидации дизайн-систем
• Софт-скилы: веду воркшопы, презентую решения
• Инструменты: Figma (Variables, Auto Layout), Token Studio, Storybook, Miro, Amplitude, Notion, HTML/CSS, Webflow

---

Портфолио

Mobile app (iOS/Android) + Web

О проекте:

Международный заказчик из логистики пришёл с задачей: собрать Uber-like платформу для ремонта грузовиков. В отрасли одни и те же боли:

• водители не могут быстро найти механика в дороге, простаивают;
• частные механики и сервисы страдают от «дырявого» потока заказов;
• диспетчеры тонут в звонках, Excel и ручном учёте заявок и денег.

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

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

Моя роль:

Как Product Designer я отвечал за мобильные части платформы:

• Исследование домена: интервью с представителями автопарков, механиков и водителей, разбор текущих процессов.
• Проектирование user flow и интерфейсов мобильных приложений для водителей и механиков.
• Создание и поддержка дизайн-системы для мобильных и веб-клиентов.
• Подготовка интерактивных прототипов, проведение юзабилити-сессий.
• Описание сценариев, состояний и краевых кейсов в спецификациях для разработки.
• Совместная работа с backend / mobile / web-командой над API и состояниями.

Процесс:

• CJM и IA, согласовали с продуктом и техлидами;
• низкоуровневые прототипы → UX-валидация на стороне заказчика;
• финальный UI, состояния ошибок, крайние кейсы;
• спецификации для разработчиков (описание статусов, событий, переходов);
• участие в ревью, проверка соответствия флоу и UI.

Команда:

Продакт, проджект менеджер, системный аналитик, frontend разработчик , backend разработчик.

Аналитика

Интервью с представителями автопарков, механиков и водителей; фиксация сценариев и болей.

Гипотезы

H1.

Если дать механику экран «Request» с активными заказами и лентой новых заявок, то он быстрее ориентируется в дне и чаще выходит «в сеть» через приложение.

H2.

Если в карточке заявки показать достаточно информации (тип проблемы, фото, данные ТС, расстояние, примерное время в пути), то доля взятых в работу заявок вырастет, а время на принятие решения сократится.

H3.

Если упростить создание предложения до экрана «цена + ETA + комментарий» и добавить подсказки средних цен, то механики будут чаще отправлять офферы и меньше бояться «промахнуться» по стоимости.

H4.

Если сделать удобный блок фиксации результата (чек-лист, фото, материалы) + прозрачный статус выплат, то уменьшится количество спорных ситуаций и вопросов по оплате.

JTBD

CJM опыт Механика

UX-флоу и структура

Собрали карту экранов и потоков:

• Водитель: регистрация по номеру → выбор услуги → данные о ТС → описание проблемы (текст/фото/аудио) → ожидание предложений → выбор механика → трекинг → подтверждение и оценка.
• Механик: регистрация → настройка профиля и зоны работы → лента заявок → отправка предложений → чек-лист этапов ремонта → фиксация материалов и завершение.

flowchart TD
    Start([Запуск приложения]) --> Auth{Авторизован?}
    
    Auth -->|Нет| Onboard1[Экран приветствия]
    Onboard1 --> Onboard2[Регистрация]
    Onboard2 --> Onboard3[Ввод данных]
    Onboard3 --> Onboard4[Верификация]
    Onboard4 --> Onboard5[Подтверждение кода]
    Onboard5 --> Onboard6[Выбор зоны работы]
    Onboard6 --> Onboard7[Специализация]
    Onboard7 --> Onboard8[Загрузка документов]
    Onboard8 --> Home
    
    Auth -->|Да| Home[HOME / СЕГОДНЯ]
    
    Home --> HomeStatus{Статус}
    HomeStatus -->|Офлайн| SetOnline[Переключить в сеть]
    SetOnline --> Home
    HomeStatus -->|Онлайн| ShowHome[Главный экран]
    
    ShowHome --> Action1{Действие}
    
    Action1 -->|Лента| Feed[ЛЕНТА ЗАЯВОК]
    Feed --> FeedList[Список заявок]
    FeedList --> SelectRequest[Выбрать заявку]
    SelectRequest --> RequestCard[КАРТОЧКА ЗАЯВКИ]
    
    RequestCard --> CardDetails[Просмотр деталей]
    CardDetails --> Decision1{Решение}
    
    Decision1 -->|Отклонить| Feed
    Decision1 -->|Откликнуться| CreateOffer[СОЗДАНИЕ ПРЕДЛОЖЕНИЯ]
    
    CreateOffer --> OfferForm[Заполнить форму]
    OfferForm --> SendOffer[Отправить предложение]
    SendOffer --> WaitResponse[Ожидание ответа]
    
    WaitResponse --> Response{Ответ}
    Response -->|Отклонено| Feed
    Response -->|Принято| ActiveOrder[АКТИВНЫЙ ЗАКАЗ]
    
    Action1 -->|Заказ| ActiveOrder
    
    ActiveOrder --> OrderScreen[Экран заказа]
    OrderScreen --> OrderStatus[Статусы заказа]
    
    OrderStatus --> OrderFeatures{Функции}
    
    OrderFeatures -->|Чат| Chat[Чат с водителем]
    Chat --> OrderScreen
    
    OrderFeatures -->|Навигация| Route[Маршрут к клиенту]
    Route --> OrderScreen
    
    OrderFeatures -->|Статус| UpdateStatus[Изменить статус]
    UpdateStatus --> StatusCheck{Статус}
    StatusCheck -->|В пути| OrderScreen
    StatusCheck -->|На месте| OrderScreen
    StatusCheck -->|В работе| WorkProcess[Процесс работы]
    WorkProcess --> OrderScreen
    StatusCheck -->|Завершён| Complete[Завершение]
    
    Complete --> FinalPrice[Итоговая сумма]
    FinalPrice --> Payment[Ожидание оплаты]
    Payment --> Rating[Получение оценки]
    Rating --> Home
    
    Action1 -->|Финансы| Finance[ФИНАНСЫ]
    Finance --> FinanceScreen[Финансовый экран]
    FinanceScreen --> Home
    
    Action1 -->|Профиль| Profile[ПРОФИЛЬ]
    Profile --> ProfileScreen[Экран профиля]
    ProfileScreen --> ProfileSections{Разделы}
    
    ProfileSections -->|Специализация| Specialization[Редактировать специализацию]
    Specialization --> ProfileScreen
    
    ProfileSections -->|Документы| Documents[Управление документами]
    Documents --> ProfileScreen
    
    ProfileSections -->|Рейтинг| RatingView[Просмотр рейтинга]
    RatingView --> ProfileScreen
    
    ProfileSections -->|Зона| WorkZone[Изменить зону работы]
    WorkZone --> ProfileScreen
    
    ProfileSections -->|Настройки| Settings[Настройки приложения]
    Settings --> ProfileScreen
    
    ProfileScreen --> Home
    
  

    

Особое внимание — минимум шагов на мобиле и чёткая обратная связь: прогресс-бар мастера, статусы «ищем механика», «механик в пути», «ремонт идёт», «ожидаем подтверждение».

Дизайн система

Базировался на мобильных гайдлайнах iOS/Android: понятные таб-бары, крупные CTA, работа с картой и листами снизу.

• Собрал дизайн-систему:
  • цветовые токены (состояния: «требует внимания», «в работе», «завершено»);
  • типографика, сетка, отступы;
  • компоненты: карточки заявок, мастера шагов, блоки с картой, статусы, формы, модалки.
• Для веб-части использовал похожий подход, чтобы водитель/механик не «терялись» между платформами.

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

В Figma собрал интерактивные прототипы обоих приложений (iOS/Android, но с общей логикой).

https://www.figma.com/proto/wFfLQZwHKZsbNLf51rLtJc/RIG--demo-?page-id=17232%3A247428&node-id=17102-235379&viewport=-271%2C-241%2C0.27&t=FIQhYVVqh0voQeIM-1&scaling=min-zoom&content-scaling=fixed&starting-point-node-id=17102%3A235379&show-proto-sidebar=1

Прогнал сценарии с 5–7 респондентами (водители и механики из базы клиента:

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

Ключевые UX / UI-решения

Опыт Механика

Экран «Request» — точка входа в смену

Создание предложения (оффера)

Экран активного заказа: статусы и навигация

Фиксация результата и отчётность

Результаты

Среднее время от появления заявки до принятия механиком сократилось (по данным пилота) примерно на 30–40 %.

Доля заявок, закрытых с фото и заполненным чек-листом, выросла до 70–80 %.

Механики стали чаще использовать приложение как основную точку входа, а не только телефон/мессенджеры.

Уменьшилось количество спорных ситуаций по оплате и объёму работ — за счёт прозрачной фиксации и статусов.

---

Моя роль

Product Designer (end-to-end): - Discovery и синтез инсайтов (5 интервью) - IA под 5 ролей - UI ключевых флоу подготовки и live-модерации - Design system и компоненты - Тестирование итераций, контроль качества

---

---

Основной флоу: подготовка события

Раньше: 20+ созвонов → правки через разработчиков → непредсказуемые сроки

Теперь: организатор собирает как конструктор:

Ключевые экраны

Dashboard — операционный центр

Не аналитика для отчётов. Это экран для ответа на один вопрос: "всё ок или горит?"

Chat Management — live-модерация

Live-модерация это стресс. Любое действие — бан, скрытие, отключение комнаты — может быть ошибкой.

Ключевое решение: safe actions.

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

Q&A Moderation — очередь вопросов

Q&A Moderation

Приоритизация по upvotes, статус “in progress”, быстрые шаблоны ответов.

Content Manager — self-service наполнение

Клиенты хотели менять контент сами. Но боялись сломать что-то в live.

Готовишь изменения → смотришь как будет выглядеть → публикуешь когда уверен. Откат в один клик.

---

Design System

Много экранов, 5 ролей — без системы всё расползётся за месяц.

Design System

Dark theme с "заглублением" — карточки темнее фона. Меньше контраста = меньше усталости в долгих сессиях мониторинга.

Цвета:

• Зелёный (#37CA8C) — primary actions, online/live статусы
• Красный — только деструктивные действия, никогда для акцента
• Нейтральные — всё остальное

Компоненты: buttons (filled/outline/ghost), inputs (S/M/L), tabs с счётчиками, badges, tables.

---

Результаты

Как считали

• Время подготовки — от старта до go-live (по таймлайнам проектов)
• Self-service — доля задач без dev/саппорта
• CSAT — пост-ивент опрос

Business impact: - Быстрее закрывали сделки — могли обещать сроки - Меньше инцидентов и кранчей перед запуском - Выросла параллельность без роста dev-нагрузки

---

Что понял

Role-based > Universal. Инвестиция в разные интерфейсы окупилась. Люди перестали путаться, support tickets упали.

Safe actions работают. Toggle + confirm для деструктивных действий — это не "недоверие к пользователю", это защита от стресса.

DS экономит недели. В проекте с 5 ролями и десятками экранов без системы — хаос.

---

Клиент: Омскинформ

Роль: Product Designer

Период: 2025

Команда: 1 дизайнер, 3 разработчика, редакция из 8 человек

Ключевые результаты:

• Время публикации: 14 мин → 7 мин (-50%)
• Удовлетворенность: 3.2/5 → 4.6/5 (+44%)
• Автомодерация: 0% → 90% комментариев
• ROI: Окупаемость ~2 года, экономия ₽173k/месяц

Моя роль

Product Designer

Я отвечал за полный цикл UX/UI:

• Провёл 8 глубинных интервью (~8 часов записей)
• Спроектировал flows, информационную архитектуру, прототипы, UI
• Провёл 3 раунда юзабилити-тестирования с 5 респондентами
• Описал edge cases, валидации, состояния ошибок
• Сопровождал разработку через design-review, контроль качества

---

Контекст проекта и проблема

К 2025 году Омскинформ стал одним из крупнейших региональных новостных порталов с аудиторией в сотни тысяч читателей. Однако за внешним успехом скрывалась серьезная проблема — устаревшая CMS делала работу редакции всё менее эффективной.

Скриншот старой CMS

Ключевые проблемы

Для журналистов

• Публикация срочной новости занимала до 15 минут
• Необходимость переходить между 4 разными разделами интерфейса
• Текстовый редактор не подходил для полноформатной работы
• Отсутствие автосохранения — страх «сломать сайт»

Для редакторов

• Путаница с ролями и правами доступа
• Сложная логика размещения баннеров (знал только 1 человек)
• Постоянные ошибки в рекламных материалах

Для модераторов

• Ручная фильтрация всех комментариев
• Работа в нерабочее время с телефона
• Отсутствие мобильной версии CMS

Психологический фактор

Команда потеряла доверие к системе. Журналисты писали тексты в Word, боясь потерять материал в CMS.

💬 Главный редактор:

“Система больше мешает, а не помогает в работе. Каждая публикация — это испытание нервов.”

Цели проекта

Бизнес-цели

• Сократить время публикации новости с 15 до 5 минут
• Снизить количество ошибок при размещении рекламы на 40%+
• Автоматизировать модерацию комментариев на 80%+
• Повысить вовлеченность аудитории через новые форматы контента

UX-цели

• Упростить публикацию новостей до одного экрана
• Создать интуитивно понятный интерфейс без необходимости обучения
• Внедрить систему ролей и прав для защиты от ошибок
• Разработать полноценную мобильную версию для модераторов

Технические цели

• Перейти на markdown-редактор для упрощения интеграций
• Создать медиабиблиотеку с редактором изображений
• Интегрировать AI-помощника в рабочий процесс
• Разработать модуль спецпроектов с автопубликацией

---

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

Research-подход

Глубинные интервью (Фаза 1: май 2025)

• Главный редактор (1 человек) — 90 минут
• Журналисты (3 человека) — по 60 минут каждый
• Модераторы (2 человека) — по 45 минут каждый
• Администратор (1 человек) — 60 минут
• Корректор (1 человек) — 45 минут

Итого: 8 интервью, ~8 часов записей

Юзабилити-тестирование (Фаза 2: июнь 2025)

📅 График тестирований

Методология тестирования:

• Формат: Модерируемое онлайн-тестирование
• Think-aloud протокол (пользователи проговаривают мысли вслух)
• Запись экрана и курсора
• Видеозапись реакций (где возможно)
• Пост-интервью после каждого сценария

⚠️ Почему это важно:

“Периодически, когда наводишь на иконку, не всё подписывается. Сложнее быстро понять, что где есть.”

Без живого наблюдения мы бы никогда не узнали об этой проблеме — она не очевидна при внутреннем тестировании.

Инструменты валидации

Качественные метрики

• Confusion points (где пользователь запутался)
• Количество ошибок при выполнении
• Необходимость помощи модератора
• Вербальная обратная связь

Количественные метрики

• Время на выполнение сценария
• Количество кликов до выполнения задачи
• Процент успешного завершения
• NPS (Net Promoter Score)

Результаты валидации

Методология

Формат: Модерируемые глубинные интервью + UX-аудит системы

Участники:

• Главный редактор (1)
• Журналисты (3)
• Модераторы (2)
• Администратор (1)
• Корректор (1)

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

💡 Инсайт #1: Фрагментированный workflow

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

💡 Инсайт #2: Отсутствие защиты от ошибок

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

💡 Инсайт #3: Узкое место в знаниях

Логику размещения баннеров знал только один человек. Это создавало критическую зависимость и риск для бизнеса.

💡 Инсайт #4: Юридические риски

Редакция столкнулась с проблемами по правам на изображения из сторонних источников. Отсутствие медиабиблиотеки усугубляло ситуацию.

---

Jobs To Be Done

Мы проанализировали, какую «работу» каждая роль нанимает CMS выполнить. Это помогло понять не только что делают пользователи, но и зачем, в каком контексте и какие препятствия мешают.

Jobs To Be Done

Главный инсайт из JTBD

Все роли нанимают CMS для «скорости и уверенности» — не «красивый интерфейс», а «быстро сделать работу без страха ошибиться».

Это изменило наши приоритеты проектирования:

НА ЧТО ДЕЛАЛИ ФОКУС: - Автосохранение и блокировки (уверенность) - Горячие клавиши и быстрые кнопки (скорость) - AI-фильтры для модерации (экономия времени) - Единый экран для публикации (меньше переключений) - Валидация и подсказки (защита от ошибок)

ЧТО НАМЕРЕННО НЕ ДЕЛАЛИ: - Визуальные улучшения ради красоты - Анимации и “wow-эффекты” - Сложные настройки и кастомизация - Дополнительные фичи “на будущее”

Связь JTBD с решениями

Юзабилити-тестирование

Участники тестирования

• Респондент 01 — Журналист (опытный пользователь старой системы)
• Респондент 02 — Журналист (средний опыт)
• Респондент 03 — Корректор
• Респондент 04 — Администратор/Модератор
• Респондент 05 — Редактор (новичок)

Метод: Модерируемое онлайн-тестирование с записью действий

Даты: 06.06.25 - 18.06.25

📅 Расписание сессий

Метрики по сценариям

Критические проблемы UX

1️⃣ Непонятные иконки без подписей

💬 Респондент 02 (Алексей, журналист):

“Периодически, когда наводишь на ту или иную иконку, не всё подписывается почему-то. Сложнее быстро понять, что где есть, и догадываешься интуитивно.”

Найдено у: 100% респондентов

Критичность: 🔴 HIGH

2️⃣ Скрытая функция предпросмотра

💬 Респондент 02:

“Предпросмотр пока не понимаю, как… Тут предпросмотр не вижу, следовательно, он где-то внутри.”

Время на поиск: 2+ минуты

Найдено у: Респондент 01, 02, 05 (75%)

Критичность: 🔴 HIGH

3️⃣ Запутанная структура заголовков

Проблема: Дублирование функционала заголовка в редакторе и в настройках новости

💬 Респондент 01:

“Не поняла структуру заголовков и подзаголовков”

💬 Респондент 02:

“Начал работать с заголовками из редактора [вместо настроек]”

💬 Респондент 05:

“Пытался работать с заголовками внутри тела статьи”

Найдено у: 100% журналистов

Критичность: 🔴 HIGH

4️⃣ Кнопка “Настройка статьи” не заметна

💬 Респондент 05:

“Не мог найти кнопку Настройка статьи”

Время на поиск: 3+ минуты

Найдено у: Респондент 01, 05 (50% журналистов)

Критичность: 🔴 HIGH

5️⃣ Карусель изображений

💬 Респондент 02:

“Вроде бы карусель нашел, но она почему-то не появляется в самой админке. Найти карусель — обнаружить её — сложно, потому что не все подписаны.”

Найдено у: 100% респондентов при работе с изображениями

Критичность: 🟡 MEDIUM

6️⃣ Проблемы с медиабиблиотекой

💬 Респондент 01:

“Не поняла функционал кнопок включения/отключения вариантов изображения. Пыталась загрузить несколько изображений разом.”

💬 Респондент 02:

“Пытался произвести пакетную загрузку файлов”

💬 Респондент 05:

“Испытывал трудности с фильтрацией. Искал обработанную фотографию в выборке по Оригиналам”

Найдено у: 100% при работе с изображениями

Критичность: 🟡 MEDIUM

Что улучшили сразу после первых тестов

💬 Обратная связь от респондентов:

Респондент 02: “Если возможно, добавить предпросмотр вот сюда. Если я сохранил, я просто захожу сразу в предпросмотр, проверяю, что всё правильно, и всё.”

Респондент 03 (Корректор): “Добавила бы в редактор кавычки-ёлочки и длинное тире по правилам русского языка.”

Респондент 05 (Редактор): “Добавил бы функцию сброса форматирования текста”

Респондент 01: “Увеличила бы область превью в окне редактирования изображения”

Решения внедренные немедленно:

• ✅ Добавили кнопку предпросмотра в списке новостей
• ✅ Кавычки-ёлочки и длинное тире в быстром доступе
• ✅ Функция сброса форматирования (экшеном и при вставке)
• ✅ Увеличили область превью для изображений
• ✅ Тултипы для всех иконок (фиксит проблему “догадываться интуитивно”)

Изменения в UX-паттернах:

• Убрали дублирование заголовков из редактора (оставили только в настройках)
• Автооткрытие вкладки “Настройки” при создании новой статьи
• Цветная кнопка “Настройка статьи” для привлечения внимания
• Переименовали статус “Редактируется журналистом” для ясности

Метрики после исправлений:

Реакция команды разработки

💬 Фронтенд Разработчик (после просмотра тестов):

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

Ценность юзабилити-тестирования для команды:

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

💬 Из обсуждения:

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

---

Решения

1. Новый дашборд — единая точка контроля

Вместо разрозненных разделов создали единый дашборд с визуализацией статусов всех новостей.

Что изменилось:

• Все новости на одном экране
• Цветовая кодировка по статусам
• Быстрые фильтры по авторам, датам, тегам

2. Редактор статей — всё в одном месте

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

Ключевые фичи:

Markdown-редактор

• Упрощенная вёрстка без визуального мусора
• Поддержка горячих клавиш
• Автосохранение каждые 30 секунд
• История изменений

Настройка публикации

• Заголовок, подзаголовок, описание — в одной панели
• Выбор обложки из медиабиблиотеки
• Настройка времени публикации
• SEO-параметры

Блокировки

• Автоблокировка при редактировании
• Уведомления о том, кто работает с новостью
• Возможность «выгнать» пользователя (для админов)

  

Результат:

Время публикации сократилось с 15 до 7 минут.

3. Роли и права — защита от ошибок

Внедрили систему ролей с чёткими границами прав:

Эффект:

Критические ошибки снизились на 67%.

4. Медиабиблиотека — центр работы с контентом

Создали централизованное хранилище для всех медиафайлов.

Возможности:

• Загрузка изображений и видео
• Категоризация и теги
• Поиск по метаданным
• История использования
• Информация об авторе и правах

Редактор изображений

Функции:

• Обрезка и поворот
• Готовые форматы (обложка, иконка, карусель)
• Автоматическая генерация вариантов
• Предпросмотр на разных устройствах

Инсайт из тестов:

💬 Респондент 01:

“Увеличила бы область превью в окне редактирования изображения”

Решение: Увеличили превью на 40% и добавили режим полноэкранного просмотра.

5. Управление баннерами — больше никаких ошибок

Проблема до:

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

Решение:

• Визуальный конструктор позиций
• Превью на живом сайте
• Автоматическая проверка конфликтов
• Расписание показов
• Уведомления об истечении срока

Результат:

Ошибки в размещении рекламы снизились на 45%.

6. Модерация комментариев

Проблема до:

Модераторы вручную проверяли все комментарии, тратя по 4 часа в день.

Решение:

Автофильтры с ML

• Определение токсичности
• Обнаружение спама
• Фильтрация мата
• Выявление ботов

Приоритизация

• Комментарии сортируются по вероятности нарушений
• Высокий приоритет — модератор видит первым
• Низкий приоритет — проверяется выборочно

Метрики:

• Автофильтрация: 90% комментариев
• False positive rate: <5%
• Время модератора: 4 часа → 1 час (-75%)

---

Варианты решений. почему именно так?

Ключевые дизайн-решения и их обоснование

1️⃣ Markdown-редактор вместо WYSIWYG

Альтернативы, которые рассматривали:

Вариант А: WYSIWYG-редактор (как Medium, Notion)

• ✅ Привычно для нетехнических пользователей, визуальный контроль
• ❌ Сложная разработка (3-4 месяца), проблемы с форматированием из Word, тяжело интегрировать с внешними системами
• ❌ Генерирует "грязный" HTML, сложно парсить для API

Вариант Б: Notion-style блоки

• ✅ Современно, гибко, модульно
• ❌ Overkill для новостных статей, долгая разработка
• ❌ Непривычно для журналистов, высокая кривая обучения

Вариант В: Markdown-редактор ✅ ВЫБРАЛИ

• ✅ Простота интеграций — легко экспортировать в Telegram, соцсети, RSS
• ✅ Чистый HTML-вывод, быстрая разработка (1-1.5 месяца)
• ✅ Гибкость для технических пользователей
• ⚠️ Требует обучения для нетехнических сотрудников

Решение:

Markdown + live-превью + панель быстрых кнопок (заголовки, списки, ссылки)

Почему это сработало:

• Интеграция с Telegram за 2 недели вместо 2 месяцев
• Простой экспорт в любые форматы
• Журналисты освоили базовый синтаксис за 3-4 дня

---

2️⃣ Автооткрытие настроек статьи

⚠️ Проблема из тестирования:

100% журналистов начинали работу с редактора текста, игнорируя настройки (заголовок, обложка, SEO)

Альтернативы:

Вариант А: Оставить всё на одном экране (как в старой системе)

• ✅ Всё видно сразу
• ❌ Перегруженный интерфейс, когнитивная нагрузка
• ❌ На маленьких экранах всё не помещается

Вариант Б: Подсветка кнопки "Настройки"

• ✅ Ненавязчиво
• ❌ Пользователи игнорировали (проверили в тестах)

Вариант В: Автооткрытие вкладки при создании ✅ ВЫБРАЛИ

• ✅ Фокусирует внимание на правильном первом шаге
• ✅ Компромисс — сохраняем чистый интерфейс, но направляем пользователя
• ✅ После первого раза пользователи понимают логику

Решение:

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

Результат: Ошибок с незаполненными заголовками: 100% → 5%

---

3️⃣ Структура дашборда: список новостей vs альтернативы

Альтернативы:

Вариант А: Канбан-доска (по статусам)

• ✅ Наглядно видно движение новостей по воронке
• ❌ Не подходит для большого объёма (50+ новостей в день)
• ❌ Сложно фильтровать по автору/дате

Вариант Б: Календарь (по датам публикации)

• ✅ Удобно для планирования
• ❌ Срочные новости не привязаны к календарю
• ❌ Неудобно смотреть черновики

Вариант В: Список с фильтрами и группировкой ✅ ВЫБРАЛИ

• ✅ Новость — главная сущность для редакции, всё крутится вокруг неё
• ✅ Гибкие фильтры (статус, автор, дата, теги)
• ✅ Быстрый поиск, сортировка, bulk-действия
• ✅ Для каждой роли своё представление (журналист видит свои, редактор — все)

🎯 Решение:

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

Кастомизация под роли:

• Журналист: видит свои новости + назначенные на проверку
• Редактор: видит всё + фильтр "Требует внимания"
• Корректор: только новости на проверке
• Модератор: отдельный дашборд комментариев

---

4️⃣ Роли и права: простые vs настраиваемые

Альтернативы:

Вариант А: Гибкие настраиваемые права (как в WordPress)

• ✅ PМаксимальная гибкость
• ❌ Повышает нагрузку на администратора редакции
• ❌ Риск ошибок при настройке (дал лишние права → проблемы)
• ❌ Сложно поддерживать консистентность

Вариант Б: Фиксированные роли с чёткими границами ✅ ВЫБРАЛИ

• ✅ Простота для админа — назначил роль и всё работает
• ✅ Предсказуемость — все знают, что может каждая роль
• ✅ Защита от ошибок — нельзя случайно дать лишние права
• ⚠️ Cons: Менее гибко (но для новостной редакции это не критично)

🎯 Решение:

5 стандартных ролей (Журналист, Редактор, Корректор, Модератор, Администратор) с заранее определёнными правами.

Почему это сработало:

• Онбординг нового сотрудника: 5 минут вместо 30
• Ноль инцидентов с неправильными правами за 6 месяцев
• Админу не нужно вникать в матрицу прав

---

5️⃣ Медиабиблиотека: внешние сервисы vs своя

Альтернативы:

Вариант А: Интеграция с Cloudinary / Imgix

• ✅ Pros: Готовое решение, CDN, оптимизация
• ❌ Зависимость от внешнего сервиса
• ❌ Юридические риски — изображения хранятся на чужих серверах
• ❌ Дополнительные затраты

Вариант Б: Своя медиабиблиотека на сервере редакции ✅ ВЫБРАЛИ

• ✅ Контроль над данными — все изображения на своих серверах
• ✅ Предмодерация каждой фотографии перед публикацией (юридическая защита)
• ✅ Работа с авторскими правами и метаданными
• ✅ Нет зависимости от внешних сервисов
• ⚠️ Нужно разрабатывать редактор изображений

🎯 Решение:

Собственная медиабиблиотека с базовым редактором (кроп, поворот, фильтры).

Trade-off: Пришлось ограничить функционал кропа (только preset-форматы: обложка, иконка, карусель) из-за сроков MVP. Свободный кроп отложили в backlog.

---

6️⃣ AI-модерация: какую модель выбрали

Рассматривали:

• OpenAI GPT-3.5/4 — дорого, требует интернет (только через VPN)
• Yandex GPT — русский язык, но платно
• DeepSeek ✅ — бесплатно, можно self-host, хорошо с русским
• Qwen ✅ — китайская модель, отличная работа с контекстом

Решение:

Гибридная модерация: AI (DeepSeek + Qwen) + ручная проверка

• AI автоматически фильтрует 90% комментариев
• Спорные случаи (10%) идут на ручную модерацию
• Модель обучается на решениях модераторов

Результат: False positive rate < 5%

Результаты

Эффективность работы

Качество работы

Вовлеченность аудитории

Качественные результаты

💬 Главный редактор:

“Теперь можно снова сосредоточиться на журналистике, а не на том, как уговорить систему не падать. Журналисты начали чаще готовить большие лонгриды, потому что уверены — система не «съест» их черновики.”

---

Паттерн принятия решений

Для каждого решения мы использовали фреймворк:

1. Определить проблему — что не работает сейчас?
2. Сгенерировать альтернативы — минимум 3 варианта
3. Оценить по критериям:
   • Скорость разработки
   • UX для конечных пользователей
   • Техническая сложность
   • Maintenance в будущем
4. Протестировать гипотезу — валидация на пользователях
5. Измерить результат — метрики до/после

Выводы и уроки

Что сработало

✅ Глубокое погружение в домен

Неделя интервью и наблюдений дала больше инсайтов, чем месяцы работы по ТЗ. Мы поняли не только что нужно сделать, но и почему это важно.

✅ Фокус на реальных workflow

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

✅ Постепенное внедрение

Запускали функции поэтапно, собирая обратную связь. Это помогло избежать сопротивления изменениям.

✅ Восстановление доверия

Автосохранение, блокировки, роли — технические решения, которые вернули команде психологический комфорт.

✅ Живое юзабилити-тестирование

💬 Разработчик:

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

Тестирование с реальными пользователями выявило критические UX-проблемы, которые команда не замечала изнутри.

Что можно было улучшить

⚠️ Больше времени на обучение

Некоторые сложные функции (например, редактор изображений) требовали дополнительного онбординга.

⚠️ Ранняя работа с контентом

Стоило начать наполнение медиабиблиотеки еще до релиза, чтобы показать ценность сразу.

⚠️ Метрики до запуска

Не все бейзлайн-метрики были собраны заранее, что усложнило оценку эффекта.

⚠️ Больше итераций тестирования

Провели только 2 раунда с журналистами. Стоило протестировать все роли (корректор, модератор, редактор) до релиза.

Ключевой урок

🔑 Главный инсайт:

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

Культурный сдвиг в команде

💬 Финальный отзыв главного редактора:

“Теперь можно снова сосредоточиться на журналистике, а не на том, как уговорить систему не падать. Журналисты начали чаще готовить большие лонгриды, потому что уверены — система не «съест» их черновики.”

Что изменилось:

• Журналисты перестали бояться системы
• Появилось время на качественные материалы
• Команда начала экспериментировать с новыми форматами
• Снизился стресс от ежедневной работы

---

• UX исследования для дизайнеров
• Хакатон Яндекс недвижимости