image_pdfimage_print

HH.RU — Веб-приложение HH метрика

Дизайн-система. Личный кабинет. Метрика.


О проекте

HeadHunter — российская компания интернет-рекрутмента, развивающая бизнес в России, Беларуси и Казахстане. Проект HH метрики подразумевает собой грамотное и отсортированное дерево всей бизнес-информации компании, для быстрого вовлечения сотрудников и руководителей и для просмотра отчетов по этим метрикам.

В компании не было дерева метрик на котором показано как работает бизнес. До древа метрик было несколько визуализаций, в Miro (Фотография 1) и в Figma (Фотография 2) и ни одна из них в полной мере не устраивала клиента, из-за того, что они не функциональны и максимально не удобны. Клиент хотел бы сделать отдельный лендинг, который позволит всем сотрудникам компании легко ознакомиться со всеми ключевыми метриками компании, найти ответственных за эти метрики и перейти к отчётам по этим метрикам.

Прекомпозиция метрик (Фотография 1)

Первоначальный флоу (Фотография 2)

Ставя себя на место сотрудника HH, я, как продуктовый дизайнер, вижу это так:

  • Могу разворачивать древо метрик по его ветвям
  • Могу кликнуть на каждую метрику, по клику у меня должен развернуться всплывающее окно, на котором я увижу: название метрики, описание метрики, с возможной формулой подсчёта
  • Ответственного за развитие метрики сотрудника компании и куда ему писать
  • Родительские метрики на которую влияет эта метрика
  • Дочерние метрики, от которой зависит эта метрика
  • Ссылки на отчёты и дашборды по этой метрики, где на неё можно смотреть в динамике

Проблемы

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

Цели

  • Уложиться в кротчайшие сроки
  • Упростить и ускорить процессы разработки и поддержки цифрового продукта
  • Разработать MVP продукта для дальнейшего предпросмотра стейкхолдерами HH

Задачи

  • Разработать дизайн-макеты для последующей разработки
  • Описать для фронтенд-разработчика всю нужную документацию по дизай-системе HH
  • Предложить бизнес-клиенту MVP и дальнейшую версию дизайн-продукта, с потенциалом для развития продукта

Реализация

Для компании очень было важно быстрое вовлечение и реализация MVP продукта, для этого с командой HH подготовили мудборд в Miro (Фотография 3) для быстрой разработки макетов и для последующей верстки.

Фотография 3

Разработка велась с учётом выбранной React‑библиотеки — выбор пал на React Flow. Дизайн‑гайдлайн выполнялся в строгом соответствии с техническим заданием и рекомендациями фронтенд‑разработчика.

Поток создания дизайн‑макетов велся по документации дизайн‑системы HH, где чётко описаны правила использования и рекомендации. Главной проблемой проекта была неопределённость между выбором технологичности и гибкости продукта: в первоначальном ТЗ был пункт о строгой иерархии (слева направо, сверху вниз), который мешал пользователю эффективно искать нужные метрики и отчёты. В итоге гибкость удалось внедрить за счёт сбора обратной связи от потребителей HH.

Ссылка на демонстрацию

https://www.figma.com/design/9uMkaip2HmP3h6In1jvcRr/%D0%A1%D0%BC%D0%B0%D1%80%D1%82%D0%A0%D1%83%D1%82%D0%B8%D0%BD%D0%B0—%D0%94%D0%B5%D0%BC%D0%BE%D0%BD%D1%81%D1%82%D1%80%D0%B0%D1%86%D0%B8%D1%8F-?node-id=40000008-71588&t=ORT0va0nfhTw6HHu-1

Цитаты


Илья Айден

Руководитель внутренней автоматизации в HeadHunter

Захар Калачёв, UI/UX дизайнер, отлично работает в режиме исполнителя, когда у него есть чёткие вводные и пользовательские сценарии, реализуя всё в полном соответствии с видением заказчика. Он проактивен, что замечательно. Иногда его инициативы могут быть несколько преждевременными, как это бывает с разработчиками, занимающимися «преждевременной оптимизацией». Захар иногда предлагает функциональность, которая может не понадобиться в будущем. Это небольшая область для роста с точки зрения гибкости, которая легко решается в процессе коммуникации. Возможно, он потратил на это несколько лишних часов, но это не будет предметом обсуждения с точки зрения оплаты. Было бы полезно, если бы Захар сам стал лучше представлять, какой объём работы и функциональности может быть излишним для ранних версий продукта.



Захар Калачёв

Продуктовый дизайнер

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