По мере развития продукта начинают копиться интерфейстные проблемы, о которых никто заранее не думал.
Например, добавляли фичу по одной, и интерфейс стал перегруженным. Разработчик отложил мелкую правку на потом и все забыли. На юзабилити-тесте увидели проблему, но исправить ее руки не дошли. Сюда же задачи, созданные на основе фидбэка от пользователей.
📍Все это — дизайн-долг. И чем дольше живет продукт, тем больше подобных задач появляется.
Просто копить задачи в одном списке — мало. Поэтому мы действуем по шагам:
0. Договариваемся, что будем делать дизайн долг
Пока не согласовали с командой, что задачи по дизайн-долгу будут попадать в спринт, смысла в остальном нет.
Поэтому нужно убедить разработчиков и руководителей, что эти проблемы влияют на деньги, пользовательский опыт и рупутацию продукта. На этом этапе согласуйте сколько задач вы будете брать в работу и как часто.
1. Собираем дизайн-долг
Весь потенциальный дизайн-долг надо фиксировать в тикеты — куда угодно, где у вас ставятся задачи. Главное, чтобы было легко найти: например, в Трекере, мы это делаем по тегу.
2. Приоритизируем задачи
Когда в списке десятки задач и, на первый взгляд, все важные, тяжело выделить что-то одно.
На этом этапе помогает приоритизация. Тема отдельного поста, если интересно про такое почитать — поставьте реакций. Кратко: придумал свою формулу по приоритизации задач.
3. Делаем задачи командой дизайна.
Тут, я думаю, все понятно.
4. Передаем в разработку
Последним пунктом важно регулярно передавать задачи из дизайн долга на реализацию в команду разработки, проводить дизайн-ревью.
Дизайн-долг не убрать разом — он будет всегда. Главное постепенно начать с ним работать, чтобы он не копился и стал частью процесса по улучшению продукта.