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

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

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

***

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

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

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

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

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

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

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

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

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

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

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

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

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

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

***

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