Долг UX: Как определять, расставлять приоритеты и решать.

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

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

Что такое долги UX?

Долгосрочные долги UX похожи на их технический аналог, известный как технический долг. Первоначально разработанный Уордом Каннингемом в 1992 году, технический долг означает дополнительные затраты времени и усилий, которые возникают в результате запуска более быстрых или простых технических решений вместо того, чтобы использовать наилучший подход. Это означает, что стоимость возврата и устранения проблем после запуска всегда выше, чем запуск идеальных решений в первую очередь (т.е. долг погашается ростовщическими процентами). Как и технический долг, долг UX часто возникает, когда дизайнеры и исследователи работают в сжатые сроки или с нереальными ограничениями проекта. Другие факторы, способствующие возникновению UX долга:

• Пропуск тестирования пользователями
• Игнорирование стандартов бренда и руководств по стилю
• Разработка комитетом
• Ложное виденье продукта
• Приобретение или слияние с другими продуктами
• Плохая связь или документация
• Недостаточное тестирование QA
• Устаревший код или отложенный рефакторинг

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

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

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

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

Несмотря на то, что слово «долг» для большинства людей является сложным, метафора не подразумевает, что долг UX следует избегать любой ценой. Особенно, если вы работаете в Agile, будут случаи, когда скорость выхода на рынок и давление датой выпуска, требуют альтернатив для экономии времени. Хотя определенные типы UX-долгов (например: проблемы с интеграцией, несогласованности и проблемы с сохранением простой концептуальной модели, которая объясняет и объединяет весь UX), более вероятны в Agile, любые решения, которые намеренно приводят к UX-долгам, должны быть обдуманы тщательно и коллективно. Подумайте о том, стоит ли быстрее выйти на рынок, рискуя негативно повлиять на восприятие пользователей и получить более высокие затраты на устранение проблем позже. Когда ответ «да», итоговый UX-долг должен отслеживаться, управляться и постепенно «выплачиваться» со временем, чтобы пользователи не заметили его и отказались не полностью от использования веб-сайта или приложения.

Выявление UX-долга

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

• Пользовательский интерфейс (кнопки, ссылки и визуальный стиль)
• Дизайн взаимодействий (перемещение со страницы на страницу, анимации и эффекты прокрутки)
• Копирование, контент и обмен сообщениями (ярлыки, заголовки и письменный текст)
• Информационная архитектура (структуры навигации и классификация контента)
• Элементы доступности (контрастность, индикаторы визуальной фокусировки, альтернативы тексту и т. д.)
• Последовательность «переходов» клиента
• Многоканальная целостность

Например, пресс-релиз на веб-сайте партнеров по связям с инвесторами Symantec содержит главный текст, у которого слишком низкая контрастность, чтобы считаться приемлемой. Хотя низкий контраст не является ошибкой, это пример UX-долга, который может негативно повлиять на пользователей с низким зрением или цветовой слепотой. В соответствии с рекомендациями WCAG, коэффициенты контрастности между цветами текста и фона должны быть от 4,5 до 1 для текста нормального размера. Коэффициент контрастности между цветом текста и цветом фона на этой странице составляет всего 3,2 к 1 и поэтому слишком мал, чтобы считаться приемлемым. Symantec должен был выбрать цвет главного текста, соответствующий стандартам доступности, и теперь должен помнить о том, чтобы вернуться и исправить эту проблему UX-долга.

Лучший способ выявить UX долг – часто получать реальную обратную связь с пользователями и различными способами. Хотя вам всегда следует проводить пользовательское тестирование перед выпуском функций Спринта , текущее тестирование также должно происходить не реже одного раза в месяц и сосредоточиться на ключевых потоках и реалистичных задачах, которые пользователи часто делают в/на вашем веб-сайте/приложении. Такой подход поможет вам понять общее состояние пользователей и выявить наиболее серьезные проблемы. Другие методологии обратной связи с пользователями, которые могут помочь вам найти UX-долгов, включают:

• Обследование сайтов
• Показатели CSAT или NPS
• Проблемы, связанные с обслуживанием клиентов

