Сфера — платформа для командной разработки ПО

Основной дизайнер продукта. За время работы наладил процесс дизайна в команде: раньше он был не структурирован — много хаоса и переделок макетов. Внедрили дискавери фичи на предварительном этапе, когда решения согласуются с командой и разработкой, чтобы заранее понимать ограничения. Все продуктовые решения строятся на взаимодействии с пользователем на всех этапах — и до проработки, и после реализации.

Рабочий подход показан ниже на примере создания фичи «Структура» — одной из многих задач в продукте.

Задача

Новый функционал «Структура»: многоуровневые иерархические представления задач (эпики → истории → задачи → дефекты) с гибкой настройкой уровней и QL-фильтрацией. Аналог Jira Structure, но со спецификой основного заказчика: планирование спринтов и контроль поставок по своим правилам.

Что не так

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

Решение

Фича дорогая в разработке, поэтому до старта проработки провели большую серию предварительных интервью — определили основные сценарии использования и разбили объём на MVP и post-MVP, чтобы в MVP уместить только необходимое.

Мастер создания структуры. Параметры (название, доступ, пространства) и настройка отображения по уровням: на каждом уровне — тип связи (дочерние / связанные) и типы задач, плюс QL-запрос для точечной корректировки набора задач на уровне.

Итоговое представление. Раскрываемая таблица со сменой атрибутов, ресайзом колонок и инлайн-редактированием статусов и оценок.

Исследование

После релиза MVP провели серию качественных интервью, чтобы оценить результат и собрать проблемы фичи. Логика построения структуры в целом понятна, все пользуются QL для корректировки набора задач на уровне.

Выявлен ряд приоритетных доработок: сортировка и группировка по атрибутам в таблице, подсказки синтаксиса QL, раскрытие структуры до выбранного уровня, калькулируемые и кастомные колонки, массовые изменения, сохранение набора атрибутов, фильтрация по исполнителю и команде, стабильность и документация. Часть гипотез (например, «растягивание» уровней прокруткой) не подтвердилась и вынесена из приоритета.

Развитие: диаграмма Ганта

После доработки критически важного функционала следующим этапом эволюции фичи стало переключение структуры в вид диаграммы Ганта. Инструмент собрал положительную обратную связь пользователей.

Благодаря новому инструменту команды могут:

• планировать быстрее — сроки и последовательность задач видны сразу, без ручной сверки;
• видеть общую картину по нескольким командам и пространствам на одном экране;
• отслеживать зависимости между задачами и вехи релизов;
• работать с планом прямо в структуре, без переключения между инструментами.

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

Сфера.Команда — HR-система: найм, учёт времени, распределение ресурсов, планирование бюджета, развитие сотрудников и контроль эффективности; роль-ориентированная — от сотрудников до топ-менеджмента.

Процесс работы в продукте показан на примере двух задач — функциональности «Функциональная структура» и редизайна навигации.

Функциональная структура

Что было не так. Визуализация оргструктуры компании не масштабировалась под разные модели — функциональную, сервисную, проектную; работа со структурой занимала 10–15 минут.

Исследование. Интервью и CSAT, чтобы понять боли и ожидания; полевые наблюдения — как люди реально работают с системой; сравнение с рынком и внутренними стандартами.

Что сделали. Переработали визуализацию структуры под разные модели; сохранили и улучшили табличный режим; вынесли расширенный набор данных на карточки.

Было

Стало

Результат. Время работы со структурой компании — с 10–15 минут до 1–2 минут. Позитивная обратная связь, сокращение прохождения ключевых сценариев.

Редизайн навигации

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

Что сделали. Универсальное меню: пользователь одинаково попадает в нужные модули из любой точки продукта.

Было

Стало

Результат. Позитивная обратная связь по навигации, сокращение прохождения ключевых сценариев.

Задача

TODO — что за продукт, задачи.

Решение

TODO.

Результат

TODO.

Разные типы исследований, которые применял на продуктах платформы.

CJM и информационная архитектура

Что: до этого CJM и работа с информационной архитектурой на платформе не практиковались — продакт-менеджеры и дизайнеры путались в собственных фичах, у команд не было общей картины сценариев. Начал собирать CJM и пересобирать IA как часть работы над продуктами.

Метод: детальные CJM по ролям и этапам (вход, обзор и поиск, работа с объектом, планирование) — с точками контакта, мыслями, действиями и болями на каждом шаге; на их основе — переработка информационной архитектуры продукта.

Результат: построены основные роли пользователей; по обратной связи с CJM собран бэклог задач на доработку продукта.

Опрос и интервью

Что: как пользователям удобнее работать с карточкой задачи в таск-менеджере — в каком формате её открывать (полный экран, широкая боковая панель, узкая шторка) в разных сценариях и почему.

Метод: 10 глубинных интервью (аналитики, разработчики, тестировщики, лиды, скрам-мастера) и опрос на платформе — 76 респондентов. Всего 86 ответов.

Результат: 74% предпочитают широкую боковую панель — она закрывает большинство сценариев; полноэкранный режим нужен для глубокой работы с телом задачи, но быстрого перехода в него из карточки нет; для смены статуса достаточно узкой шторки. Рекомендации: широкая панель по умолчанию, явный переход на полный экран рядом с номером задачи, упростить переход к клонированной задаче.

UX-тест

Что: тестировал прототип создания доски для нескольких пространств с QL-запросом — сравнивал две версии логики: фильтрация на этапе создания доски и постфильтрация (настройка фильтров уже на готовой доске).

Метод: UX-тест на прототипе, 6 респондентов (скрам-мастера и agile-коуч).

Результат: версия с фильтрацией при создании — успешность задания 100%, все справляются без критических трудностей; постфильтрация — 67% (5 из 6 не сразу находят, где ввести QL-запрос). При этом по предпочтению 4 из 6 выбирают постфильтрацию — за гибкость и чтобы «не плодить доски». Решение: оставить обе версии, доработать вординг и подсказки, добавить визуальный редактор фильтров, группировку по пространствам и поиск пространств на итоговой доске.