Сэм Айронс написал о дизайн-долге — дизайнерском аналоге технического долга: как классифицировать, измерить и погасить.

— Это накопленные проблемы с дизайном, решение которых отложили на потом;
— Варианты разумного дизайн-долга: а) Преднамеренный: команда понимает, что дизайн не очень, но решает его реализовать и планирует доработки на следующие итерации; б) Непреднамеренный: команда реализует хороший дизайн, но со временем он перестаёт быть таковым, так как меняются обстоятельства;
— Безрассудный преднамеренный дизайн-долг отличается от разумного тем, что команда делает «быстро и грязно», не оценивая трудозатраты на доработки и не планируя их (хакатоны, инновационные спринты);
— Безрассудный непреднамеренный дизайн-долг появляется из-за некомпетентности и отсутствия опыта;
— Кто создаёт продукт, тот и должен его обслуживать, в том числе устранять дизайн-долг;
— Время на обслуживание надо закладывать в план. В Atlassian на это уходит четверть рабочего времени;
— Можно выявлять отдельные баги в UI (неправильный отступ, опечатка) или UX (проблема с сообщением об ошибке, стандартное пустое состояние);
— Можно искать способы: а) Снизить сложность сценария, уменьшив количество ответвлений или пользовательских действий, необходимых для его прохождения; б) Уменьшить количество отдельных сценариев, которые надо последовательно пройти в продукте для достижения цели; в) Упростить концептуальную модель, сократив количество сущностей и связей между ними;
— Появление дизайн-долга можно предотвращать, внедряя лучшие практики вроде проведения исследований, поиска нескольких решений, вовлечения клиентов в процесс, сквозного тестирования существующих продуктов, анализа клиентских отзывов и так далее;
— Возвращайтесь к компромиссным решениям и планируйте их доработки. Принимая такие решения, старайтесь сразу включать доработки в план;
— Сделайте дизайн-долг прозрачным: ведите бэклог, измеряйте его размер;
— Зафиксируйте обязательства по регулярному погашению долга;
— Стандартизируйте процедуры выявления и погашения долга (Брейден Ковиц упоминал день исправления UI-багов).

#design_debt

Алисия Суска написала о дизайн-долге.

— Долг UX-дизайна характеризуется несогласованностью при взаимодействии с продуктом, более сложным внедрением новых функций. Это самый распространённый и важный тип дизайн-долга. Погашать его надо в первую очередь, так как такой продукт хуже привлекает новых и удерживает старых клиентов;
— Операционный долг — невыстроенные процессы или недоработки в рамках текущих процессов. Например, отсутствие дизайн-системы (когда она необходима), устаревшие макеты, отличающиеся от реализации, хаос в слоях, стилях и компонентах. Он замедляет скорость работы дизайнеров и разработчиков;
— Визуальный долг — непоследовательность в визуальной части продукта. Если этим пренебрегать, продукт будет выглядеть менее профессиональным и надёжным, и доверие к нему может снизиться;
— Они возникают из-за: 1) Отсутствия доработки после внедрения первой версии новой функциональности; 2) Ограниченного бюджета и срока, что влияет на полноту дизайн-процесса; 3) Технического долга, когда на дизайн влияют ограничения текущей инфраструктуры; 4) Отсутствия лидеров, которые могли бы управлять уровнем дизайн-долга, обучая команду, выбивая нужные ресурсы, формируя единое видение и правильные процессы; 5) Отсутствия инвестиций в решения, которые позволяют масштабировать продукт;
— Чем больше и старше компания, тем больше у неё дизайн-долг. Влияет на это и количество продуктов, и особенности в процессе принятия решений. Но у таких компаний больше ресурсов для погашения дизайн-долга, если это будет в приоритете.

In English. Смотрите также статью Сэма Айронса о дизайн-долге. #design_debt

Илья Безделев написал, что делать с дизайн-долгом (papercuts).

— Дизайн-долг — места в интерфейсе, где что-то получилось криво по незнанию или неумению или где срезали углы, чтобы сделать быстрее;
— По отдельности проблемы вроде лишнего шага или немного кривой валидации формы не смертельны, как порез бумагой;
— Но если нанести слишком много порезов, может случиться «death by a thousand papercuts» — продукт перестанет приносить пользователям радость;
— В каждом цикле планирования выделяйте время на исправление мелких недочётов;
— Их можно закидывать в планы с низким приоритетом как бонусные задачи. Сделал большое дело, можно заняться мелочью;
— В командах с полноценными онколл-ротациями у разработчиков может быть свободное время онколла, когда не надо тушить пожары. Они могут заниматься papercuts;
— Хакатон-фиксатон — на неделю отложить работу над фичами и заняться фиксом дизайн-долга.

#design_debt