Как проводить UX-исследования без бюджета и что нужно знать о дизайн-процессе

Меня зовут Данил Приходько, я 5 лет работаю на позиции UI/UX Designer. Сейчас сотрудничаю с сервисной IT-компанией Yalantis. Когда только начинал карьеру, в статьях я старался найти алгоритмы решения задач, не понимая, что это практически невозможно. Я написал эту статью с рекомендациями и краткой выжимкой того, что знаю, для таких, как я в прошлом. Материал будет полезен начинающим дизайнерам, которые стали задумываться о том, как они могут реально помочь пользователям.

Как проводить UX-исследования без бюджета

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

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

• How might we questions — вопросы, которые помогут сформулировать точные задачи для решения внутри компании. Например: «Как сделать оплату на сайте безопасной?». Видя эти вопросы, проще сформулировать конкретную задачу для команды разработки.
• Customer journey maps — пути пользователей по достижению целей.
• Pains and gains — болевые точки и точки-мотиваторы.
• Данные юзабилити-тестов.
• Отзывы пользователей.
• Анализ конкурентов и другое.

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

А теперь поговорим об особенностях украинского IT-бизнеса и подходах. Существуют два основных типа компаний:

• Продукт — есть внутренний заказчик или инвестор и чаще всего развивается один продукт или группа продуктов. Например, украинская компания MacPaw занимается созданием собственных приложений на Mac.
• Аутсорс — много разных заказчиков, которые имеют разные потребности. Это и разработка приложения такси «Убер-лайк», и создание сложной системы для логистических компаний.

В аутсорсе бюджеты заказчиков очень разные. Это могут быть дочерние компании компаний из топ-100 и начинающие стартапы. А исследования — ещё одна статья бюджета, этим этапом могут пренебречь, мотивируя тем, что «мы и так знаем проблемы пользователей». Ещё один камень преткновения в том, что исследование может показать бесполезность стартапа, что невыгодно компании-разработчику.
Работая в аутсорсе, я понимаю эти проблемы, но считаю, что без исследования невозможно построить качественный и нужный продукт. Если компания не располагает бюджетами или возможностями для создания отдельной команды исследователей, нужно проводить их своими силами.

О дизайн-процессе

В начале карьеры я не понимал, почему в каждой второй статье вставляют странный дабл-даймонд и говорят о каких-то фреймворках и Human centered design. По прошествии нескольких лет понимаю, что мой дизайн-процесс интуитивно построен как раз таки на этом framework, и я следую принципам Human centered design. Для таких, как я в прошлом, хочу предоставить расшифровку этого графика и показать, где же находятся исследования, а где сам дизайн.

Первый алмаз — стадия исследования и синтеза вопросов и задач

Вы можете увидеть слова diverging и converging, к ним ещё должно добавляться слово «фаза». Эти словосочетания трудно перевести, но примерно они означают следующее:

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

Converging phase — в этой фазе у нас стоит Define, и мы работаем с результатами исследования. На этом этапе формируем результаты исследования, находим инсайты (неожиданное о мотивациях, пожеланиях и болях потребителей в конкретной теме). И формируем How-might-we вопросы. Они помогают понять, что можно сделать или решить в заданной сфере действий.

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

Возникает вопрос, как устроить работу так, чтобы не тратить много денег и времени, но всё же провести исследование?

Для начала ответим на вопрос «Зачем нужно исследование?»

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

Самые частые «отмазки» дизайнеров от исследований:

• Не хватает денег.
• Не хватает времени.
• Просто не умею.
• Сложно найти данные.

Этот список для каждого индивидуален, но каждый хоть раз говорил такое.

Какие методы исследований можно назвать простыми и использовать постоянно

Интервью с бизнесом

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

Самые распространенные вопросы для интервью с бизнесом:

• Цель бизнеса. Для чего нужно исследование, что бизнес хочет получить от исследования?
• Что изменится, когда цель будет достигнута?
• Чего не хватает, чтобы добиться цели сейчас?
• Есть ли полезные знания уже сейчас?
• Какие страхи и риски?
• Какая структура бизнеса, какие процессы существуют?
• С кем нужно поговорить для поиска новых знаний?

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

