Как дизайнеру выстраивать работу над дизайн-долгом во внутреннем продукте

Привет! Я Саша Чистова — дизайнер команды интерфейсов студии pinkman. В этой статье расскажу, как у нас появился дизайн-долг во внутреннем b2b-продукте для X5 Group и как мы выстраивали работу над ним.

Если коротко, дизайн-долг — это все дизайн-фичи, которые разработка не успела реализовать. Со временем такие задачи начинают копиться в бэклоге и превращаются в большой массив работы над исправлениями.

Последние два года мы интенсивно развивали внутренний продукт для X5 Group. В компании менялась структура, и нужно было максимально быстро выкатывать решения для цифровизации процессов.

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

Рост продукта также совпал с кризисами в стране и мире. У нас часто менялся состав команды и внутренние процессы, объём — от спринта к спринту, а процесс разработки не включал в себя работу над дизайн-ревью. В итоге дизайн-долг по проекту разросся до 100+ задач.

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

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

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

Изначально при разработке каждого нового раздела мы старались дорабатывать то, что не учли в предыдущих релизах. Но такие доработки были слишком мелкие и не всегда попадали в спринт, поэтому мы подошли к решению в несколько этапов:

• Выбрали время, когда интенсивность работы команды начала стабилизироваться, — у разработчиков появилась возможность внести доработки.
• Подготовили дизайн-долг к передаче в работу: убрали неактуальные задачи, привели в порядок описания и обновили макеты до последних версий, собрали всё в единый эпик в Jira и провели три сессии оценки задач с front-end разработкой.
• Объяснили команде важность некоторых задач из дизайн-долга. Для этого отобрали самые приоритетные таски, провели мини-исследования на пользователях, оформили все результаты и презентовали ребятам.

Чтобы систематизировать процесс, предложили установить квоту в восемь сторипоинтов (величина, позволяющая оценивать задачи) в каждый спринт на задачи из дизайн-долга. Это помогло понять, какой объём задачи нужно взять и что является наиболее приоритетным.

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

Также мы упростили взаимодействие дизайн-команды с Jira:

• Настроили дашборды с фильтрами по необходимым статусам;
• Выделили отдельные часы для проведения дизайн-ревью два раза в неделю;
• Договорились заводить подзадачи, если видим несоответствие с дизайном.

Но в таком подходе есть и минусы: например, мы работали параллельно с тестированием, а значит всё равно оставалась возможность пропустить какую-то задачу, если QA со своей стороны раньше нас протестировали и закрыли таск.

Задачи из дизайн-долга — не самая приятная часть работы, но для создания качественного продукта с ними необходимо разбираться. Поэтому, если вы заметили, что дизайн-долг давно не берётся в работу, обратите внимание на условия, в которых находится продукт.

• Учитывайте стадию развития продукта. На начальных этапах продукты часто не нуждаются в долгой полировке выпущенного функционала — это нормально. Доведите продукт до стадии, когда он начнёт стабильно работать, а потом улучшайте. Ещё постарайтесь сразу фиксировать, что будете дорабатывать в будущем — когда это время наступит, вы уже будете готовы к имплементации.

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