Контекст
Weeek - Российский аналог Clickup, Asana и Notion или же B2B SaaS-платформа для управления задачами, проектами и командами, с базой знаний, CRM и аналитикой. 968 000+ пользователей, 30 000+ активных команд
В Weeek руководители и тимлиды управляют командами, распределяют задачи и отвечают за сроки проектов. Но при планировании работы возникала проблема: не было единого места, где можно было бы быстро увидеть загрузку команды и понять, кто перегружен, а у кого есть свободное время
Чтобы оценить загрузку, руководителям приходилось сопоставлять задачи, сроки и оценку времени вручную — в том числе с помощью таблиц и сторонних инструментов
Для бизнеса это было особенно важно в сегменте команд 10+ человек: по мере роста команды планирование становится сложнее, а потребность в ресурсном планировании — выше
Задача
Создать собственный инструмент планирования загрузки, который:
повысит ценность Weeek для команд 10+;
снизит необходимость использовать сторонние инструменты;
увеличит глубину использования продукта;
станет основой для дальнейшего развития платных возможностей планирования
Процесс
Исследование
На старте у меня были:
PRD от продакта с предполагаемым MVP;
сообщения и пожелания руководителей из пользовательских переписок;
решения конкурентов
Я изучил, как аналогичные задачи решаются в других продуктах: какие данные показываются менеджеру, как визуализируется загрузка, как устроена детализация и какие действия доступны непосредственно из графика
Поиск концепции
Перед тем как углубляться в частные случаи надо определиться с фундаментом. Примерное ожидание от MVP и референсы от конкурентов у меня есть - рисуем концепт раздела
Решения
Быстрая оценка загрузки всех исполнителей
Менеджеру нужно понять, кто из сотрудников загружен, кто свободен и есть ли проблемы с планом
Даже без детального просмотра задач на графике визуально видно распределение загрузки по сотрудникам и дням. Но одного визуального сигнала недостаточно: менеджеру нужно быстро сравнивать сотрудников между собой.
Поэтому рядом с именем каждого исполнителя я добавил индикатор загрузки, который показывает, сколько часов уже запланировано относительно доступной нормы. Если сотрудник выходит за норму, индикатор меняет состояние и сразу привлекает внимание к потенциальной перегрузке
Как разобраться в причинах перегрузки?
Менеджер обнаружил, что сотрудник перегружен. Нужно понять почему: какие задачи создают нагрузку, в какие дни возникает проблема и насколько она серьёзная
Я добавил возможность раскрыть список задач непосредственно внутри графика
Задачи отображаются как временные отрезки - по тому же принципу, который пользователи уже знают по диаграмме Ганта
Таким образом, менеджеру не нужно покидать график, чтобы разобраться в источнике нагрузки
Детализация через тултипы
Не всю информацию было рационально показывать непосредственно на графике, поэтому подробности я вынес в контекстные тултипы
Тултип на конкретном дне показывает информацию о загрузке за этот день, а на общем индикаторе позволяет посмотреть данные за весь отображаемый период.
Это решает сразу несколько задач:
показывает фактическое количество часов
показывает точное превышение нормы
объясняет расхождения между общей загрузкой и видимыми задачами
Работа со скрытыми задачами
Отдельно я проработал узкое место: часть задач может быть недоступна менеджеру, но график показывает загрузку целиком
Если просто показать менеджеру число «40 часов» и список задач на «25 часов», возникает ощущение, что график ошибается. Поэтому в тултипе с деталями я сделал причину расхождения более явной
В деталях загрузки менеджер может увидеть:
Сверх нормы
Сколько часов приходится на превышение доступной нормы.Скрытые / доступные
Есть ли задачи, которые менеджер не может просматривать.По фильтрам / остальные
Есть ли задачи, исключённые текущими фильтрами.
Фильтр по проекту: Как не потерять общую загрузку сотрудника, когда он активен?
У сотрудника несколько проектов. Менеджеру нужно понять, какую часть его загрузки занимает конкретный проект и не создаст ли работа по нему перегруз.
Для этого я использовал существующий компонент фильтров и встроил его в новый раздел. В нём можно выбрать один проект или несколько проектов одновременно.
Но здесь возникла важная UX-проблема: Если после применения фильтра полностью заменить общую загрузку на отфильтрованную, менеджер теряет контекст
Для примера: Общая загрузка - 7 часов, а в проекте N - 5 часов. Если показать только 5 часов, легко решить, что у сотрудника есть ещё 3 свободных часа из его дневной нормы, хотя на деле остальные 2 заняты другими проектами
Поэтому я разделил график на два слоя
Общая загрузка остаётся на заднем плане, а загрузка по выбранному фильтру отображается поверх неё
Так менеджер одновременно видит насколько человек загружен всего и сколько этой загрузки занимает конкретный проект
При этом тултип учитывает оба слоя и показывает соответствующую детализацию.
Это решение позволило сохранить контекст при фильтрации и снизить риск принятия неправильного решения о перераспределении задач.
Настройка рабочей нормы
Не все сотрудники работают по стандартному графику 5/2 и 8 часов в день.
Для этого я продумал настройку доступной загрузки на двух уровнях:
Рабочее пространство — общая норма для команды.
Участник — индивидуальный график конкретного сотрудника.
При этом норма стала не просто настройкой интерфейса, а частью логики расчёта перегрузки: например, если сотрудник работает 8 часов в день с понедельника по пятницу, задача на 40 часов, распределённая на будни и не создаёт перегрузку
Если изменить рабочий график — например, установить другую дневную норму или добавить выходные — расчёт автоматически подстраивается
Отдельно учитываются задачи, поставленные на выходные: поскольку доступная норма в этот день равна нулю, такая работа считается перегрузкой независимо от количества часов
Таким образом, график становится гибким для команд с самым разным рабочим графиком
Передача в разработку
После согласования концепции я провёл совместный разбор решения с PM, дизайн-лидом и разработкой. На этом этапе я:
подготовил сетку новых компонентов;
описал использование существующих компонентов;
проработал состояния;
подготовил 21 экран с основными и краевыми сценариями;
учёл разные ширины экрана;
проработал loading;
empty states;
ошибки;
состояния фильтров;
различные варианты загрузки и доступности данных.
После того, как фича попала на dev ветку, я заревьюил её и работал с разработчикам по правкам, которые должны были быть внесены
Релиз
После запуска я помог команде маркетинга подготовить визуальные материалы для релиза:
иллюстрации для публикаций в Telegram;
изображения для статьи об обновлении.
❇️
Результаты
Adoption
56.6% платящих команд попробовали фичу хотя бы один раз
30.7% используют его регулярно
Частота
В среднем — около 25 событий в месяц на пользователя, среди регулярных пользователей — около 44 событий.
Новые пользователи
30.9% новых команд начинают использовать график в течение первых 14 дней.
При этом регулярные пользователи в основном относятся к командам 7+ человек, что подтверждает первоначальную гипотезу о ценности инструмента для более крупных команд.
UX Feedback
При попытке разобраться с графиком:
12% сразу поняли, как начать работу.
25% почти поняли, но у них остались вопросы.
63% не смогли самостоятельно понять, как использовать график.
❇️
Выводы
Я научился брать ответственность за UX решения в большом продукте, прорабатывать сложные сценарии без готовых паттернов и выстраивать системный дизайн в условиях высокой скорости и постоянной смены приоритетов
Также есть важная точка роста: прослойка пользователей, которым непонятно, как работать с разделом — 63%. Часть из них попробовали раздел, но не смогли в нём закрепиться. Возможно, дело в их процессах; возможно, не проработан важный для них сценарий; а может, просто не хватает понятных подсказок. В любом случае, если выявить и устранить пробелы, ещё больше пользователей увидят дополнительную ценность платного тарифа WEEEK, на котором график и доступен
Что бы я сделал дальше?
Я бы исследовал несколько гипотез:
Доля “неразобравшихся” не использует оценку времени в своей работе
Не хватает фичей
Не хватает хорошего онбординга при первом запуске фичи
🤓 Выводы
Этот проект был для меня не столько задачей «нарисовать график», сколько задачей спроектировать новый инструмент принятия решений внутри сложного B2B-продукта
Мне пришлось работать одновременно с:
бизнес-целями
пользовательскими сценариями — планированием, поиском перегрузки и перераспределением задач
сложными состояниями — фильтры, приватные задачи, нестандартные графики, выходные, масштабы, состояния индикатора и распределение графика
техническими ограничениями — часть существующих компонентов пришлось адаптировать под требования нового раздела
аналитикой — оценкой adoption, частоты использования и удержания после релиза
