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

Гипотезы о проблеме подтверждались через интервью, внешние исследования и замеры сценариев,
а гипотезы решений — через последующее юзабилити
сфокусироваться на ключевых сценариях
Отказаться от не релевантных функций
сформировать 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, время выполнения задач, частота использования)
  • развитие сценариев внутри дашборда
Создано на