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

Как это обычно происходит? Покажу на примере последнего запроса. Пишет мне потенциальный клиент в Телеграм:

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

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

Объясняю в переписке, что всё очень индивидуально и предлагаю время созвона. Моя задача — организовать часовой разговор, во время которого я познакомлюсь с человеком и проектом, а также успею провести экспресс-аудит. Это бесплатно и всегда интересно.

Первый созвон: сбор данных и экспресс-аудит

Созваниваемся (в любом удобном месте, где есть видеосвязь и возможность продемонстрировать экран) — и я узнаю, что речь идёт о небольшом калифорнийском сервисе: подготовка к экзаменам на получение сертификата медсестры. Платный продукт с набором уроков и тестовых заданий. Авторы обещают, что, если усвоить весь материал и пройти тестирование хотя бы на 90% — то на реальном экзамене точно всё получится.

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

— Сколько стоит продукт?

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

— Откуда посетители узнают об этом продукте?

Получив ответ, сразу пойму, какой информацией и опытом пользователи будут обладать в момент, когда попадут на лендинг (сайт с рассказом о продукте), ведущий к регистрации.

Я задаю вопросы между делом, как бы невзначай, но они все выверенные. Мне нужно построить приземлённое представление о пользователях, о том, в каких условиях они пользуются интерфейсом, что у них в головах. От момента, когда увидели первую рекламу о продукте, до момента, когда получают на email письмо с поздравлением с успешным прохождением тестового экзамена.

Вроде как сегодня это называется CX (customer experience). Когда исследуется не только пользовательский путь по интерфейсам, но и вне них. Я сам никогда не отделял одно от другого. И UX, и CX, и ещё куча вещей — всё это часть моей профессии проектировщика интерфейсов.

В результате разговора понимаю, что путь пользователя состоит из нескольких этапов:

• Формирование потребности (кому и в какой момент понадобится получать сертификат медсестры);

• Неудачная попытка получить сертификат своими силами (либо же человек сразу принимает решение сначала где-то дополнительно подготовиться — а уже потом идти сдавать экзамен);

• Знакомство с рекламой или результатом поискового запроса;

• Знакомство с информацией на лендинге, принятие решения;

• Регистрация и аутентификация в продукте;

• Использование продукта (аудит именно этой части от меня изначально хотели получить);

• Успешное или неуспешное получение сертификата (задача решена — и это окно возможностей, когда может сработать сарафанное радио).

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

Во время разговора выясняю детали не только про пользователей, но и про бизнес.

— Где тут деньги? Я правильно понимаю, что это классический инфопродукт с платным доступом? Подготовка к конкретному экзамену?

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

— На чём сделан проект?

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

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

Я учёл это и работал в рамках ограничений. А чем больше ограничений — тем меньше свободы выбора. И это, во-первых, упрощает мою работу, а, во-вторых, уменьшает шанс на ошибку.

И вот по результатам разговора я знаю:

• Что нужно бизнесу

• Что нужно пользователям

• Какие есть технические ограничения

При этом ни одного из этих вопросов я не задавал напрямую.

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

В конце беседы я сказал примерно следующее:

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

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

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

Подготовка коммерческого предложения

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

Разработчикам всё равно пришлось бы что-то делать: с моей помощью или без неё. И со мной больше шансов на то, что результат работы понравится финальному клиенту (тем более что мы предварительно показываем ему прототип и согласуем его).

Прикидываю, сколько ресурсов мне понадобится, чтобы пробежаться по всем необходимым интерфейсам — и скидываю в мессенджер такой текст:

— 70к рублей, неделя, на выходе документ и небольшой прототип.

Разумеется, предварительно я показал примеры документов, которые готовил для других. Создание прототипа — особенность конкретно этого проекта: разработчикам он поможет внести правки в интерфейс, опираясь не на замечания и рекомендации, а на конкретные проработанные экраны от проектировщика. Так что КП в виде строчки текста клиенту было понятно.

А ещё на следующий день я узнал, что у меня отвалился огромный проект и высвободилось много времени — и отправил вдогонку ещё одно сообщение:

— Добрый день. Если к понедельнику примете положительное решение, скину стоимость до 50к рублей.

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

После этого произошёл короткий, но показательный диалог. Клиент написал:

— Понял. Сколько страниц будет входить в аудит и прототип? Только внутренняя часть, что мы с вами смотрели, или лендинг тоже? Там, наверное, прототип не нужен, но если можно будет какой-то общий фидбек получить и по лендингу, это будет отлично.

На что я ответил:

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

Спойлер: прототип получился на девять экранов, а документ — на двенадцать страниц. И то, и другое — на английском языке.

Аудит: подготовка и проведение

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

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

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

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

Главное — не делать аудит ради аудита.

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

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

• Заполнить регистрационные данные, войти в личный кабинет;

• Разобраться, с чего начать обучение, куда двигаться, что делать;

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

• Пройти финальный экзамен, ознакомиться с результатами и рекомендациями.

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

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

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

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

А вот как выглядело заключение:

А вот скриншот ещё одной странички, уже из другого аудита. Там меня программист попросил взглянуть на производственный календарь, который он сделал для своих нужд:

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

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

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

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

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

Я уже показал скриншоты с самыми важными частями документа: с выводами. Но основное его наполнение — это именно перечень замечаний и рекомендации по их исправлениям от экрана к экрану. Взгляните.

Интерактивный прототип

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

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

Вся работа (и аудит, и прототип) заняла около недели. На переговоры ушло не больше пяти часов.

Заключение

Итак, весь процесс по шагам:

• Бесплатная часовая встреча и экспресс-аудит

  • Узнать о проекте и пользователях

  • Узнать о разработке и разработчиках

  • Узнать о бизнесе

• Подготовка КП

• Подготовка к аудиту

  • Составить перечень пользователей

  • Их информационных ожиданий

  • Функциональных требований к интерфейсу

  • Зафиксировать, на каких устройствах будет аудит

  • Зафиксировать цели и задачи интерфейсов (отдельно для разных групп пользователей и отдельно для бизнеса)

• Сам аудит

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

  • Фиксировать места, на которых я спотыкался в течение этих маршрутов

  • Фиксировать сопутствующие менее важные недочёты

  • Пройтись по всем выявленным недочётам и сопроводить их рекомендациями по исправлениям

  • Выделить среди десятков недочётов один-три самых важных для бизнеса

  • Подготовить заключение

• Сделать КП на перепроектирование, если в этом есть необходимость

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

Главный принцип: не навреди

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

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

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

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