Содержание
Прим. перев.: В рамках нашего блога на Хабре мы решили начать публикацию серии переводов материалов, подготовленных создателями британского госпортала Gov UK. Команда Gov UK знаменита тем, что очень подробно описывает весь ход своей работы – поэтому ее материалы могут быть полезны с практической точки зрения (разумеется, не только для создания масштабных госсервисов), ведь все, о чем пишут создатели проекта, было реализовано на практике. Мы решили начать серию переводов с блока, посвященного гибким методологиям проектирования, и его важной части – создания так называемого user-centered design.
Изучайте ваших пользователей на каждом этапе развития проекта. Делайте это непрерывно в ходе каждого этапа – исследование пользователей – не то, что происходит только в начале и по завершении какой-либо стадии работы.
Если вы будете исследовать свою аудиторию непрерывно, это позволит вам:
- Концентрироваться в первую очередь на потребностях пользователя;
- Помогать команде проектировать именно те продукты, которые в наибольшей степени отвечают потребностям пользователя;
- Помогать команде разрабатывать продукты итеративно, с учетом пользовательского фидбека.
Дизайнеры и исследователи в равной степени важны
Каждая команда должна включать в себя дизайнера и «исследователя», работающих сообща и активно интересующихся проектированием и поиском пользовательских инсайтов. Речь не идет о том, чтобы исследователь «тестировал» работу дизайнера – это означает, что они должны работать вместе и тем самым:
- делиться всеми знаниями, полученными от пользователей так, чтобы любое решение, принятое в отношении продукта, было основано на выводах, сделанных по результатам изучения реальных пользователей;
- силами исследователя обеспечивать команду большим количеством информации и отзывами пользователей, собираемыми на регулярной основе – это поможет команде работать итеративно, приоритезировать задачи на каждой итерации и создавать максимально качественный продукт;
- непрерывно проводить эксперименты, которые смогут показать, обеспечивают ли выбранные дизайн-принципы создание понятного и привлекательного для пользователей продукта.
Убедитесь, что в вашем коллективе есть человек, ответственный за исследования, который постоянно находится в контакте с командой. Этот человек может заниматься и другими задачами (работать дизайнером, копирайтером и т.п.), но должен нести ответственность за проведение мероприятий в рамках исследования пользователей каждые 2 недели.
Проведение исследований в ходе итеративных работ по проектированию
Не работайте над проектированием продукта без получения фидбека от конечных пользователей дольше 2 недель. Каждая двухнедельная итерация будет включать в себя три стадии:
- разработку
- оценку
- изучение и получение новых знаний [о пользователях]
1. Разработка
Используйте open source-фреймворки [создатели портала Gov UK для нужд команд, работающих над проектами похожего типа, рекомендуют собственный репозиторий GDS], поскольку:
- Так вы сможете достаточно быстро пограммировать прототипы дизайн-концептов;
- Работающий прототип позволит вам получить от пользователей больше инсайтов по сравнению с бумажной версией.
Учитывайте, что вы будете проектировать и разрабатывать множество прототипов для тестирования, и большая часть из них пойдет в утиль. Это дает команде свободу исследовать сразу несколько различных концепций и получать лучшее понимание того, что будет оптимальным для конечного пользователя. Выделяйте на подобные эксперименты достаточно времени, особенно на ранних этапах жизни проекта.
[Прим. перев.: мы решили узнать, насколько тяжело создать в команде культуру, в рамках которой сотрудники будут адекватно воспринимать необходимость создания множества прототипов, подавляющее большинство из которых не пойдет в финальную работу, у профессионалов, которые сталкивались с подобными задачами на практике.]
Комментирует egorushkin (Сергей Егорушкин, интернет-предприниматель):
Мне понравилась фраза однажды: «Сотрудник должен уметь улыбаться до того, как вы его наймете». Мне кажется это из этой же серии. Ломать отношение не благодарное дело, я всегда предпочитал нанимать «своих» по духу людей.
Комментирует Hryusha (Платон Днепровский, руководитель UIDG):
Тут вопрос — из-за чего создается большое количество прототипов, не пошедших в работу. Если это из-за постоянных изменений требований или желания заказчика (внешнего или внутреннего) «поиграться шрифтами» — это, безусловно, снизит мотивацию.
Если все эти прототипы — последовательное движение к улучшению системы (создали — обсудили/потестили — доработали), то наоборот, все будут видеть результат этого движения, и будет только интереснее.
Люди – не идиоты, и достаточно быстро понимают бессмысленность работы. Общий совет — все должны понимать, ради чего делается та или иная работа. Если она осмысленна и ведет к улучшениям — то всё Ок.
На этих стадиях существования проекта прототипы, скорее всего, будут выглядеть незавершенными, а их дизайн потребует дальнейшей доработки. Придерживайтесь правила тестировать прототипы каждые 2 недели вместо того, чтобы пытаться довести до завершения работу над дизайном или создавать внешне «законченный» продукт.
Старайтесь, чтобы работа над каждым прототипом завершалась по меньшей мере за сутки до начала тестирования, так как это:
- Позволяет выделить время на незначительные модификации и доработку;
- Сокращает риск технических сбоев во время проведения исследования.
2. Оценка
Есть множество способов провести «эксперименты», которые помогут вам ответить на вопросы о вашем продукте, его дизайне и конечных пользователях. Ваш исследователь поможет выбрать наилучшие методы для ответа на каждый из этих вопросов. С его помощью вы, вероятно, придете к использованию большого количества различных техник в рамках работы над проектом.
Но, каким бы ни был ваш проект, не забывайте тестировать его на конечных пользователях каждые две недели.
[Прим. перев.: подобные тесты особенно важны в том числе потому, что нередко по их результатам команда приходит к противоречивым, на первый взгляд, выводам. Например, казалось бы, более симпатичный, интересный (по мнению команды) дизайн оказывался на практике менее привлекателен для пользователей.]
Комментирует Hryusha (Платон Днепровский, руководитель UIDG):
Очень часто такое происходит. Я даже сформулировал для себя мысль, что я считаю команду/проектировщика по-настоящему профессионалом, если он готов создавать интерфейсы, которые ему лично не нравятся, но эффективны для ЦА. Иначе всё это – вкусовщина. Другое дело, что собственный вкус и опыт могут помочь в быстром поиске или оценке решений.
Соответственно, ответ: всегда выбираем более эффективный/рабочий вариант, а не самый симпатичный.
Комментирует egorushkin (Сергей Егорушкин, интернет-предприниматель):
С симпатичным новым дизайном уже многие получали падение продаж. Первый фактор – непривычно, нужно время на адаптацию. Второй – у ресурса уже есть целая теория и, если коротко, то дизайн должен попадать в эмоциональный фон пользователя. Резко и радикально менять дизайн в лучшую сторону так же плохо, как и резко и радикально его ухудшать.
Просто россияне в своем отношении к дизайну и юзабилити несколько менее эмоциональны, чем, например, европейцы, поэтому в России хорошо продают «средние» по оформлению сайты.
2.1 Тестирование с привлечением пользователей раз в две недели
[в терминологии разработчиков Gov UK «Testing Tuesday» – «вторничные тесты»]
В рамках этих сессий вы сможете:
- Привлечь людей к взаимодействию с интерфейсом, над которым вы работаете (юзабилити-тестирование);
- Исследовать все конкретные вопросы, динформацию по которым вы хотели бы получить, используя более детальные интервью (личное интервью, которое может дать глубокое понимание потребностей и поведения пользователя).
Проводите «исследовательские» сессии с привлечением пользователей каждые 2 недели в один и тот же день. Проводя такое тестирование в заранее определенные даты, через регулярные временные промежутки, вы обеспечите для вашей команды возможность заранее высвобождать время для наблюдения за сессией.
[Прим. перев.: мы решили поинтересоваться, используются ли подобные практики в менее масштабных проектах, и как они видоизменяются в зависимости от объема/вида задач.]
Комментирует Hryusha (Платон Днепровский, руководитель UIDG):
Пока мы (как внешнее агентство) совсем не всегда сопровождаем продукт в течение его жизненного цикла, или хотя бы его заметной части. Чаще это работа над одним релизом. В этом случае — тестируем 1-2 раза: либо перед выпуском, либо перед и потом спустя некоторое время (если нужны навыки от пользователей).
В тех проектах, где мы живём с сервисом долго, частота теста должна определяться частотой изменений. Зачем тупо тестить одно и то же? Но если проект большой — то тестируются разные сценарии, и тут уж частота зависит от возможностей и планов, хоть каждый день. Но скорее — это именно запланированные 2-4-недельные активности, к которым ты готовишь нужные функции и планы их тестирования.
Постарайтесь запланировать на этот день порядка 5 личных интервью, каждое длительностью 1 час (привлеките к мероприятию еще одного «запасного» пользователя на случай, если кто-то опоздает или не будет соответствовать требованиям к потенциальному участнику теста).
Проводите сессии либо:
- В вашем собственной офисе;
- В исследовательской лаборатории (при необходимости ее можно снять).
Начните решать вопросы по бронированию помещения и привлечению участников тестирования на начальных этапах жизни проекта с учетом большого количества подобных сессий в рамках создания альфа- и бета-версии продукта.
Перед сессией
Чтобы подготовиться к сессии, вам необходимо:
- Определить вопросы исследования: что вы планируете узнать по результатам раунда тестирования?
- Сформировать гипотезы относительно вашего дизайна, например: изменение текста на кнопке будет стимулировать людей более внимательно читать определенный материал.
- Определить, что будет свидетельствовать о подтверждении/опровержении гипотезы, например: вы считаете, что гипотеза верна, поскольку время на чтение материала увеличилось.
- Выделить характеристики пользователей, с привлечением которых вы хотите провести тестирование по следующим параметрам: возраст, местонахождение, соответствие заданию, иные факторы.
- Начать отбор кандидатов как минимум за неделю до тестирования (подразделение GDS – Government Digital Service – секретариата кабинета министров Великобритании рекомендует заниматься поиском кандидатов через специализированные рекрутинговые агентства).
- Подготовить руководство по ведению интервью, в котором будет описано, как должно проводится общение с потенциальным пользователем и какие результаты должны быть получены в ходе беседы.
- Подготовить соглашение, позволяющее вам вести видеозапись сессии.
- Разослать распорядок дня всем членам команды и настоятельно порекомендовать им присутствовать на сессиях.
- Обеспечить стриминг видео с места проведения тестирования в режиме реального времени через такие сервисы, как, например, GoToMeeting, чтобы те члены команды, которые не смогут лично присутствовать на сессии, могли наблюдать за ходом процесса.
Перед сессиями подготовьте прототипы и убедитесь в том, что:
- Их можно показывать пользователям;
- Они полностью готовы к тестированию;
- К ним можно получить доступ и их можно использовать из помещения, в котором проводится исследование (выставлены необходимые настройки систем ограничения доступа, разрешение экрана компьютера позволяет работать с прототипом, для работы используются совместимые браузеры).
Во время сессии
В процессе проведения каждой сессии тестирования с привлечением пользователя:
- Убедитесь в том, что сессия записывается на видео.
- Убедитесь в том, что видео с сессии доступно в режиме реального времени для внешних наблюдателей (членов команды).
- Постоянно помните об исследуемых гипотезах, чтобы не упустить важных тем при общении с пользователем.
- Используйте листочки post-it с клейким краем, чтобы фиксировать наблюдения во время сессии:
- Лучше всего для этого использовать желтые листки, которые хорошо держатся на вертикальных поверхностях;
- Фиксируйте каждое наблюдение на отдельном листке;
- Пишите маркером заглавными буквами (так будет легче потом читать записи, сделанные в спешке);
- Если вы не уверены в том, насколько важно наблюдение, все равно запишите его.
- Подготовьте письменный транскрипт сессии (или в процессе сессии, или после нее).
После дня тестирования необходимо выделить время на анализ прежде, чем принимать решения по изменению прототипа. Стадия анализа детально раскрыта ниже.
2.2 Партизанские исследования
Вы можете использовать время между двумя сессиями формального тестирования для проведения партизанских тестов и получения фидбека по улучшенным вариантам дизайна напрямую от потенциальных пользователей.
Партизанское тестирование, как правило, состоит в следующем: вы берете ваш прототип в кофейню или другое публичное место и ищете волонтеров, которые смогут дать вам быстрый отзыв. Партизанское тестирование не всегда позволяет задействовать вашу целевую аудиторию, но может обеспечить вас быстрым ревю в перерывах между более формальными сессиями тестирования прототипа.
2.3 Другие методы исследования
Существует множество других методов, которые вы можете использовать, чтобы дополнить ваше качественное исследование в формате интервью, и которые помогут найти ответ на ряд конкретных вопросов или подтвердить/опровергнуть выводы, сделанные на основании основных тестов, на более широкой аудитории. Список подобных техник, а также указания о том, как и когда их лучше применять, находится здесь.
3. Получение новых знаний
Теперь пришло время выяснить, чему можно научиться по результатам тестирования с привлечением пользователей и последующего исследования. Лучше всего использовать накопленную информацию вам поможет:
- Анализ данных;
- Обмен результатами анализа;
- Общение.
3.1 Анализ данных
Важно правильно инструктировать команду относительно действий, которые будут предприняты после тестирования, поскольку в процессе исследования вы пронаблюдаете множество людей и их подчас совершенно разные реакции на ваш прототип.
Хотя детальный анализ сессий занимает достаточно много времени, осуществив его, вы:
- Получите четкое представление о том, чему вы научились;
- Узнаете, какие выводы нужно сделать относительно текущего прототипа;
- Будете уверены в том, что важные наблюдения не были утрачены.
Сортировка по сродству
Чтобы провести ее правильно, вам необходимо:
- Собрать все заметки, сделанные на самоклеящихся листках во время сессий тестирования прототипа, и приклеить их на стену.
- Сгруппировать наблюдения по темам.
- Сделать вывод: определить некое утверждение, которое объединяет в себе все наблюдения одной группы, и выписать его на отдельный листочек над группой.
- Попытаться связать выводы с гипотезами и решить, достаточно ли у вас информации, чтобы сделать утверждение об истинности/ложности гипотезы.
- Далее гипотезу необходимо подвергнуть последующему количественному/качественному тестированию.
На этом шаге вы нацеливаетесь на создание полного списка инсайтов (это могут быть и результаты непосредственно наблюдений, и выводы по ним), поэтому не пытайтесь сразу же приступить к проектированию решений. Процесс анализа должен занять несколько часов.
Работайте с любым членом команды, который наблюдал процесс тестирования прототипа с привлечением пользователей, чтобы проанализировать наблюдения, поскольку это поможет вам:
- Выявить все общие принципы для наблюдений;
- Найти подтверждение тому, что наблюдала команда в процессе тестов;
- Сформировать консенсус относительно полученных выводов.
Действия
Решите, что вы будете делать относительно каждого полученного вывода (и будете ли вообще). А когда вы найдете подтверждение/опровержение гипотезы, убедитесь, что оно задокументировано на видео, и команде о нем известно.
Если полученные выводы требуют дальнейших действий, определите, что требуется для их превращения в следующую итерацию проектирования продукта. Выписывайте эти действия на оранжевые самоклеящиеся листочки и прикрепляйте на стену рядом с выводами.
Расстановка приоритетов
Когда вы определились с тем, какие действия нужно предпринять, используйте метод расстановки приоритетов (такой как, например, кумулятивное голосование), чтобы решить, как вы распределите усилия в рамках следующей итерации.
3.2 Обмен результатами анализа
Поместите информацию о выводах, сделанных по результатам тестирования, и действиях, которые необходимо предпринять, там, где команда проекта сможет получить доступ к этой информации, поскольку велика вероятность, что вы будете возвращаться к полученным данным, чтобы:
- Вспомнить, к каким идеям вы пришли;
- Проследить, как конкретная тема или опция развивается в ходе итеративного проектирования прототипа.
Вы можете задокументировать результаты ваших исследований для того, чтобы другие могли получить к ним доступ различными способами, в частности, вы можете:
- Создать документ с правом коллективного доступа к нему;
- Начать вести блог;
- Создать т.н. story wall (с помощью сервисов вроде Trello);
- Каталогизировать ваше исследование.
Полезно также сохранять записи о том, что именно тестировалось с привлечением пользователей: например, если вы создали не бумажный, а «рабочий» прототип, для каждой итерации сохраняйте отдельную папку в репозитории. Полезным может оказаться и сохранение скриншотов прототипа.
Специалисты из GDS хотят создать специальный формат для обмена выводами исследований между правительственными проектами. Пока GDS делает все возможное для создания такого формата, храните свои выводы в доступном для обмена информацией виде, так, чтобы ими можно было поделиться и изучить их в будущем. По возможности выводы должны быть выражены максимально ясно, чтобы для их понимания не требовалось дополнительное истолкование.
Вносите информацию обо всех действиях в story wall, так, чтобы вся команда видела, кто над чем работает.
Видео
Используйте видео для демонстрации выводов исследований и храните видеозаписи с сессий в безопасности – в идеале там, где их смогут найти и просмотреть члены команды. Если для хранения видео вы используйте публичный сервис (вроде Vimeo), убедитесь, что ваши записи достаточно хорошо защищены.
3.3 Общение
Вам необходимо обсуждать проект и прогресс по работе над ним с окружающими. Это можно делать с помощью:
- Демонстрации проекта/презентации регулярных обновлений;
- Постоянной публикации обновлений дизайна проекта;
- Ретроспекции.
Демонстрация проекта
Группа проектировщиков и исследователей пользователей должна поступать точно так же, как и, непосредственно, разработчики, то есть презентовать изменения по проекту по результатам каждой итерации. Это позволит убедиться в том, что у всей команды есть понимание того, что:
- Исследования и проектирование дизайна не стоят на месте;
- По результатам исследования были сделаны выводы, с которыми необходимо ознакомиться;
- По результатам исследования предпринимаются действия по изменению дизайна проекта.
В рамках таких презентаций члены команды получают возможность узнать все важные моменты, которые они могли упустить, не попав на сессии тестирования прототипа, а также могут задать вопросы. В зависимости от того, как работает команда, вы можете встроить свою презентацию в общий отчет или презентовать результаты своей работы отдельно.
Учитывайте интересы и более отдаленных стейкхолдеров
Помимо вашей непосредственной команды по проекту могут существовать и другие люди, заинтересованные в результатах вашей работы. Чтобы начать активное общение и/или работу вместе с ними, вы можете:
- Пригласть их на демонстрацию вашего проекта;
- Расшарить на них часть документов;
- Публиковать информацию по проекту в блог;
- На регулярной основе рассылать информацию обобновлениях проекта по почте, используя скриншоты прототипа для демонстрации того, что именно тестировалось в рамках исследовательских сессий.
Публикуйте самую свежую информацию о дизайне вашего прототипа
Сделайте так, чтобы у вашей команды всегда был доступ к последней версии прототипа, но при этом обеспечьте ей адекватную защиту. Членам команды может понадобиться проверить что-либо или использовать прототип для обсуждения проекта с собственными заинтересованными в результатах проекта лицами.
Ретроспекция
Важно отражать прогресс по проекту регулярно. Выделите время на ретроспективную оценку проекта, в рамках которой команда, в которой ведется работа над изучением пользователей и дизайном, сможет открыто обсудить процесс и высказать предложения по его изменению. Назначьте ответственных за задачи и строки выполнения действий, чтобы высказанные предложения были выполнены.
