Pull to refresh
0
Собака Павлова
Интерфейсы рабочих мест

Вести с полей: кто и как применял качественные методы в UX Research для разработки IT-продуктов. Часть 1 из 6

Reading time14 min
Views15K
Все части статьи: 1 | 2 | 3 | 4 | 5 | 6

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

Спасибо прекрасному автору за симпатичную картинку.

Почему речь идет о зарубежных компаниях? Качественная методология там давно перестала быть экзотикой и вошла в арсенал IT-продуктологов. Изучение их опыта позволит лучше понять возможности и ограничения этих методов в сфере UX. Для этого мы провели собственное исследование.

Работу проводили в несколько этапов. Сначала отбирали зарубежные компании, специализирующиеся на разработке IT-продуктов. Понятно, что таких компаний на западном рынке немало. Мы не ставили цели выявить все или отобрать лишь самые известные. Зачем? Нам было интересней посмотреть, над какими проектами работают небольшие и средние компании. Хотя есть в выборке и крупные, и известные компании (например, Cooper или Blink).

Составили большой список и стали проверять компании на соответствие нашим критериям: внимательно изучали информацию на вкладке About и портфолио. Основных критериев было четыре.
  1. Это должна быть самостоятельная компания, выступающая в роли подрядчика. Мы исключили UX-отделы крупных компаний. Там, конечно, проводят исследования. И качественные методы в ходу, но это совсем другая история. И бюджеты другие.
  2. Компания должна оказывать услуги по разработке IT-продуктов. Не обязательно «полного цикла»: своих программистов в штате может не быть.
  3. Компания должна использовать качественную методологию (интервью, наблюдение, этнографию). Не обязательно, чтобы это были единственные методы в арсенале.
  4. На сайте компании должны быть кейсы. Вот здесь было больше всего проблем: некоторые компании подходили по трем первым критериям, но вместо кейсов на сайте были лишь логотипы клиентов. Логотипы — даже если их много — не позволяют понять суть работы.

Мы не оценивали уровень компетенции компаний: нам просто нужно было отобрать наиболее подходящие для нашей задачи — проанализировать опыт использования качественной методологии. В итоге мы отобрали 15 компаний:
  1. ReD Associates (Дания, США)
  2. Experientia (Швейцария, Италия, Сингапур, Великобритания, Китай, Тайвань)
  3. AnswerLab (США)
  4. Cooper (США)
  5. Spotless (Великобритания)
  6. U1 (Австралия)
  7. TecEd (США)
  8. Bowmast/Nick Bowmast (США)
  9. Head (Великобритания)
  10. The Understanding Group (США)
  11. Blink (США)
  12. Prime Motive (Австралия)
  13. Reading Room (Великобритания)
  14. CX Partners (Великобритания)
  15. RMA (Великобритания)

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

Проблем с кейсами было три.
  1. В описании кейса только общая информация. С какой конкретно проблемой пришел заказчик? Что сделали, чтобы ее решить? Непонятно. Сразу о результатах рассказывают и в общих чертах.
  2. Не описаны методы сбора данных о пользователях. Что скрывается за фразой «мы изучили пользователей» или «мы поговорили с пользователями»? Какой метод использовали: опрос, фокус-группу, наблюдение, интервью или вообще веб-аналитику? Нам важно было отобрать кейсы, где использовались именно качественные методы. Количественные методы нас не интересовали, хотя в некоторых случаях они могли дополнять качественную методологию.
  3. Непонятно, как использовались полученные данные. Например, как повлияло изучение рабочего дня врача на разработку приложения для сотрудников больницы? Лишь в немногих кейсах этому уделяли внимание.

И все же 26 кейсов мы отобрать сумели. Они различаются полнотой описания, и это отражено в тексте статьи. Не все компании смогли предложить яркую историю, где описано использование результатов аналитики. Где-то был достаточно сухой отчет. Однако все кейсы содержат реальные примеры использования качественной методологии при разработке IT-продуктов: сайта, мобильного приложения, профессионального интерфейса, онлайн-сервиса. Результаты работы были разными: рекомендации, стратегии развития, концепты, прототипы или уже готовые продукты. Нам было интересно все, ведь мы тоже беремся за очень разные проекты.

