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

Конспект материала UX-консультанта Джима Росса.

UX-исследователи предоставляют два типа информации: результаты исследования и рекомендации, считает Росс.

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

По отдельности они были бы не нужны: рекомендации без результатов исследования выглядят необоснованными, а результаты без рекомендаций — бесполезными.

Росс описал факторы, которые нужно учитывать при составлении рекомендаций:

• аудиторию;
• метод исследования;
• останетесь ли вы в проекте;
• будете ли вы UX-разработчиком или им станет кто-то другой.

Список вопросов, которые могут возникнуть у тех, кому вы презентуете результаты своей работы:

• Я верю этому исследованию? Подходит ли выбранный метод? Компетентен ли исследователь?
• Верю ли я результатам исследования? Действительно ли обозначенная проблема является проблемой?
• Насколько важно решить эту проблему?
• Помогут ли рекомендации? Есть ли лучшее решение?
• Насколько легко (или сложно) решить проблему? Сколько времени и денег для этого понадобится?
• Мы не можем сразу исправить все проблемы, которые выявил исследователь. Какие нужно исправить в первую очередь, а какие могут подождать?

Презентация результатов и рекомендаций должна ответить на все эти вопросы.

Автор отмечает, что на характер выводов и рекомендаций влияет метод исследования. Если вы провели юзабилити-тестирование или сделали экспертный обзор, то выводы будут конкретными. Если вы провели исследование пользователей, то выводы будут более глубокими и обобщёнными.

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

Он отмечает психологическое влияние таких выводов:

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

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

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

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

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

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

Росс называет качества эффективных рекомендаций. Они должны быть:

• понятными;
• краткими;
• в должной мере конкретными;
• правдоподобными;
• авторитетными;
• требующими конкретных действий;
• осуществимыми;
• гибкими;
• распределены по степени важности;
• удобными для просмотра.

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

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

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

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

Некоторые проблемы имеют очевидные решения, поэтому к ним подходит конкретная рекомендация.

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

Есть проблемы, которые можно решить разными способами, поэтому для них не имеет смысла давать конкретное решение.

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

Эти рекомендации достаточно конкретны. Не указывайте точную форму иконки, текст и цвета. Рекомендации содержат информацию о том, какие изменения важны, без указания точного дизайна.

Аудитория должна поверить, что рекомендации будут решать проблемы.

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

Для описания этой характеристики автор приводит случай из своей практики. В компании, где работал Росс, руководство задалось вопросом, следует ли использовать термин «рекомендация». Они считали, что «рекомендация» звучит как всего лишь предложение, а не авторитетное указание: «Сделайте это».

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

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

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

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

Росс утверждает, что сделать рекомендации осуществимыми — не значит максимально упростить их до самых лёгких и наименее дорогостоящих. Нужно дать и «идеальную» рекомендацию, и краткосрочное решение.

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

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

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

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

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

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

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

После презентации команда проекта должна понимать рекомендации.

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

Другой вариант — создание дополнительного документа рекомендаций в Excel или Word, где они будут перечислены в таблице. Росс предлагает разместить следующие колонки:

• номер рекомендации;
• краткое описание результатов исследования;
• приоритет рекомендации.

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

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

• Поняли ли сотрудники рекомендации?

• Рекомендации были убедительными или было много споров и альтернативных мнений?

• Рекомендации были реалистичными или некоторые из них невыполнимы, поэтому их не реализовали?

• Много ли изменений было в моих рекомендациях?

• Сколько из рекомендаций было в конечном итоге реализовано, были ли они реализованы правильно?