О компании

Компания  специализируется 
в интеграции своего продукта
по созданию личных кабинетов для ключевых компаний РФ
для корпоративных систем
и крупного бизнеса
Входит в ТОП-50 ведущих digital production России, ТОП-30 
веб-разработчиков / интеграторов России.
ТОП-40 рейтинга «Поддержка и развитие сайтов для бизнеса и потребителей», 
ТОП-50 рейтинга разработчиков сайтов для крупного бизнеса, 
ТОП-15 в рейтинге Мобильная разработка на субподряде, 
ТОП-40 рейтинга digital-интеграторов.

Кратко о проекте

Информация

О проекте

Цель — разработать корпоративный B2B-дашборд,
который решает внутренние проблемы компании 
и может быть масштабирован, как коммерческий продукт для других бизнесов.

Моя роль

Продуктовый дизайнер — сценарии,
структура дашборда, логика виджетов
Исследователь — интервью, user flow,
юзабилити-тестирование, анализ научных статей
Продуктовый менеджер — формирование гипотез, приоритизация MVP, оценка бизнес-эффекта (ROI)

Ключевая проблема

Проблема кейса является конфликт между решением проблем сотрудников компании, и универсального решения для продаж нового продукта другим клиентам

Мои вызовы:

Проблема пользователей

Текущий корпоративный портал не работает, потому что им никто не пользуется

Столкновение интересов стейкхолдеров

  • Директор хочет универсальный дашборд для продажи
  • HR продвигает 
    корпоративную культуру
  • Сотрудники хотят, чтобы я решил их проблемы в работе

Технологические ограничения

Текущий корпоративный портал не работает, потому что им никто не пользуется

Предварительные результаты

Сокращение времени поиска 

Сотрудники стали меньше искать нужные ссылки и документы 
из 40 секунд до 10

Создание универсальных виджетов

8 универсальных виджетов, которые покрывает большее количество сценариев 

Маштабируемость

Продукт создан на долгосрочное развитие

Этап 1. Бриф 
с стейкхолдерами

На старте мне дали краткое ТЗ. Чтобы точнее понять задачу, я инициировал трехстороннюю встречу с HR, арт-директором и мной как дизайнером
Результаты встречи
Ограничения бизнеса
Решение нужно было строить на базе 
уже существующих функций портала
Устаревший UI-Kit
Проблема организованности
У сотрудников нет единой организованной рабочей среды
проекты, сервисы и документы разбросаны по разным системам;
Сроки запуска
Сроки были короткими, поэтому бизнес ориентировался на запуск MVP за 9 месяцев;
Этап 2. Исследование
Чтобы понять, как сотрудники работают с системой, 
я провёл серию интервью с представителями разных ролей: 
дизайнер, разработчик, тимлид, менеджер проекта и директор. 
я сделал акцент на покрытии разных ролей, 
чтобы увидеть полный цикл работы.
Что я хотел проверить
В рамках интервью я фокусировался на следующих вопросах:
Как сотрудники находят нужные проекты и документы
С какими системами работают ежедневно
Как отслеживают задачи и поручения
Какие действия выполняют чаще всего

Основные наблюдения

Игнорирование уведомлений

100% респондентов. Полностью игнорируют стандартные системные уведомления
и подвержены «баннерной слепоте»

Портал не является инструментом

100% респондентов. Сотрудники редко посещают 
в корпоративный портал и используют его только как справочник

Отсутствие организованности

80% респондентов. Теряют рабочее время на поиск нужных ссылок, документов и контактов из-за использования множества систем (Jira, Git, ЦУП, Total и т.д.).

Общая информация не интересна

80% респондентов. Развлекательные и общие виджеты сотрудники не хотят видеть в своем дашборде

Точно не уверенны, что сотрудник сегодня работает

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

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

Гипотеза

Централизация рабочих ссылок и ресурсов 
сократит время на поиск проектов и документов

Обоснование

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

Гипотеза

Отображение статуса доступности сотрудников снизит количество лишних уточнений и ожиданий ответа

Обоснование

Менеджеры и тимлиды тратят время на коммуникацию 
с коллегами, которые могут быть недоступны (встреча, отпуск)
Учёт времени

Гипотеза

Снижение порога входа в учёт времени
повысит регулярность списания часов

Обоснование

Текущий процесс требует дополнительных действий (VPN, поиск задачи), поэтому сотрудники откладывают заполнение и вносят данные позже
Уведомления

Гипотеза

Единый  центр уведомлений повысит
осведомленность сотрудников о задачах

Вывод

Пользователи игнорируют стандартные
уведомления из-за информационного шума

Трансформация решения

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

Гипотеза

Социальные блоки на главном экране
повысят вовлечённость сотрудников

Вывод

Для опытных сотрудников портал воспринимается как рабочий инструмент, а не как медиа-площадка.

Трансформация решения

Трансформация решения: Социальный контент стал вторичным и опциональным.

Вывод по этапу

