Не UI единым: как провести UX-ревью сложного IT-продукта и не утонуть в данных? Гайд от практика
Привет! Это Даша, проектировщик из Selectel. Сегодня хочу поделиться своим опытом проведения UX-аудита — неоднократно я приходила в новый продукт и передо мной вставала такая задача.
Я успела набить шишек, перерыть половину рунета и в итоге на практике получить ценный опыт.
Эта статья родилась из желания помочь читателям избежать ошибок, которые совершила я (например, с головой уйти в анализ размера кнопок вместо изучения основных пользовательских сценариев), и при этом поделиться инструментами, которые помогли мне провести UX-аудит, будучи новичком в сложном продукте. Кроме того, я собрала полезный шаблон в Miro для динамичной и наглядной презентации результатов аудита команде.
Все подробности — под катом.
Используйте навигацию, если не хотите читать текст полностью:
→ Что такое UX-аудит
→ Когда UX-аудит нужен, а когда нет
→ Шаг 1: Определите основные цели продукта, а также ожидаемый от него результат
→ Шаг 2: Проанализируйте данные о продукте и фиче
→ Шаг 3: Оцените поведение интерфейса
→ Шаг 4: Подготовьте отчет для команды
→ Ура, вы закончили! А что дальше?
Что такое UX-аудит
UX-аудит — оценка продукта или его отдельных фичей на предмет удовлетворения пользовательских потребностей и попадания в бизнес-цели.
Перед тем, как перейти к конкретным шагам аудита, расскажу о моем опыте.
Так сложилось, что несколько раз я приходила в уже «устоявшийся» на рынке сложный продукт. На практике это означало, что команда активно делала новые фичи, а владелец продукта в качестве первых задач давал провести UX-аудит текущих решений.
Учитывая, что каждый из продуктов был в специфических сферах (HR-консалтинг, телефония, IT-инфраструктура), задача для меня звучала примерно как: «Мы тут год назад построили мост, оцени, пожалуйста, насколько он надежен». И все бы ничего, вот только я ничего не знаю про мосты, кроме того, что в Петербурге их около 300 :)
И вот это основной вызов, с которым сталкивается проектировщик, придя в новый продукт — с одной стороны, появляется возможность «незамыленным» глазом провести оценку текущего состояния: выявить основные барьеры, которые сейчас не позволяют достичь каких-то бизнес или пользовательских целей в продукте. С другой — необходимо сделать это за короткий промежуток времени, разобравшись не будучи экспертом в основных пользовательских задачах и бизнес-ожиданиях от продукта.
Главная ловушка на старте — из-за недостатка знаний о сфере, продукте и основных пользовательских кейсах скатиться в оценку UI.
Важный дисклеймер! Это не значит, что оценивать UI не нужно. Проблемы в визуальной части действительно негативно влияют на пользовательский опыт (иногда настолько критично, что, например, пользователи, уже сложив много позиций в корзину, не могут оформить заказ и отдать бизнесу деньги). Однако обычно такого рода проблемы — верхушка айсберга.
И чтобы дойти до его основания и провести качественный UX-аудит, нужно это делать поэтапно:
- изучить бизнес-цели продукта и понять, насколько они закрываются теми фичами, которые уже есть в продукте;
- изучить потребности пользователей и проанализировать, насколько продукт помогает пользователю решить его задачи;
- оценить данные (количественные и качественные) о текущем поведении пользователей;
- проверить, насколько интерфейс предсказуемо ведет себя для пользователя (и вот тут уже спрятан кусочек для анализа UI).
В этом тексте вас ждет подробная инструкция по каждому шагу. А пока разберемся, в каких ситуациях нужен UX-аудит, а когда его можно не делать.
Когда UX-аудит нужен, а когда нет
UX-аудит будет полезен, если:
- Продукт уже устоялся и надо оценить его работоспособность, соответствие ожиданиям рынка и пользователей.
- Продукт уже устоялся настолько, что пора делать редизайн. Чтобы его сделать осмысленно, стоит провести «ревизию» продукта. Также в этом случае полезно «замерить» на метриках состояние до редизайна. Это потом поможет оценить эффективность ваших действий.
- Основные метрики, по которым вы отслеживали эффективность всего продукта и отдельных фичей, стали снижаться по показателям. Это тоже весомая причина, чтобы провести анализ текущей ситуации и выявить причины, по которым происходит падение показателей.
- Никаких метрик по отслеживанию удовлетворенности пользователей или бизнес-показателей нет. Соответственно, нет понимания, где продукт находится сейчас. В таком случае, самое время провести аудит. И даже больше — вместе с владельцем продукта определить основные бизнес-показатели, которые вы начнете отслеживать.
UX-аудит можно пропустить, если:
- Вы пришли в стартап, который ракетит на рынке, активно привлекает пользователей и инвестиции. Это важный момент роста, который нельзя упустить, чтобы дойти до стадии «снятия сливок» (вот здесь можно почитать про стадии развития продукта подробнее). В таком случае лучше сфокусироваться на развитии новых фич, которые помогут продукту укорениться на рынке, и сборе обратной связи от пользователей.
- В команде настроен регулярный процесс отслеживаний UX- и бизнес-метрик, которые показывают, что в продукте полный порядок. Тогда с чистой совестью можно окунаться в бэклог, уходить в исследование и проектирование новых фичей.
По этой схеме можно свериться, нужно ли вам в текущей ситуации проводить аудит.
Итак, вы обнаружили свой кейс в первом списке и уже заряжены проводить аудит.
Чтобы не скатиться в хаотичное изучение всего, везде и сразу, я разбила аудит на четыре понятных шага. Рекомендую их выполнять последовательно. Так вы не потеряете основной фокус с ценности продукта для пользователей и бизнеса, и при этом не упустите из виду UI-огрехи.
Четыре основных шага аудита:
- Определите основные цели и ожидаемые результаты продукта для пользователя и бизнеса.
- Изучите имеющуюся аналитику на предмет актуальности и достоверности. Спойлер: если кажется, что у вас нет аналитики, вам кажется.
- Проанализируйте основные состояния интерфейса (рабочее, пустое, ошибочное), или, при отсутствии выделенного времени, проведите более упрощенный анализ на основе UX-эвристик.
- Опишите в понятной форме результаты аудита и список улучшений.
Приготовьтесь к погружению — далее мы рассмотрим каждый шаг подробно и разберем конкретные примеры.
Шаг 1: Определите основные цели продукта, а также ожидаемый от него результат
Зачем это нужно?
Представим, что вы оказались в новом продукте. И вместе с его владельцем или тимлидом пришли к тому, что необходимо провести UX-аудит. Очевидно, что для вас этот продукт — новая книга: вы не знаете, о чем она. В этот момент возникает соблазн быстро книгу пролистать (как в книжном магазине, когда хочется из середины вычитать пару абзацев, чтобы понять, а что там интересного). Другими словами — «походить» по интерфейсу и «потрогать» ручками, как все работает. Или другой вариант — окунуться в документацию (при ее наличии и актуальности в команде).
Первый вариант дает только поверхностное знакомство с UI. Второй может запутать большим количеством информации.
Поэтому в начале аудита я рекомендую четко зафиксировать, какие у продукта основные цели: как для пользователя, так и для бизнеса.
Как это сделать?
Есть такое понятие, как UX Value Loop — это похожий на восьмерку концепт, который помогает осознать важные составляющие продукта. Он показывает, что если не удовлетворить каждую сторону, то продукт провалится.
Работа с пользователями
Чтобы разобраться в основных пользовательских задачах, проведите качественные исследования с реальными пользователями. Но если на это нет времени, изучите другие источники знаний:
- расспросите персональных менеджеров клиентов о потребностях,
- узнайте у технической поддержки какие эмоции и почему возникают у клиентов,
- выясните у менеджеров продаж, с какими возражениями они сталкиваются и какие фичи пользователи выделяют как желанные,
- изучите отзывы клиентов о продукте или проанализируйте тикеты, обращения клиентов.
Другой важный источник знаний — сам владелец продукта. Проведите с ним серию экспертных интервью, чтобы разобраться, как та или иная фича закрывает (или не закрывает) пользовательские задачи. Это самый короткий способ узнать самое важное о продукте.
Работа с целями бизнеса
Для изучения бизнес-целей также рекомендую поставить встречу с владельцем продукта или бизнес-аналитиком в команде. Во время встречи проверяйте, попадают ли названные цели в одну из категорий (если нет – конкретизируйте до тех пор, пока не попадет, в противном случае это будет не цель, а лишь видение):
- рост выручки и прибыли компании,
- удержание и возвращаемость клиента,
- снижение издержек.
Вот такой список пользовательских задач и бизнес-целей я составила вместе с владельцем продукта, который отвечает за ролевую модель с разными уровнями доступа в панели управления Selectel.
Важно: в рамках UX-аудита сосредоточьтесь на тех фичах, которые одновременно решают пользовательские задачи и закрывают бизнес-цели – именно они в долгосрочной перспективе обеспечивают успех продукта.
Шаг 2: Проанализируйте данные о продукте и фиче
Не поверите, но даже после сбора основной информации о пользовательских задачах и бизнес-целях, мы с вами все еще не идем трогать интерфейс и другие точки касания клиента с продуктом :)
Сейчас самое время, чтобы посмотреть на цифры, которые собирают системы веб-аналитики. Если таких нет, на этом этапе стоит просигнализировать команде, что нет важного источника данных о поведении пользователей, и завести задачку с высоким приоритетом в командном трекере.
Те, кто сейчас читает этот текст и понимает, что в команде нет подключенной веб-аналитики — не убегайте. Для вас у меня тоже есть идея, откуда достать цифры. Об этом рассказываю ниже.
На что смотреть, когда системы веб-аналитики работают
Вот какие данные я рекомендую собрать на этом этапе UX-аудита.
Конверсия в завершение сценария
Самый интересный показатель. У любого сценария есть стартовая точка — когда пользователь начинает решать свою задачу, и финальная — выполнение целевого действия. Между этими точками есть шаги, которые пользователь должен пройти. Конверсия позволяет оценить, сколько пользователей доходит до конца, совершая целевое действие, и посмотреть пути тех, кто все же не доходит до финиша. А после — сформулировать гипотезы, почему так происходит.
Время решения задачи
Можно изучать вместе с конверсией, можно отдельно. Само по себе время не говорит ни о чем, пока вы не начнете сравнивать его с временем, которое тратит пользователь до и после каких-либо изменений.
Совет: зафиксируйте эту метрику на этапе аудита, а после доработки сценариев оцените, как ваши действия повлияли на скорость прохождения пути. Чем быстрее пользователь решает задачу, тем лучше.
Поисковые запросы
Зафиксируйте, что пользователи ищут и не могут найти. Также определите объем самых популярных запросов. Этот показатель подсветит самые востребованные фичи и, возможно, подскажет основные проблемы в навигации.
Если же система не выдает список поисковых запросов, аналогичный можно составить, просмотрев скринкасты по разным страницам продукта — такая возможность есть в Яндекс Метрике и Posthog.
Сообщения об ошибках
Посмотрите, какие сообщения об ошибках наиболее популярны, где и когда пользователи их получают. Основные вопросы, на которые стоит здесь ответить: знаете ли вы причину возникновения ошибок? Насколько плохо то, что пользователь получает ту или иную ошибку? Насколько часто встречается эта ошибка?
Какие устройства наиболее популярны — десктопные или смартфоны?
А, может, планшеты? Как правило, эти данные открывают новые горизонты для команды и повод провести больше качественных исследований, чтобы больше узнать про контекст использования продукта. Например, настроить работу сервера со сложной конфигурацией явно проще с ноутбука, нежели с телефона по дороге на работу в метро.
DAU и MAU
- DAU — число уникальных пользователей, использовавших продукт в течение календарных суток.
- MAU — число уникальных пользователей, использовавших продукт в течение календарного месяца.
Чтобы лучше разобраться в метриках, советую к прочтению текст по ссылке.
Что делать, если подключенных систем веб-аналитики нет
Собрать разные количественные данные можно, обратившись за помощью к разработчикам. Они смогут их выгрузить из баз данных или логов активности. Для того, чтобы понять, какие именно данные вам нужны, я рекомендую синхронизироваться с продактом. Более полный список метрик, которые будут актуальны для вашего продукта, читайте в тексте по ссылке.
По возможности, лучше обращаться к разным источникам данных: и к системе веб-аналитики, и к выгрузкам из баз данных. Это позволит вам сравнить корректность данных, а также дополнить их.
В качестве примера приведу метрики, которые я собирала при аудите сценария «Добавление пользователя в систему в панели my.selectel.ru».
Шаг 3: Оцените поведение интерфейса
Переходим к одной из самых медитативных частей аудита: будем оценивать, насколько интерфейс попадает в представления пользователя о том, как должен работать продукт по методике эвристической оценки.
Эвристика — это рекомендация, правило или суждение эксперта, которое принято считать верным. Самые популярные эвристики в UX: Нильсена Нормана, Бена Шнейдермана, Вайншенка и Баркера, Иэн Коннелл.
Выполняя эвристическую оценку, вы изучаете интерфейс на предмет выполнения этих эвристик в интерфейсе.
Как не похоронить себя за пикселями, когда в продукте много фич
Каким бы большим и мощным ни был продукт, его всегда можно разбить на составляющие (фичи) и провести эвристическую оценку интерфейса. Прежде, чем перейти к этому этапу, важно сделать следующее:
- Сверьтесь со списком основных фичей продукта. Он должен был у вас появиться после прохождения шагов выше.
- Вместе с продактом выделите те, которые лучше всего перформят для бизнеса.
- Выберите среди них 3-5 самых востребованных для пользователей и проводите оценку этих фичей.
- Не забудьте про те фичи, в которых по результатам анализа ключевых метрик стало ясно, что там что-то «болеет» по цифрам. Возможно, вы сможете на этапе эвристического анализа поставить диагноз.
Почему именно эвристическая оценка? Я рекомендую использовать эту методику, поскольку она одновременно позволяет проверить:
- отвечает ли система требованиям пользователя: насколько качественно продуман UX,
- не упустить из виду эстетический аспект анализа: тот самый UI, до которого мы с вами дошло только на этом шаге.
Если пока звучит сложно, сейчас станет проще: рассмотрим, как это работает на примере двух эвристик (остальные вы найдете в шаблоне чуть дальше). За основу возьмем эвристики Нильсена Нормана (вы вольны выбрать эвристики того эксперта, к кому вы испытываете большею симпатию, но для меня это всегда будет Нильсен Норман).
Пояснения к эвристикам взяты из статьи-перевода описания эвристик по Нильсену Норману.
Такую оценку лучше проводить по каждой фиче отдельно. По каждой эвристике вы представляете в двоичной системе, выполняется ли она или нет: 0 или 1. В итоге у вас получится понятная оценка юзабилити по 10 балльной шкале с четким пониманием, какие проблемные места требует внимания дизайнера для доработки или редизайна.
Для удобства я сложила готовый шаблон в таблицу – копируйте себе и берите в работу.
Шаг 4: Подготовьте отчет для команды
Все шаги аудита мы с вами проходили не для галочки. Они были нужны, чтобы собрать данные, сделать выводы и далее вместе с командой наметить план действий.
К финальному этапу у нас собралось уже ну очееень много материала, который надо емко и коротко показать команде.
Самый оптимальный способ — собрать презентацию с выводами по каждому шагу. При этом я рекомендую показывать результаты не просто демонстрируя выводы в Power Point, а проводя демо на интерактивной доске.
Для того, чтобы вам было проще подготовить такое демо, я собрала шаблон доски в Miro. Там каждый участник команды сможет сразу оставлять комментарии по вашим выводам и фиксировать конкретные задачи, которые пойдут в работу.
На моей практике презентация отчета команде никогда не укладывалась в одну часовую встречу, поэтому рекомендую заложить на это серию встреч (в зависимости от объема вашего отчета).
Ура, вы закончили! А что дальше?
Чтобы ничего из вашего отчета с результатами UX-аудита не покрылось слоем пыли и не осталось в летописи работы команды, рекомендую сделать следующее:
- По всем доработкам, которые вы обсудили с командой, завести эпики в таск-трекере. На данном этапе более детальная декомпозиция не понадобится — к этому можно приступить в момент, когда на командном планировании вы определите, что скоро возьмете эпик в работу.
- Если эти доработки достаточно масштабы, вместе с продактом актуализируйте дорожную карту развития продукта (если в команде ее нет — заведите!).
- Если видите, что по мере дальнейшей работы команды эти доработки теряются из виду — напоминайте на командных встречах, что они важны и аргументируйте, почему их надо взять в работу.
Совет напоследок: есть вероятность, что в процессе аудита вы что-то упустите. Это нормально — особенно в тех случаях, когда вы приходите проводить оценку в устоявшийся продукт с большим легаси.
Общайтесь с коллегами, задавайте вопросы, гуглите информацию про сферу своего продукта, все наработки фиксируйте. И не теряйте фокус с самого главного — пользовательского опыта и бизнес-показателей, без которых не может существовать ни один продукт.