Как дизайнеру выстраивать работу над дизайн-долгом во внутреннем продукте
Привет! Я Саша Чистова — дизайнер команды интерфейсов студии pinkman. В этой статье расскажу, как у нас появился дизайн-долг во внутреннем b2b-продукте для X5 Group и как мы выстраивали работу над ним.
Что это такое и как мы к этому пришли
Если коротко, дизайн-долг — это все дизайн-фичи, которые разработка не успела реализовать. Со временем такие задачи начинают копиться в бэклоге и превращаются в большой массив работы над исправлениями.
Как у нас накопился дизайн-долг
Последние два года мы интенсивно развивали внутренний продукт для X5 Group. В компании менялась структура, и нужно было максимально быстро выкатывать решения для цифровизации процессов.
В этих условиях приоритеты сместились к усиленному созданию нового функционала — команде не оставалось времени на «причёсывание» продукта, а улучшения оставались в бэклоге.
Рост продукта также совпал с кризисами в стране и мире. У нас часто менялся состав команды и внутренние процессы, объём — от спринта к спринту, а процесс разработки не включал в себя работу над дизайн-ревью. В итоге дизайн-долг по проекту разросся до 100+ задач.
Почему большой дизайн-долг – это критично
В случае с внешними продуктами большой дизайн-долг может привести к отставанию в удобстве и визуале от конкурентов. Даже при равной ценности продуктов, пользователь, скорее всего, выберет сервис с более дружелюбным и современным интерфейсом.
Для внутренних продуктов это опасно тем, что интерфейсом будет просто неудобно пользоваться, и, по нашему опыту, работа с такими сервисами может привести к тихому саботажу со стороны пользователей. Да, внутренними сервисами нельзя не пользоваться, но велика вероятность, что работу с такими продуктами будут стараться делегировать кому-то другому.
При этом важно понимать, что величина дизайн-долга не обязательно коррелирует с критичностью фичей в нём — большой дизайн-долг не всегда ведёт к краху продукта. Посмотрите, например, на SAP.
Как мы выстроили работу
Изначально при разработке каждого нового раздела мы старались дорабатывать то, что не учли в предыдущих релизах. Но такие доработки были слишком мелкие и не всегда попадали в спринт, поэтому мы подошли к решению в несколько этапов:
- Выбрали время, когда интенсивность работы команды начала стабилизироваться, — у разработчиков появилась возможность внести доработки.
- Подготовили дизайн-долг к передаче в работу: убрали неактуальные задачи, привели в порядок описания и обновили макеты до последних версий, собрали всё в единый эпик в Jira и провели три сессии оценки задач с front-end разработкой.
- Объяснили команде важность некоторых задач из дизайн-долга. Для этого отобрали самые приоритетные таски, провели мини-исследования на пользователях, оформили все результаты и презентовали ребятам.
Чтобы систематизировать процесс, предложили установить квоту в восемь сторипоинтов (величина, позволяющая оценивать задачи) в каждый спринт на задачи из дизайн-долга. Это помогло понять, какой объём задачи нужно взять и что является наиболее приоритетным.
В идеале ещё хотели сделать обязательной стадию дизайн-ревью во флоу закрытия задачи в Jira так, чтобы без согласия от дизайнера задачу закрыть было бы невозможно. Однако не смогли получить достаточный уровень прав в Jira для её настройки.
Флоу работы команды
Также мы упростили взаимодействие дизайн-команды с Jira:
- Настроили дашборды с фильтрами по необходимым статусам;
- Выделили отдельные часы для проведения дизайн-ревью два раза в неделю;
- Договорились заводить подзадачи, если видим несоответствие с дизайном.
Но в таком подходе есть и минусы: например, мы работали параллельно с тестированием, а значит всё равно оставалась возможность пропустить какую-то задачу, если QA со своей стороны раньше нас протестировали и закрыли таск.
Резюмируя: как строить работу над дизайн-долгом во внутреннем продукте
Задачи из дизайн-долга — не самая приятная часть работы, но для создания качественного продукта с ними необходимо разбираться. Поэтому, если вы заметили, что дизайн-долг давно не берётся в работу, обратите внимание на условия, в которых находится продукт.
- Учитывайте стадию развития продукта. На начальных этапах продукты часто не нуждаются в долгой полировке выпущенного функционала — это нормально. Доведите продукт до стадии, когда он начнёт стабильно работать, а потом улучшайте. Ещё постарайтесь сразу фиксировать, что будете дорабатывать в будущем — когда это время наступит, вы уже будете готовы к имплементации.
- Покажите команде, как доработки связаны целями продукта. Для этого можно провести исследования и опросы. Они помогут вам найти аргументы для старта работ над дизайн-долгом.
- Сделайте работу с дизайн-долгом обязательным шагом, включив его в общий флоу разработки. Делать это лучше последовательно — резкие изменения могут быть отвергнуты с большей вероятностью, чем плавные улучшения процесса.
отличная статья,спасибо
согласен, статья что надо
Подход отличный! Но сам факт наличия дизайнерского это очень странно, для продуктовых команд прям на грани (это же то ради чего и пилят фичи)
в Jira надо было попросить добавить Demo или Авторская приемка (по факту название можно подобрать исходя из убеждений команды разработки и принятым ритуалам, во всех фреймоворках есть такой этап:))
Этот этап как раз про проверку достижения целей реализации:)