HR Planner

В компании с разветвлённой структурой HR-блок и руководители сталкивались с типичной проблемой: данные о сотрудниках, проектах, загрузке, заявках и структуре подчинения жили в разных процессах.

Из-за этого было сложно быстро понять, кто перегружен, кто в каких проектах участвует, какие заявки требуют внимания и как устроены связи между сотрудниками, руководителями и HR-службой.

HR Planner должен был собрать эти процессы в одном интерфейсе: профиль сотрудника, проектную занятость, заявки, организационную структуру, справочники и настройки системы.

Во время работы часть команды и бизнес-заказчиков сменилась. Я остался одним из людей, кто держал в голове продуктовую логику HR Planner целиком: помогал новому менеджеру проекта погружаться в систему, объяснял уже принятые решения и участвовал в демонстрациях для заказчиков и руководства.

Я работал над продуктом как UX/UI-дизайнер: изучал вводные, общался с аналитиком и HR-командой, переводил прототипы заказчика в Figma, собирал основные пользовательские сценарии и готовил UI для разработки.

Отдельно я занимался описанием UI-компонентов для frontend-команды и проводил дизайн-ревью на тестовом стенде.

Проект начинался с прототипов в Axure и документации в Confluence. В них уже была общая логика продукта, но интерфейсу не хватало цельной структуры, визуальных правил и понятного сценарного слоя.

Я начал с погружения в предметную область: изучал, как HR-специалисты и руководители работают с сотрудниками, проектами, заявками, обучением и внутренними настройками. После этого перенёс ключевые сценарии в Figma и начал собирать интерфейсную систему вокруг реальных задач пользователей.

Профиль сотрудника стал одним из центральных экранов продукта.

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

Часть данных подтягивалась из 1С. Часть информации могла быть доступна только определённым ролям. Поэтому в макетах я отдельно учитывал ролевой доступ и конфиденциальные блоки: не каждый пользователь должен видеть трудовой договор, юридические данные или внутренние кадровые сведения.

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

Профиль сотрудника

Раздел проектов решал задачу ресурсного планирования.

В карточке проекта пользователь видел статус, сроки, прогресс, ответственного менеджера, команду и участников с процентом занятости. Это помогало руководителю или HR-специалисту быстрее понять, кто уже загружен, кого можно подключить к проекту и где есть риск перегруза.

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

Проекты и загрузка команды

Страница проекта

В HR Planner был отдельный блок заявок: создание, согласование, обработка и отказ.

Я проработал список заявок, статусы, фильтрацию, сортировку и сценарий создания заявки через модальное окно. Набор полей зависел от типа заявки, поэтому форма не могла быть универсальной для всех случаев.

Для согласующих ролей я показал сценарии обработки заявки: просмотр деталей, комментарии, прикреплённые файлы, результат обработки и история изменений. Счётчики в меню помогали пользователю увидеть, что по заявкам появились новые действия или обновления.

Заявки

Отдельный блок был связан с настройками системы.

Администратор мог управлять модулями, включать и отключать их через интерфейс, задавать базовые параметры компании, настраивать рабочие дни, загружать логотип, favicon, фон страницы авторизации и фирменный цвет организации.

Эта часть была важна для продуктовой модели HR Planner: система должна была адаптироваться под компанию, которая покупает лицензию, а не оставаться жёстко зашитым решением для одного заказчика.

Администрирование и кастомизация

Я собирал основные UI-компоненты и подробно описывал их в Confluence для frontend-разработчиков.

В описаниях фиксировал состояния, отступы, поведение, скриншоты и ключевые детали. Благодаря опыту в HTML и CSS мне было проще говорить с разработчиками на одном языке и объяснять, как интерфейс должен вести себя после вёрстки.

После передачи макетов я участвовал в дизайн-ревью на тестовом стенде: сверял реализацию с Figma, отмечал расхождения и помогал доводить интерфейс до утверждённого состояния.

UI-компоненты и передача в разработку

В проекте участвовали менеджер, системные аналитики, backend- и frontend-разработчики, QA, DevOps и я как UX/UI-дизайнер.

К моменту закрытия проекта основные дизайн-макеты были отрисованы и утверждены заказчиком.

HR Planner показал, что я умею быстро входить в сложный B2B-продукт, разбирать чужие прототипы, уточнять сценарии, работать с ролями и правами доступа, собирать UI-систему и сопровождать интерфейс после передачи в разработку.