{"id":13812,"url":"\/distributions\/13812\/click?bit=1&hash=7aad8372ebaeed8b9f0411b6538b74104d083797cee812ade3ece5f97be0c878","title":"\u0427\u0435\u043a-\u043b\u0438\u0441\u0442 \u0434\u043b\u044f \u0431\u0438\u0437\u043d\u0435\u0441\u0430: \u043d\u0443\u0436\u043d\u044b \u043b\u0438 \u0432\u0430\u043c API?","buttonText":"\u041f\u0440\u043e\u0432\u0435\u0440\u0438\u0442\u044c","imageUuid":"f6c199c9-f72d-52bc-a539-75fc9e2f6f21","isPaidAndBannersEnabled":false}

Дизайн-долг – что это такое, как его измерить и как погасить

С дизайн-долгом (в английском языке обычно используется термин experience debt) рано или поздно сталкивается в своей практике, вероятно, каждый специалист по пользовательскому опыту. Юрий Ветров, куратор UX-Марафона #27, посвящённого вопросам разработки и реализации UX-стратегии, определяет дизайн-долг как «намеренно или неумышленно накопленные проблемы с юзабилити, решение которых откладывается до будущих версий».

По рекомендации Юрия Ветрова хотим предложить вашему вниманию перевод статьи Сэма Айронса, контент-дизайнера в компании Atlassian – разработчике программного обеспечения с мировым именем. Автор анализирует разные типы дизайн-долга и рассказывает, как с ним работают в Atlassian.

***

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

Звучит знакомо? То, что вы испытываете, естественно. Ваша команда сделала определённые вложения в пользовательский опыт, чтобы понять, насколько они удачны. Это нормально. Но вы в долгу перед пользователями. И пришло время этот долг оплатить.

В Atlassian мы много говорим о качестве дизайна и должном уровне скрупулёзности при разработке тех или иных решений. Мы пытаемся найти баланс между быстрым запуском новых идей и тщательной проработкой базовых функций.

Тем не менее, в процессе работы мы неизбежно накапливаем технический и дизайн-долг. Отчасти это происходит из-за проблем, с которыми мы сталкиваемся, когда масштабируем нашу команду и наши продукты. Кроме того, дизайн-долг возникает, когда мы осваиваем что-то новое или реагируем на меняющиеся требования отрасли.

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

Итак, вот что в Atlassian думают о дизайн-долге. Вы сильно удивитесь, но мы не считаем его чем-то однозначно плохим.

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

Здесь мы можем опираться на опыт, накопленный идейными лидерами в сфере разработки программного обеспечения. Они разработали фреймворки для оценки различных аспектов технического долга. Глядя на эти фреймворки, легко заметить, что программные приложения накапливают дизайн-долг сходным образом.

Стив МакКоннел, автор книги Code Complete, различал умышленный, преднамеренный (deliberate) и непреднамеренный (inadvertent) технический долг. Мартин Фаулер, подаривший миру концепцию рефакторинга, расширил эту классификацию, включив в нее вопрос о том, был ли долг разумным (prudent) или безрассудным (reckless).

Фаулер изобразил аспекты технического долга в виде схемы, состоящей из четырёх секторов. Я адаптировал эту схему для классификации дизайн-долга:

Разумный и преднамеренный. По мнению Фаулера, разумный умышленный долг обеспечивает бизнесу быструю прибыль. Команда принимает осознанное решение запустить продукт как можно раньше, если считает, что выгода от этого решения существенно перекроет расходы, связанные с устранением дизайн-долга на последующих этапах. Нетрудно узнать в этом подходе концепцию минимально жизнеспособного продукта (MVP), когда команда идет на компромисс в вопросах долгосрочной перспективы, чтобы быстрее зарелизить продукт. При этом разработчики заранее намечают вехи для доработок в ходе последующих итераций.

Безрассудный и преднамеренный. Безрассудный и преднамеренный дизайн-долг – очень распространённое явление. В этом случае команда работает «быстро и грязно», сознательно игнорируя общепринятые подходы к проектированию. Хакатоны, инновационные спринты, community development – эти практики зачастую порождают продукт со множеством мелких недочётов. Фаулер предупреждает, что в итоге это приводит к сокрушительным «процентным платежам» или очень долгой выплате «основного долга». Подобный подход заставляет команду увеличивать дизайн-долг и не даёт определить реальную ценность выбранного решения.

Безрассудный и непреднамеренный дизайн-долг возникает из-за некомпетентности и отсутствия опыта. Команда «влезает в долги», не понимая этого и не осознавая последствий. С этим видом дизайн-долга нередко сталкиваются компании, находящиеся в стадии быстрого роста. Даже имея самые лучшие намерения, они не всегда в состоянии контролировать работу своих команд. Так быть не должно, но чем крупнее компания, тем больше риск, что именно так всё и произойдет.

Вы можете подумать, что разумного и непреднамеренного дизайн-долга не бывает, но Фаулер уверен, что «он неизбежен для команд, члены которых являются отличными дизайнерами». Это долг, который накапливается по мере существования продукта, а также в результате меняющихся требований рынка. Команды проделали хорошую работу, но, оглядываясь назад, «они осознают, каким следовало сделать дизайн». К сожалению, это один из самых сложных для погашения видов дизайн-долга. Его устранение может потребовать редизайна значительной части найденных ранее решений.

***

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

0
4 комментария
Natalja

Хорошо было бы и иллюстрацию for sake of consistency перевести на русский. В остальном спасибо, интересно!

Ответить
Развернуть ветку
UX-марафон
Автор

Сделали)

Ответить
Развернуть ветку
Евгения Потемкина

Кажется, что в схеме допущена ошибка. В оригинальной статье Безрассудный находится слева. Поэтому подход «делаем быстро, ничему не учимся» не может относиться к Разумному.

Ответить
Развернуть ветку
UX-марафон
Автор

Разумеется, спасибо! Торопились заменить англоязычную схему на русифицированную, пока доступно редактирование публикации, и вот\
Исправили.

Ответить
Развернуть ветку
Читать все 4 комментария
null