Дизайн
Skytrace: личные кабинеты для 4 ролей
Доработала и собрала личные кабинеты для пользователя, партнёра, дистрибьютора и вендора — всех участников цепочки продаж системы управления ИТ-инфраструктурой.
О проекте
- Роль
- UX/UI-дизайнер
- Период
- 2024–2025, в два этапа
- Платформа
- Веб, десктоп
- Команда
- Менеджер проекта, команда заказчика из 3 человек, разработчики заказчика
- Что сделала я
- На основе наработок заказчика доработала, переделала и собрала все 4 кабинета — структура разделов, статусы, фильтры, формы; дополнила UI-kit
Задача
Заказчик — российская компания, которая разрабатывает и внедряет систему управления рабочими местами и серверами. Продукт продаётся не напрямую, а через дистрибьюторов и партнёров-интеграторов. Лицензии считаются по числу устройств, к ним добавляются техподдержка, внедрение и обучение.
Нужны были личные кабинеты для всех участников этой цепочки. У заказчика уже были наработки: ТЗ и часть кабинета пользователя. Я доработала их, добавила новые роли и фильтры и собрала четыре цельных кабинета.
Пользователи и роли
Это четыре отдельных кабинета, у каждого своё меню и свои права.
- Пользователь — ИТ-специалист компании-клиента. Смотрит свои лицензии, скачивает дистрибутивы, обновления и документацию, пишет в техподдержку.
- Партнёр — интегратор, который продаёт и внедряет продукт. Регистрирует проекты, заказывает лицензии для клиентов, видит объём продаж, прайс-листы и маркетинговые материалы, добавляет сотрудников.
- Дистрибьютор — крупный реселлер. Следит за совершёнными и планируемыми отгрузками, согласует отгрузки по проектам.
- Вендор — менеджер со стороны компании, у него полный доступ: все лиды и проекты, управление пользователями, партнёрами и дистрибьюторами.
Что было сложным
Карты бизнес-процесса не было. Я разбиралась в нём в разговорах с менеджером проекта и раскладывала по экранам уже по ходу работы.
Требования росли. Заказчик составил ТЗ, но после каждого показа экранов добавлял правки: новые статусы, поля, возможности. Их приходилось встраивать в уже собранный интерфейс так, чтобы логика не развалилась.
Данных много, и они мелкие: на одном экране — список, статусы, суммы, фильтры и действия.
Ключевые решения
Статусы, которые работают как фильтр
Проблема. У лида в кабинете вендора 8 статусов, у проекта партнёра — 13. В общем списке трудно найти записи, которые ждут действия.
Что я сделала. Статусы попросил заказчик. Я разобралась, как у них идёт сделка, и вынесла статусы в ряд над списком: каждый статус — одновременно фильтр, у каждой записи цветная метка. Когда поняла схему, предложила и свои фильтры — по статусу, дате и сумме. Счётчик новых записей предложил менеджер: логично, хотя интерфейс он нагружает.
Решение по заявке прямо в списке
Проблема. Партнёр получает много новых проектов, и на каждый нужен ответ.
Что я сделала. Кнопки «Отклонить», «На доработку» и «Принять» стоят прямо на карточке в списке — не нужно открывать каждый проект. У дистрибьютора и вендора та же схема для отгрузок: «Согласовать» или «Отказать».
По требованию заказчика при отказе и отправке на доработку причина обязательна: так её не нужно вспоминать, а вторая сторона знает, что исправить.
Контрагенты по цепочке продаж
Проблема. Вендору нужно видеть не просто список компаний, а кто через кого продаёт.
Что я сделала. Раздел «Контрагенты» с вкладками «Пользователь», «Партнёр», «Дистрибьютор» и статусами договора. Из карточки дистрибьютора можно перейти к его партнёрам и их проектам. Партнёров можно отфильтровать по названию и по уровню, который ввёл заказчик.
UI-kit и передача в разработку
Заказчик дал начальный набор компонентов, я дополнила его: статусы, фильтры с вложенными меню, таблицы и ячейки, формы. У кнопок есть состояния обычное, наведение, нажатие и неактивное, у полей ввода — пустое, заполненное и с ошибкой. Пустые списки и окна успешного действия тоже нарисованы. Отдельных экранов загрузки и ошибок не было.
Макеты передавались в Figma: менеджер проекта оставлял комментарии и сам передавал их разработчикам заказчика, напрямую с разработкой я не общалась.
Взгляд на доступность: что я исправила бы сегодня
Доступность в этом проекте не закладывалась, а информации было много, и её приходилось уплотнять. Сегодня я бы исправила:
- Серые подписи и вторичный текст. Цвет #9CA3AF даёт контраст 2,5:1 на белом и 2,3:1 на сером фоне, а нужно от 4,5:1. Затемнила бы до #4B5563. Критерий 1.4.3.
- Белый текст на цветных кнопках. На оранжевой «На доработку» контраст 2,1:1, на зелёной «Принять» — 2,3:1. Поставила бы тёмный текст или более тёмный фон. Критерий 1.4.3.
- Мелкие цели нажатия. Крестик сброса фильтра — около 16 px, статусы-фильтры — около 22 px в высоту, а минимум 24 px. Критерий 2.5.8.
- Фокус. В UI-kit нет состояния фокуса: с клавиатуры не видно, где ты находишься. Добавила бы заметную обводку для кнопок, полей и статусов. Критерий 2.4.7.
Итог
Кабинеты внедрены, заказчик ими пользуется.
На этом проекте я научилась разбираться в чужом бизнес-процессе и переводить его в интерфейс: выстраивать логику разделов, называть статусы и подбирать для них цвета.
Сегодня многоролевой кабинет для бизнеса я начала бы с карты бизнес-процесса, а не с экранов: от процесса зависит, каким будет дизайн. Прототипы делала бы сначала без цвета, чтобы видеть блоки и собрать цельную структуру. И не мельчила бы: здесь в один экран попало слишком много, и интерфейс получился мелким.