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

В ожидании UX-Марафона #27, посвящённого вопросам UX-стратегии, продолжаем знакомство со статьёй Сэма Айронса Experience debt — what it is, how to measure it, and how to pay it down о том, как решают проблему дизайн-долга в компании Atlassian, глобальном разработчике программного обеспечения. В первой части мы рассмотрели, как появляется дизайн-долг. Сегодня разберёмся, как его измерить, предотвратить и погасить.

***

Разработчики Atlassian опираются в своей работе на принцип DevOps you build it, you run it: кто создаёт продукт, тот его и обслуживает. Обслуживание кода означает его поддержку и устранение технического долга. Команды разработчиков закладывают техническое обслуживание в план работы и включают это время в свои рабочие показатели. Например, команды проектировщиков Atlassian тратят на эти цели около 25% своего времени.

Аналогичный подход мы стремимся использовать и в UX-дизайне. Недостаточно уметь хорошо проектировать пользовательский опыт, нужно также брать на себя поддержку проектов после запуска. Необходимо улучшать работу с дизайн-долгом и отлаживать процессы таким образом, чтобы этот долг вовремя погашался.

В Atlassian мы рассматриваем две разновидности дизайн-долга:

Алекс Омейер из DZone обсуждает измерение технического долга исходя из количества багов, а также качества и связности кода. По примеру разработчиков мы можем подобрать эквивалентные понятия для измерения UX-долга. Так, дизайнеры могут выявлять легко устранимые UI/UX-баги, а также анализировать совокупный пользовательский опыт. Дизайн-отделы, кроме того, могут оценивать цельность пользовательского опыта внутри всей линейки продуктов.

UI-баги (paper cuts) обычно легче всего выявить. Они не мешают потребителям достигать своих целей. Однако, они могут резать глаз и подчеркивать несоответствия между разными частями потока. Например, неправильный отступ, прыгающие по экрану при загрузке элементы интерфейса, опечатки и прочие визуальные косяки. UI-баги можно выявить с помощью автоматизированного тестирования.

UX-баги мешают пользователям решать свои задачи с помощью наших продуктов. Обычно UX-баги – это несоответствия между задуманным дизайном и и его воплощением на практике. Например, проблемы с сообщениями об ошибках и их обработкой, стандартные «пустые экраны», битые ссылки и многое другое.

Опытные дизайн-команды стараются выявить UI/UX-баги до того, как продукт попадёт к потребителям. Однако, даже после автоматизированного тестирования вы всё равно можете зарелизить продукт с UI- и UX-багами. К счастью, работы по исправлению багов можно внести в бэклоги команды.

Сегодня потребители программного обеспечения рассматривают error-free программное обеспечение как как минимальное обязательное условие для принятия решения о его покупке. Поэтому исправление UI/UX-багов в уже выпущенном продукте в итоге ведёт к снижению прибыли. Чтобы добиться измеримых результатов в работе с дизайн-долгом, придётся копнуть немного глубже.

Совокупный UX — это совокупность каждого потока как части пути пользователя. Вы можете рассматривать совокупный UX, исходя из трёх аспектов вашего дизайна: сложности пути пользователя, связанности (не путать со связностью) пользовательского опыта и концептуального моделирования.

Под сложностью пользовательского пути понимается обычно количество независимых сценариев, которые клиенты могут выбирать, чтобы выполнить свою задачу. Либо, если говорить более детально, количество шагов или действий, необходимых для достижения успеха в каждом сценарии. Чем больше шагов нужно предпринять, тем сложнее путь пользователя. Сложность пользовательского пути отрицательно сказывается на удовлетворенности клиентов вашим продуктом. Очень сложные пути могут помешать пользователям выполнить свою задачу.

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

Связанный UX увеличивает когнитивную нагрузку на ваших пользователей. Они могут отвлекаться, нервничать или даже разочароваться и отказаться от использования вашего продукта. Связанный UX делает задачи более сложными, чем ожидают ваши пользователи.

