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


20.07.2019 Время чтения - 14 минут 74

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

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

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

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

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

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

Чтобы разрешить этот пример UX-долга, Symantec нужно выбрать более темный цвет главного текста, что приведет к более высокому коэффициенту контрастности для соответствия стандартам доступности
  • Показатели CSAT или NPS
  • Проблемы, связанные с обслуживанием клиентов

Пользователь на Amazon столкнулся с противоречивым, неправильным количеством товара при выполнении возврата. Это несоответствие заставило их усомниться в достоверности и точности Amazon. Этот тип вопроса считается долгом UX.

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

Читайте также: Советы и рекомендации по портфолио UX