Эвристическая оценка

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

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

Шаги, как сделать эвристическую оценку:

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

Анализ конкурентов

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

Можно долго говорить о том, что именно стоит анализировать. В разных источниках можете увидеть разные подходы, начиная от оценок стратегии продукта, простого S.W.O.T. анализа, заканчивая подробными разборами каждого экрана. Хочу поделиться максимально простым и действенным шаблоном, который подходит для оценки интерфейса приложения или сайта. Должен заметить, что он больше подойдет для сравнения прямых конкурентов. Для непрямых процессов будет немного отличаться.

Процесс анализа конкурентов:

• Сделать список конкурентов.
• Отметить основные сведения о конкуренте. Важно внести в документ все ссылки, пароли и логины, чтобы потом было удобно вернуться к приложению или сайту. Замечу, что для регистрации лучше не использовать корпоративные или личные данные. Цифровую безопасность никто не отменял.
• Определить, какие параметры будем анализировать.
• Пройтись по определенному флоу на сайте/приложении конкурента, попутно занося в таблицу все нужные данные.
• Можно делать скриншоты или дополнительные пометки.
  
  

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

Общение с поддержкой

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

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

Здесь тоже нет чёткого алгоритма проведения такого исследования, но попробую дать краткие рекомендации:

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

Что дальше делать с данными? Лучше всего подтвердить их с помощью других методов исследований, например глубинных интервью с пользователями. Это поможет не только знать о проблеме, а и узнать о её контексте. Что точно не стоит делать, так это сразу бросаться переделывать всё только потому, что по какой-то проблеме вы имеете большое количество обращений. Таким образом можно всё усугубить. Без контекста не раскроете проблему до конца.

Ещё хочется отметить, что, даже не имея доступа к конкретной команде саппорта, можно найти различные отзывы о продукте. Просто просмотрев отзывы в App Store и Google Play, сможете найти много интересных данных. Кстати, отзывы в магазинах можно смотреть и о приложениях конкурентов, чтобы не повторять их ошибок ;)

Общение с Sales team

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

Проведение такого исследования пошагово похоже на общение с командой саппорта:

• Определите, что именно хотите узнать.
• Поговорите с Sales team.
• Зафиксируйте данные.
• Приоритизируйте проблемы.

Команда продаж сможет дать вам данные, которые будут отражать не те проблемы, с которыми пользователи сталкиваются в процессе использования продукта, а те проблемы, которые пользователи решают, выбирая этот продукт. На основе этих знаний в дальнейшем возможно использовать фреймворк Jobs to be done.

Глубинные интервью

Как показала практика, непростой, но самый действенный способ. Куратор курса, который проходил, сказал: «Если у вас мало времени для ресёрча, выбирайте этот инструмент». Не буду подробно описывать, как проводить интервью, так как этот процесс достаточно сложный, но безумно интересный. И он не соответствует идее статьи. Но выделю несколько важных моментов.

Глубинное интервью — разговор с человеком в формате 1 на 1, длительностью 45–90 минут. В процессе необходимо задавать вопросы, которые подталкивают к длинным ответам. Глубинное интервью должно склонять пользователя рассказать историю о своём опыте. Главное задавать правильные вопросы:

• Плохой вопрос: «Ты часто заказываешь доставку продуктов на дом?»
• Хороший: «Расскажи о своём последнем заказе продуктов на дом»

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

Зачем проводить глубинные интервью? Вы сможете узнать истории людей, которые используют продукт. Получить контекст, которого так не хватает количественным данным. Вы узнаете не только, какая проблема возникла у пользователя, но и почему она возникла, при каких обстоятельствах, что он чувствовал, что делал. Согласитесь, мало кто пишет о таком в поддержу. Глубинное интервью даёт понимание поведенческих паттернов, помогает понять мотивацию пользователей. После проведения интервью вы получите информацию, которую можно интерпретировать по-разному: создать CJM, сделать карты эмпатий или points of view, а можно сделать всё вместе.

Вместо вывода

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