Диагностика UX-проблем по модели Джеймса Гарретта 🥼 💊

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

Вы уходите с этим флаконом и странным ощущением в животе (как в прямом, так и в переносном смысле). Конечно, лекарство может притупить боль, но действительно ли оно решит проблему? А что, если она совсем не временная? Или требует более глубокого исследования?

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

Другая крайность: вы обращаетесь к врачу из-за легкой сыпи, чтобы понять, откуда она взялась, и слышите в ответ: «Ну, мы можем ее удалить». Удалить? Нужно ли ее удалять? Это серьезное вмешательство! И когда вы приходите к нему в следующий раз, потому что никак не можете избавиться от насморка, он рекомендует тот же план лечения: «Давайте просто удалим эту часть вашего лица».

Могу поспорить, что вы больше не пойдете к этому врачу.

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

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

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

Почему мы по умолчанию обращаемся к инструментам, а не диагностике

Как дизайнеры, мы любим делать. Дайте нам проблему, и мы тут же откроем Figma и создадим прототип. Создавать что-то — это приятно. Это дает ощущение продуктивности. А ощущение продуктивности приносит нам удовольствие.

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

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

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

Модель Гарретта как инструмент диагностики

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

Каждый уровень имеет свои собственные симптомы, сигналы и инструменты. Давайте рассмотрим их подробнее:

Уровень стратегии

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

Симптомы

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

Спросите себя

• Соответствует ли ценность продукта рынку?
• Является ли наша модель ценообразования устойчивой?
• Изменился ли рынок?
• Какие данные у нас есть о потребностях пользователей и рынка?

Инструменты

• Jobs To Be Done
• Business Model Canvas (шаблон бизнес-модели)
• Value Proposition Canvas (шаблон ценностного предложения)

Если этот уровень не сформирован или лишен четкой понятной коммуникации, всё, что находится выше, обречено на провал. Точка. 

Уровень возможностей

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

Симптомы

• Неясные требования, которые постоянно меняются.
• Разработка дизайна до того, как вы поймете, что именно вы создаете.
• Добавление функций, не соответствующих целям пользователей или бизнеса.
• Заинтересованные стороны спрашивают «Можем ли мы добавить...», не вникая в последствия.
• Функции, которые не связаны между собой и не создают дополнительную ценность для пользователя.

Спросите себя

• Каковы границы этого опыта? Решаем ли мы правильные проблемы?
• Какие конкретные возможности должен иметь этот продукт, чтобы реализовать нашу стратегию?
• Что мы явным образом НЕ создаем и почему?
• Как эти функции соединяются для создания целостного опыта?

Инструменты

• Карта пути пользователя (CJM)
• Карта услуги (Service Blueprint)
• Схема объектно-ориентированного UX (OOUX)
• Карта пользовательских историй
• Конкурентный анализ

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

Уровень структуры

Здесь мы определяем, как пользователи перемещаются по интерфейсу. Это основа навигации, сценариев и логики продукта. Этот уровень охватывает как информационную архитектуру (как организованы контент и функции), так и дизайн взаимодействий (как пользователи перемещаются между этими организованными пространствами и внутри них).

Симптомы

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

Спросите себя

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

Инструменты

• Диаграммы информационной архитектуры, включая карты сайта и модели навигации.
• Моделирование контента и работа с таксономией.
• Wireflows, которые показывают как лейаут, так и сценарий.
• Потоки задач (Task Flows) и пользовательские потоки (User Flows).
• Потоки процессов (Process Flows) для сложных многоэтапных взаимодействий.

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

Уровень компоновки

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

Симптомы

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

Спросите себя

• Достаточно ли плавным получился пользовательский сценарий?
• Структурирован ли экран таким образом, чтобы обеспечивать эффективное выполнение задачи?
• Выделены ли наиболее важные действия и информация?
• Последовательно ли выглядят и ведут себя интерактивные элементы?
• Придерживаемся ли мы привычных шаблонов взаимодействия, которые соответствуют ожиданиям пользователей?
• Оптимизирован ли лейаут для контекста и устройства пользователя?

Инструменты

• Диаграммы пользовательских сценариев на основе карты услуги и CJM.
• Вайрфреймы и низкодетализированные прототипы.
• Эвристические и экспертные оценки.
• Библиотеки компонентов и дизайн-системы.
• Юзабилити-тесты, ориентированные на выполнение задач.
• Отслеживание кликов и анализ тепловых карт.
• A/B-тестирование вариаций лейаута.

Если сценарий имеет смысл, но пользователи сталкиваются с проблемами на отдельных экранах или в рамках отдельных взаимодействий, то вы имеете дело с проблемами компоновки. Цель этого уровня — сделать выстроенную ранее структуру удобной и эффективной. Люди должны легко проходить этапы сценария, не размышляя подолгу о том, как использовать ваш интерфейс. Это должно быть понятно интуитивно.

Уровень поверхности

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

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

Симптомы

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

Спросите себя

• Выглядит ли интерфейс профессионально, вызывает ли он доверие?
• Четко ли представлен наш бренд?
• Соответствует ли дизайн стандартам WCAG для визуальных элементов?
• Поддерживает ли визуальная иерархия функциональную иерархию?
• Вызывает ли дизайн правильную эмоциональную реакцию?
• Подходит ли эстетика для наших пользователей и контекста?

Инструменты

• Визуальные фреймворки, такие как PARC, принципы гештальта и теория цвета.
• Руководство по бренду и системы визуальной идентичности.
• Дизайн-системы и стайлгайды.
• Библиотеки иллюстраций и микроанимации.
• Аудит доступности визуальных элементов.
• Тестирование первого впечатления и исследования эстетики-юзабилити.

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

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

Некоторые практические примеры

Давайте рассмотрим несколько гипотетических сценариев и применим к ним соответствующие конкретным уровням диагностические вопросы:

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

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

• «Дизайнеры хотят переделать все приложение, потому что оно выглядит устаревшим». → Этот субъективный диагноз фокусируется на поверхностном уровне. Если данные показывают снижение вовлеченности, спросите себя, соответствует ли продуктовая стратегия потребностям рынка. Иногда «выглядит устаревшим» на самом деле означает «больше не отвечает потребностям». Не путайте ценность с недостатками брендинга, это разные уровни проблем, и они требуют разных решений.

• «Наш показатель завершения онбординга упал после того, как мы добавили новый шаг». → Команды часто спешат со структурными решениями: «Давайте оптимизируем этот сценарий!» Но, может, вы просите пользователей сделать что-то, что не соответствует их целям на данный момент (проблема возможностей), или этот шаг кажется бессмысленным, потому что не приносит им никакой ценности (проблема стратегии).

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

Заключение

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

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

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

Поскольку пользователи воспринимают продукт через поверхностный слой, для постановки диагноза требуется некоторое время и усилия. Пять уровней Гарретта — отличный инструмент, чтобы замедлиться, исследовать и назначить правильное лечение. Иногда это комплексное обновление стратегии. Иногда — простое изменение интерфейса. Магия заключается в том, чтобы понять разницу.