Несмотря на эти различия, первичный анализ отобранных кейсов сразу показал, что мы имеем дело с шестью жизненными ситуациями.
  1. Разработка IT-продукта для конкретной группы пользователей.
  2. Разработка общей платформы для нескольких групп пользователей.
  3. Переход на мобильную платформу.
  4. Разработка профессионального интерфейса.
  5. Выход с IT-продуктом на новый локальный рынок.
  6. Разработка нового сервиса.

Использование качественной методологии в этих ситуациях имело свои особенности: разные цели, выбор исследовательских методов и конечные результаты. Третий этап исследования заключался в анализе этих шести ситуаций и выявлении закономерностей в использовании качественной методологии для решения продуктовых задач. Мы сфокусировались на следующем.
  • Проблемах. С какой проблемой обратился заказчик? С какими трудностями столкнулась проектная команда?
  • Методах. Какие качественные методы выбрали? Как проводилось исследование?
  • Результатах. Какие данные о пользователях удалось получить? Какое применение нашли эти данные? Как они повлияли на разработку IT-продукта?

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

«Не все мы девятилетние девочки»: разработка продукта для конкретной группы пользователей


Большая часть IT-продуктов разрабатывается под потребности определенной группы пользователей, разработка для «среднестатистического человека» — редкий случай. Успех продукта для конкретного пользователя зависит от того, насколько точно определены его потребности, ожидания и боль. И насколько правильно это знание используется при создании продукта.

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

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

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

Кейс 1. Cooper: мобильное приложение Kurbo

Кейс 1. Cooper: мобильное приложение Kurbo


Компании Cooper понадобилось разработать мобильное приложение для мониторинга питания. Подобные приложения уже имелись в App Store и Google Play. Проблема была в том, что приложение предназначалось для детей с проблемами лишнего веса. Дети с его помощью должны самостоятельно следить за своим питанием. А значит, нужно сделать приложение понятным и увлекательным, иначе срок его жизни на мобильном устройстве ребенка будет недолгим. Понятно, что без изучения пользователей такое приложение не создать.

Компания провела так называемое in-person research — исследование, предполагающее общение лицом к лицу. Выяснилось, что люди, которые питаются правильно, предпочитают хорошо знакомые продукты. А ребенок не станет вникать, как именно мама приготовила курицу, — это утомительно даже для взрослого. Контроль питания надо было сделать простым и интересным и при этом — рассказать, а лучше показать, какая еда полезна, а какая — нет.

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

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


Кейс 2. Spotless: сайт для Disney

Кейс 2. Spotless: сайт для Disney


У компании Disney Channel UK есть сайт, где дети — в основном девочки 7–12 лет — могут посмотреть любимые шоу онлайн. Компания решила модернизировать этот сайт и добавить новые возможности, но для этого разработчикам не хватало информации о пользователях. Не так-то просто понять, чем живут маленькие девочки и как сайт вписывается в их жизнь. Для этого нужно изучить их поведение, привычки и интересы. Такой анализ позволил бы определить стратегию развития сайта. И Disney обратился за помощью к компании Spotless.

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

Дневниковое исследование позволило собрать необходимую контекстную информацию о каждом участнике будущих фокус-групп и интервью. В Spotless потрудились на славу: команда подготовила для детей удобные и интересные дневники — яркие, с картинками и цветными стикерами. Заполнение дневника было похоже на выполнение домашнего задания. Девочки вели дневники в течение 4–7 дней. Полученные данные с лихвой окупили затраты на разработку инструментария — теперь исследователи говорили с детьми на одном языке. Они знали, какие персонажи, шоу и мероприятия нравятся юным пользователям больше всего. Это очень помогло наладить коммуникацию на следующих этапах работы.

После дневникового исследования были организованы фокус-группы с разбивкой по возрастам — 7–8, 9–10 и 11–12 лет. Детей в группы набирали парами — оказавшись вместе, подружки чувствовали себя комфортнее. Модератор общался с детьми, занимался вместе с ними сортировкой карточек и оценкой дизайна с помощью наклеек-смайликов. Кроме того, дети выполняли задания с различных устройств (ноутбук, iPad, iPod Touch и iPhone), оценивая удобство сайта.

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

По итогам работы компания Spotless составила отчет для Disney. Он содержал информацию о навигации на сайте, маршрутах пользователей, рекламе, языке, иконках, дизайне и верстке, а также ценные данные о среде использования и поведении маленьких пользователей. Так как интервью и фокус-группы снимались на видео, заказчик получил видеоматериалы по ключевым темам исследования. Кроме того, отчет включал анализ достоинств и недостатков сайтов, которые дети посещали регулярно. Разработчики Disney Channel UK получили всю необходимую информацию о своих пользователях для развития сайта.