Гипотезы о проблеме подтверждались через интервью, внешние исследования и замеры сценариев,
а гипотезы решений — через последующее юзабилити
сфокусироваться на ключевых сценариях
Отказаться от не релевантных функций
сформировать MVP 
с максимальным влиянием 
на ежедневную работу
Этап 4. Оценка стоимости проблемы
Чтобы перевести проблему в бизнес-контекст, 
я сделал примерную оценку сценария поиска проекта.

Текущий сценарий

В среднем пользователю требовалось:
  • несколько переходов между системами
  • 6–8 кликов
  • около 2–3 минут на поиск нужной точки входа 

Расчет

При допущении:
  • 60 сотрудников
  • ~ 3 минуты в день на поиск
  • 450 р / ч
Получается 
  • 26 000 р. в месяц
  • 320 000 р. в год

После решения
(по результатам тестирования)

Сценарий сократился до:
  • 1 системы
  • 2-3 кликов
  • около 30-40 секунд на поиск

Новый расчет

  • 6 000 р в месяц
  • 160 000 р в год

Вывод

Оценка стоимости позволило общаться с с директором
и CEO на языке бизнеса. Показать значимость проблемы 
и получить разрешение на проведение юзабилити-тестирования
Этап 5. Приоритизация решений
После формирования гипотез и оценки стоимости проблемы следующим шагом было определить, какие сценарии дадут максимальный эффект в рамках MVP
Интересы бизнеса
HR, руководитель
Реальные боли
Пользователи
Сложность реализации
Технические ограничения
Подход
Для каждого потенциального виджета я оценивал:
Какую проблему он решает
Насколько он критичен для бизнеса
Насколько часто этот сценарий встречается
Какую сложность имеет реализация

Результат оценки

Критичные
именно они формируют ежедневную работу пользователя
  • уведомления (контроль задач)
  • быстрый доступ к ресурсам 
  • поиск (вход в работу)
  • события
Поддерживающие
важны, но не являются
точкой входа
  • учёт времени
  • статусы сотрудников
Вторичные
не влияют напрямую
на выполнение задач
  • Новости
  • Социальный контент
Ниже показан фрагмент анализа, на основе которого
принимались решения о приоритетах.
Этап 6. Решения
На основе приоритизации я спроектировал дашборд 
как единую точку входа в рабочие процессы сотрудников
Целью было не просто добавить новые функции,
 а собрать ключевые сценарии в одном интерфейс
Подход
Дашборд объединяет ключевые сценарии:

Вход в работу

Поиск и быстрый доступ к ресурсам

Контроль задач

Уведомления и приоритет действий

Осведомленность

События, отсуствующие

Поддерживающие функции

Учет времени, статус сотрудников
Этап 7. Проектирование логики
В рамках кейса я сосредоточился на сценарии 
“важные уведомления” как ключевом 
для ежедневной работы сотрудников.
Он является одним из самых важных, так как он отвечает на вопрос: "Что мне нужно сделать сейчас"?

Структура сценария

Entry Flow

Как пользователь попадает в уведомления и перемещается между режимами

Action Flow (получатель)

Как пользователь видит уведомление и подтверждает выполнение

Action Flow (автор)

Как создаются, редактируются и контролируются уведомления

Проработка сценариев

Этап 8. Архитектура решений
После определения ключевых сценариев я перешёл к построению структуры дашборда
Основная задача архитектуры —
собрать разрозненные действия пользователя в один понятный поток:
открыть → понять, что делать → начать работу

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

События

Встречи и планирование

Поиск с ИИ

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

Поддерживающие блоки

учёт времени, статусы сотрудников
(дополняют основной сценарий)
Этап 10. Тестирование
После проектирования я провёл юзабилити-тестирование с участием сотрудников компании.
В рамках одной из итераций для оценки распределения внимания использовался инструмент отслеживания взгляда
До
До
После
После
Акцент перешел с заголовков на контент
Изменения после тестирования
  • уменьшил визуальный вес заголовков
  • смягчил акцент блока уведомлений (сохранил заметность, убрал “давление”)
  • перевёл даты в более читаемый формат (относительный + человекочитаемый)
Этап 10. Результат
На момент завершения проекта решение не было внедрено в продакшн, однако его эффективность была проверена 
на этапе прототипа.

Что удалось подтвердить

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

Обратная связь бизнеса

Руководители и CEO подтвердили следующее:
  • Значимость проблемы
  • Применимость решения в текущих процессах
  • Готовность к дальнейшему развитию продукта
  • Что система масштабируется в будущем 
Этап 11. Мои выводы
Я спроектировал самостоятельно интерфейс с нуля. Переосмыслил роль корпоративного портала. 
Из формальной страницы в настоящий инструмент 

Системный подход

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

Обратная связь бизнеса

Руководители и CEO подтвердили следующее:
  • Значимость проблемы
  • Применимость решения в текущих процессах
  • Готовность к дальнейшему развитию продукта
  • Что система масштабируется в будущем 

Чему научился

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

Дальнейшее развитие продукта

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