В дополнение к отзывам пользователей, выберите какое-то конкретное время время со всей командой разработчиков, для обзора общего состояния сайта или приложения. Завяжите дискуссию для остальной команды, чтобы выявить наперед любые элементы UX/Tech-долги, которые могут негативно повлиять на работу пользователя. PM (Product managment) также может выявить проблемы, связанным с долгом, которые могут найти руководство или другие заинтересованные стороны. Если возможно, делитесь тенденциями или паттернами аналитики во время обсуждения, чтобы команда могла решить всё вместе, нужно ли для выявления «долга» необходимо дальнейшее расследование.

Несоответствия в пользовательском интерфейсе можно считать UX-долгом, но не всегда. В пользовательском интерфейсе возможны незначительные расхождения, которые соответствуют правилам бренда и не создают проблем для пользователей. Например, во время теста A / B могут возникать некоторые временные проблемы UX, пока команда не поймет, какое изменение является оптимальным и должно ли оно быть добавлено в систему проектирования. Эти типы несоответствий не должны считаться долгом UX, поскольку изменения являются временными и преднамеренными. (Чтобы избежать создания задолженности UX в качестве побочного продукта теста A / B, команды должны обеспечить, чтобы выигрышные элементы были внедрены в систему проектирования с полной согласованностью и четкими стандартами для новых моделей или компонентов).

Пример информационной несогласованности в пользовательском интерфейсе, который считается UX-долгом, наблюдался на Amazon. На странице «Доставка-для-возвращения» отображались непоследовательные количества для возвращаемых элементов: пользователь хотел вернуть 4 пары штанов, но текст на странице читал «Возвращение 2-х пунктов» и сводная информация, указанная в промежуточном итоговом счете возврата для 3-х элементов. Эта противоречивая информация заставила пользователя запросить сумму возврата и вернуться на предыдущую страницу, чтобы дважды проверить, что суммарный предполагаемый возврат был верным. Несогласованность Amazon - это UX-долг и должна быть направлена на то, чтобы помочь пользователям плавно пройти через процесс возврата.

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

Отслеживание и определение приоритетов

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

• Добавление объектов UX-долгов непосредственно в бэклог
• Захват объектов UX-долгов в электронные таблицы, а затем добавление их в резерв проекта

Добавление элементов UX-долга в бэклог

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

«Мы отслеживаем наши объекты UX-долга, используя эпос в бэклоге. Во время прочёсывания бэклога мы просматриваем список объектов Tech/UX-долга, затем мы коллективно расставляем приоритеты и решаем, что делать в ближайшие две недели. Мы делаем это, прежде чем планируем новые функции, чтобы мы могли сбалансировать очистку с новыми функциями» 

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

Что улучшит работу продукта больше: новая функция или улучшение уже существующей функции? Довольно часто последний вариант является лучшим, поскольку функция, которую люди не могут использовать, также не может существовать. Таким образом, исправление чего-то, что не работает для пользователей, имеет тот же эффект, что и добавление новой функции с точки зрения того, что клиенты действительно используют. Таким образом, проблемы UX с существующими функциями могут и должны часто получать более высокий приоритет, чем новые функции. Более того, функции обычно реализуются в порядке ожидаемого эффекта, так что старая функция, вероятно, будет по своей сути более ценной, чем новая функция, если только старая функция может быть использована для работы на пользователя.

Организация и определение приоритетов в электронной таблице

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

• Описание проблемы с точки зрения пользователей (как это влияет на них?)
• Где в опыте это происходит (осознание, рассмотрение, конверсия)
• Частота возникновения (как часто это происходит?)
• Кто сообщил об этой проблеме? (пользователь, команда, заинтересованная сторона)
• Уровень UX и усилия по разработке, необходимые для решения проблемы (низкий, средний или высокий)

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

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

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

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

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

Решение UX-долга

«Уплата» UX-долга может показаться сложной, на первый взгляд, задачей и потребует времени, но есть несколько способов ее решения, которые при этом в целом улучшают ваши цифровые продукты. Один из подходов состоит в том, чтобы выделить определенное количество единиц истории для исправления UX-долга во время каждого Спринта или любого другого Спринта. Количество единиц истории может меняться со временем в зависимости от рабочей нагрузки команды, но постарайтесь устранить хотя бы один или два объекта UX-долга за спринт, желательно больше, если позволяет пропускная способность. Используйте легко понятные визуализации, данные, полученные в результате тестирования пользователей, и четкое объяснение того, что было сделано в каждом спринте, чтобы помочь руководству понять достигнутый прогресс и почему это важно.

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

Заключение

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