Кейс 3. Reading Room: сайт Victim Support You&Co

Кейс 3. Reading Room: сайт Victim Support You&Co


Команда Reading Room получила непростую задачу от Victim Support — создать сайт для детей и подростков, ставших жертвами преступления. Дети должны были получить необходимую поддержку и информацию (к примеру, о видах преступлений и уголовном правосудии). Цель создания ресурса понятна, но какая помощь нужна детям, столкнувшимся с преступлением? Как подать информацию? Как ее структурировать? Слишком ребяческий или покровительственный тон может попросту отпугнуть пользователей. Для ответов на эти вопросы требовалось провести исследование.

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

Результаты исследования ощутимо повлияли на структуру сайта и его содержание.
  • Анализ детского опыта позволил понять, что они могут обращаться к сайту на всех этапах уголовного процесса. И на каждом этапе они должны получить необходимую помощь. Сайт должен сразу выдавать нужную информацию, не заставляя проходить по длинной цепочке ссылок.
  • Обращение в суд — тяжелое испытание для ребенка. Чтобы помочь пользователям справиться с этим, на сайте был создан интерактивный зал суда.
  • Дети по-разному относятся к полиции. Нередко это отношение негативное. Поэтому все ссылки на полицию были убраны, а главная страница давала ясно понять, что ресурс не имеет отношения к полиции.
  • Дети часто стыдятся того, что с ними произошло. Порой после случившегося они замыкаются и уходят в себя. Команда Victim Support изучила опыт детей, которые уже прошли через подобное, написала сценарии и сняла по ним несколько видеороликов с участием молодых актеров. Этот процесс помог глубже осмыслить цели и задачи пользователей сайта (детей разных возрастов и их родителей).

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


* * *


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

Если говорить о методологии UX-исследований, то эти три кейса показывают, что использование качественных методов (интервью, наблюдения, дневниковые исследования) дает ценную информацию, которая помогает разработать качественный IT-продукт даже для особой группы пользователей. Команда приобретает необходимое знание и перестает блуждать в темноте. Снижается риск получить плохой продукт.

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

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

Кейс 4. TecEd: сайт Ford Vehicles

Кейс 4. TecEd: сайт Ford Vehicles


Рекламному агентству J. Walter Thompson понадобилось обновить сайт компании Ford. Чтобы выполнить эту работу, нужно было понять, как люди принимают решение о покупке автомобиля. В агентстве считали, что качественное обновление сайта невозможно без этой информации. И все бы хорошо, но на изучение пользователей отводился лишь месяц, а бюджет был сильно ограничен. Цифр не показывают, но поверим на слово. С этой задачей сотрудники агентства обратились в TecEd: получить более глубокие знания о покупателях автомобилей, чем дают веб-аналитика и опросы. Таков был запрос заказчика. И это в кратчайшие сроки и с ограниченными средствами.

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

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

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


* * *


И это все?! Провели исследование, а результаты такие скромные? Ждали революцию? Никакой революции, просто удобный для людей сайт под конкретную задачу. Использование качественной методологии при разработке продукта для конкретной группы пользователей не всегда дает ошеломляющие результаты, которые позволяют сделать прорыв. Более того, само использование качественной методологии не уникальная фишка — это часть рабочей рутины при производстве качественного IT-продукта. Результаты этой работы могут показаться банальными, но они приносят реальную пользу людям. Давайте рассмотрим еще один кейс.

Кейс 5. The Understanding Group: сайт Smart Beauty Guide

Кейс 5. The Understanding Group: сайт Smart Beauty Guide


У Американского общества эстетической пластической хирургии (American Society for Aesthetic Plastic Surgery) было два сайта для пациентов, где освещались самые разные вопросы — от инъекций до сложных операций. Однако существующие сайты не вполне удовлетворяли потребности пользователей. Обществу был нужен новый сайт, который учитывает интересы разных групп пользователей и обеспечивает более качественный пользовательский опыт. Для решения этой задачи обратились к The Understanding Group.

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

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

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


* * *


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

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


Все части статьи: 1 | 2 | 3 | 4 | 5 | 6
Tags:
Hubs:
Total votes 13: ↑12 and ↓1+11
Comments0

Articles

Information

Website
www.pavlova.cc
Registered
Founded
Employees
11–30 employees
Location
Россия