Концептуальное моделирование описывает количество понятий, присутствующих в пользовательском опыте. Сложные концептуальные модели негативно влияют на восприятие. Пользователям необходимо сопоставить концепции вашего продукта со своей реальной жизнью, со стоящей перед ними задачей. Если ваши концептуальные модели не соответствуют их представлениям или слишком сложны для понимания, то они с меньшей вероятностью найдут ценность в вашем продукте.

Цельный UX имеет прямое отношение к согласованности (консистентности) всех путей пользователя, из которых состоят ваши продукты. Цельные системы повторяют одни и те же узнаваемые компоненты во всех своих продуктах. Они используют стандартные дизайн-системы.

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

Операционные улучшения должны быть превентивной мерой. Следуя принципам дизайн-мышления и лучшим современным практикам, можно выявлять и устранять проблемы до запуска.

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

Чтобы оценить наши продукты на более высоком уровне, мы проводим регулярные сквозные тестирования. Мы анализируем ключевые пути пользователя с помощью оценочных карт UX и внедряем процессы обеспечения качества там, где это необходимо. Кроме того, мы проводим регулярные сеансы анализа клиентских отзывов.

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

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

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

Проще говоря: когда вы производите успешное программное обеспечение, которое поставляется оперативно и часто, дизайн-долг неизбежен.

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

1. Предотвращайте накопление долга, который является как безрассудным, так и преднамеренным, иначе он помешает «выплатить» ваш разумный долг.

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

3. Поскольку дизайн-долг неизбежен, постарайтесь, чтобы ваши непогашенные долги были только непреднамеренными разумными долгами. Это хороший долг. Он возникает в результате адаптации к естественной энтропии ваших продуктов и рынка.

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

Желательно выработать привычку возвращаться к преднамеренным компромиссам, сделанным при быстром запуске, и оперативно дорабатывать успешные MVP, чтобы сделать их максимально соответствующими потребностям потребителя.

Я адаптировал несколько советов SCRUM-экспертов, которые помогут вам справиться с дизайн-долгом. Возможно, вы уже встречали эти советы раньше, но они стоят того, чтобы повторить их ещё раз.

Сделайте дизайн-долг прозрачным. Пусть размер вашего дизайн-долга будет вам известен. Регулярно проверяйте пользовательский опыт своего продукта, чтобы понять, как он накапливает долги. Используйте сквозное тестирование, тайных покупателей и другие виды исследований. Пригласите на тестирование всю продуктовую команду и заинтересованные стороны. Продуктовая команда должна иметь представление о размере и характеристиках дизайн-долга, прежде чем инвестировать в его погашение.

Используйте метрики для отслеживания дизайн-долга. Есть много способов отследить дизайн-долг. Как минимум, подсчитайте количество UX-проблем в ваших продуктах, и регулярно проверяйте этот показатель всей продуктовой командой.

Зафиксируйте обязательства по регулярному погашению долга. Как и в случае с техническим долгом, пусть ваши продуктовые команды обязуются закрывать дизайн-долг в рамках каждого спринта. В среде разработчиков стало нормой тратить 15-20% от общего времени разработки на работу с техническим долгом. Дизайнерам стоит взять на вооружение аналогичную практику.

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

Включите долг опыта в определение «сделано». Принимая компромиссное решение при запуске MVP, постарайтесь включить план устранения дизайн-долга в число критериев готовности продукта. Не называйте продукт готовым, пока у команды не будет плана, как погасить дизайн-долг, связанный с релизом.

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

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

Я добавлю еще один совет от команд по работе с клиентами Atlassian:

Говорите на одном языке со своей командой. Использование языка ваших разработчиков и команд поддержки помогает всем играть в одну и ту же игру. Выражайте проблемы проектирования в терминах, которые наши разработчики признают и понимают. Это значительно поможет согласовать ваши действия.

А теперь идите и заплатите свой долг. :)

***

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