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

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

Схема процесса проектирования пользовательских интерфейсов > Концептуальное проектирование. UX-школа Артема Кузнецова.

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

Схема процесса проектирования пользовательских интерфейсов > Детальное проектирование. UX-школа Артема Кузнецова.

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

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

Схема процесса проектирования пользовательских интерфейсов > Сопровождение разработки. UX-школа Артема Кузнецова.

Вопросы пропускаем, они у нас были. Сопровождение разработки. Это этап, на котором мы консультируем разработчиков и оптимизируем макет. Вот консультация разработчиков — это как они будут спрашивать, как здесь поступить лучше, как здесь мы, как разработчики, концепции и этого макета должны им это все объяснять. Но, помимо всего прочего, здесь есть такой важный пункт — оптимизация макетов. То есть, возможно, во время разработки выяснится, это часто бывает, когда разработчики говорят, слушайте, мы вот это сделать не можем, зато можем сделать как-то по-другому. И они предлагают какое-то свое решение. А как нам узнать, насколько оно будет удобным для конечных пользователей? Для этого мы опять же можем провести небольшие интервью с пользователями и обсудить с ними эти возможные решения. 

Схема процесса проектирования пользовательских интерфейсов > Поддержка внедрения. UX-школа Артема Кузнецова.

Далее, поддержка внедрения. На этом этапе идет анализ обратной связи от пользователей и устранение недочетов. Опять же, здесь у нас присутствует, как правило, помимо анализа обратной связи, юзабилити-тестирование. Мы тестируем уже не макет, а готовый продукт. И во время этого юзабилити-тестирования, как правило, мы также проводим мини-интервью. Оно может быть совмещено с тестированием, проходить после тестирования. Тем не менее, этот метод также на этом этапе применяется. 

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

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

Сколько же гипотез может быть? Сколько гипотез мы можем проверить? В идеале мы бы хотели проверить все наши гипотезы.? И практика показывает, что у нас бывает их там и 15, и 30, и даже 40 бывает, которые хотят проверить разработчики, стейкхолдеры. Но мы ограничены рамками исследования. У нас всего 45-60 минут на интервью или 15-20 минут на анкету. И когда в гипотезе есть варианты, которые мы обсуждаем, из которых респондент может выбрать, то мы можем проверить за 30 секунд-2 минуты, что респондент в итоге выбирает. Если ответа нет и вопрос будет вообще открытый, то тогда может потребоваться и 5-10 минут, потому что люди будут просто обсуждать и рассказывать свое мнение. 

Таким образом, мы получаем по арифметике, по нашему опыту, что около 15-40 гипотез для проверки. Сейчас объясню, почему такой большой разброс. 15 – это если у нас больше открытых вопросов, 40 – это если у нас больше закрытых, из которых они просто выбирают. В любом случае, нам необходимо протестировать будет наш опросник перед исследованием, чтобы мы понимали, умещаемся мы в отведенное время или нет. 

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

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

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

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

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

Метод воронки для проведения интервью. UX-школа Артема Кузнецова

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

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

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

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

Ряд советов по тому, как фиксировать результаты интервью. Здесь понятно, что это… тут велосипед сложно придумать, это аудиозапись, видеозапись, заметки в блокноте, везде написано плюс таймер. Почему? Потому что очень важно, когда вы будете делать эти вещи, да, то есть, скажем так, пишите в блокноте, запоминайте в какой времени ставьте таймер буквально ставьте таймер да вам понадобится и запись аудио или видео и блокнот и таймер для того чтобы вы себе писали таймкод и в начале интервью поставили таймер включили и потом писали таймкод и что примерно там на 13 минуте интервью респондент говорил о том то и том то там была интересная мысль вы можете не успеть записать все это и мысли или какого-то интересного высказания, но отметить, где это было. Потом после интервью вы сможете быстро пересмотреть эту информацию, вернуться к ней и сделать какие-то более детальные заметки. 

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

Пример применения метода Кано. UX-школа Артема Кузнецова

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

Метод критического инцидента. Это тоже очень интересный метод. О нем говорит, упоминает не только Якоб Нильсон, но и другие эксперты в сфере юзабилити UX. Это очень интересный метод. Чем? Он проводится и в форме интервью, и в форме анкетирования может проводиться. Пользователям предлагается указать конкретные инциденты, то есть случаи какие-то, с которыми они столкнулись лично и которые оказали важное влияние на окончательный результат. Акцент делается на происшествиях, а не на каких-то просто расплывчатых мнениях, там что хорошо, что плохо. То есть выясняются конкретные факты, что помогло человеку решить задачу в системе, что наоборот, может быть, помешало. И потом на основе данных этих инцидентов, их анализа, их статистики, уже складывается понимание о том, где в системе присутствуют какие-то проблемные места, какие функции наоборот полезны и нужны. Это если кратко про это сказать. 

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

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

Увидимся на нашем полном занятии. Всем пока! Ну и сейчас кину ссылочку в чат, если кто-то захочет присоединиться к сегодняшнему занятию. Welcome. Если смотрите в записи, Anyway, что называется, все равно присоединяйтесь, найдите ссылочку и вы тоже получите результат и пользу для себя. Увидимся на занятии!