Portfolio
Case Study
UX-логика и структура
UX Logic · Information Architecture

Как устроена
логика продукта

Система построена вокруг одного принципа: оператор не должен искать проблему — проблема должна выйти к нему сама, с нужным контекстом и без шума.

Информационная архитектура OCC решает задачу cognitive offloading: система принимает решение о видимости, приоритете и группировке данных — оператор получает уже отфильтрованный сигнал и действует, а не анализирует.
01 · UX-принципы
— 01
Приоритет важнее полноты
Интерфейс не показывает все доступные данные. На первом слое остаются только сигналы, которые требуют действия.
— 02
Состояние сети считывается за секунды
Пользователь должен понять общую картину сети без чтения деталей и без долгого скроллинга.
— 03
Drill-down без потери контекста
Переход от overview к точке и инциденту происходит без смены сценария: контекст сохраняется, а детали открываются рядом.
— 04
Минимум переключений
Контекст точки, история и инструменты действия собраны в одном интерфейсе — без переходов между несколькими системами.
— 05
Любой сигнал ведёт к действию
Приоритет, SLA и следующий шаг читаются сразу. Сигнал не просто информирует, а подсказывает, что делать дальше.
02 · Логика приоритизации информации
Уровни сигналов / Матрица приоритетов
Критический Остановка работы точки, сбой POS/WMS, нарушение температурного режима, инцидент безопасности SLA < 15 мин
Высокий Задержка отгрузки, отклонение KPI >20%, нарушение SLA партнёра, снижение доступности SLA < 1 час
Средний Плановые задачи с риском срыва, предупреждения по запасам, повторные мелкие инциденты SLA < 4 часа
Информация Статусные обновления, завершённые задачи, плановые события — не требуют действия Фон
Группировки данных
По статусу точки По критичности По риску SLA По ответственному По региону По типу точки
Как это снижает когнитивную нагрузку
Мониторить все системы вручную
Система агрегирует данные и выдаёт единый статус точки
Понимать приоритет из потока уведомлений
Приоритет рассчитывается по критичности, SLA и влиянию на точку
Переключаться между 4+ вкладками
Контекст точки и инструменты действия собраны на одном экране
Искать историю инцидента вручную
Таймлайн событий встроен в карточку точки
Строить отчёт для передачи смены
Автосводка открытых инцидентов по смене
Держать в памяти статус каждой точки
Визуальный статус сети обновляется в реальном времени
03 · Схема информационной архитектуры
Information Architecture — структура потоков данных
Данные из внешних систем собираются в единый слой состояния точки, после чего интерфейс показывает пользователю только тот уровень информации, который нужен для первичной приоритизации, контроля и следующего действия.
ИСТОЧНИКИ ERP WMS POS / Касса Датчики IoT Логистика HR / Смены АГРЕГАЦИЯ Модель состояния точки Приоритизация сигналов Детектор аномалий SLA-трекер и таймлайн OCC ЯДРО Operations Control Center Единый реестр инцидентов Карта сети в реальном времени Уведомления и эскалация РОЛИ Операц. менеджер Карта сети + приоритизация Региональный Кластер + KPI Аналитик Отчёты + тренды Координатор Реестр + эскалация ЭКРАНЫ Dashboard · Карта сети статус всех точек + топ инциденты Регион · KPI-дашборд сравнение точек + отклонения Analytics · Отчёты исторические данные + экспорт Incident Queue реестр + назначение + таймлайн ДЕТАЛИ Карточка точки Drill-Down Метрики История Внешние системы Слой агрегации OCC платформа Роли и доступ Интерфейсные слои Детализация
04 · Уровни навигации — от обзора к действию
Уровень 1
Overview
Карта сети
Статус всех точек одним взглядом
Топ-5 активных инцидентов
Общие метрики сети в реальном времени
Быстрый фильтр по критичности и типу
Уровень 2
Регион
Кластер точек
Список точек региона с KPI
Сравнительная таблица показателей
Открытые инциденты по кластеру
Отклонения от плана по точкам
Уровень 3
Точка
Карточка объекта
Полный статус точки и активные задачи
История инцидентов и решений
Метрики: трафик, выручка, доступность
Ответственные и смена
Уровень 4
Инцидент
Карточка события
Описание, тип, критичность, SLA
Назначение ответственного
Связанные системные события
Комментарии и эскалация
Уровень 5
История
Таймлайн действий
Хронология всех действий по событию
Кто и когда принял решение
Время реакции и закрытия
Материал для разбора и обучения
05 · Как это работает в реальной операционной работе
Как это работает на практике
Операционный менеджер открывает OCC и сразу видит состояние сети, список приоритетных инцидентов и текущих ответственных. Весь путь от обнаружения до решения проходит внутри одного интерфейса.
Ключевое отличие OCC от привычных мониторингов: система не просто показывает, что происходит, а помогает быстро выбрать следующий шаг — открыть детали, назначить ответственного, эскалировать или закрыть событие.
ШАГ 01 Обзор сети Пользователь сразу видит состояние сети и приоритеты ШАГ 02 Оценка в контексте Открывает детали точки, историю и связанные риски ШАГ 03 Решение Назначает ответственного, эскалирует или меняет статус ШАГ 04 Закрытие Статус и таймлайн обновляются сразу в системе ИТОГ Resolved MTTR зафиксирован и доступен аналитику
Целевой MTTR
≤ 15 мин (Critical)
vs 40–60 мин в текущем процессе без системы
Переключений контекста
0 внешних систем
весь путь инцидента внутри OCC
Когнитивная нагрузка
Снижена структурно
система расставляет приоритеты, не оператор
Ключевые экраны
Key Screens · Wireframes
Live Interface — overview dashboard и карточка точки
← Назад к кейсу Ключевые экраны →