Прототипирование. Практическое руководство.

Шаг 4: добавление содержимого.

Базовая структура создана, пора перейти к содержимому. Мы добавим в запись блога «рыбу» и несколько комментариев. Ниже разместим форму для отправки комментария. Нажатие кнопки Post Message будет создавать на экране эффект в духе AJAX (отправка комментария).

1. Добавим шапку и несколько строк «рыбы» в раздел Article.

<div id="Article">

<div class="container">

<h2>Most Awesome Blog Post Ever</h2>

<p>Lorem ipsum dolor sit […].</p>

</div>

</div>

2. Под записью в блоге добавим блок с комментариями. Он будет включать комментарий, который мы вначале скроем, используя jQuery. Следующий код должен быть помещен сразу за последней строкой текста сообщения, но внутри контейнера, обрамленного тегами div.

<hr />

<h3>Comments</h3>

<table>

<tr>

<th width="25%"></th>

<th width="75%"></th>

</tr>

<tr class="new-comment">

<td><strong>Tom Sawyer</strong><br />

<span class="quiet">1 minute ago</span></td>

<td>Sit amet, consectetuer adipiscing[..].</td>

</tr>

<tr>

<td><strong>Betty Boop</strong><br />

<span class="quiet">4 minute ago</span></td>

<td>Lorem ipsum dolor sit amet, con[…].</td>

</tr>

<tr>

<td><strong>Barney Rubble</strong><br />

<span class="quiet">16 minute ago</span></td>

<td>Consectetuer adipiscing elit, […].</td>

</tr>

<tr>

<td><strong>Winnie Pooh</strong><br />

<span class="quiet">45 minutes ago</span></td>

<td>Sed diam nonummy nibh euismod […].</td>

</tr>

</table>

<h3>Say Something</h3>

<form>

<ul>

<li>

<label for="Name">Name</label>

<input id="Name" class="third" />

</li>

<li>

<label for="Email">Email</label>

<input id="Email" class="third" />

</li>

<li>

<label for="Comment">Comment</label>

<textarea id="Comment"></textarea>

</li>

<li>

<label></label>

<a href="#" id="PostMessage"><img.

src="images/post-message.gif" /></a></li>

</ul>

</form>

3. Затем подключим в шапке библиотеку jQuery сразу за тегом комментария Import JavaScript framework.

<!– Import JavaScript framework ->

<script src="lib/js/jquery-1.2.6.min.js"></script>

4. Наконец, осталось добавить маленький фокус jQuery в шапку HTML-страницы сразу после строки, подключающей файл jQuery.

<script>

// Если страница готова.

$(document). ready(function(){

$(".new-comment"). hide();

$("a#PostMessage"). click(function () {

$(".new-comment"). show();

});

});

</script>

Вот и все. Откройте обновленный прототип в браузере, как показано на рис. 11.4.

Нажмите кнопку Post Message, и новый комментарий появится в начале списка комментариев, а страница подсветится желтым (см. рис. 11.5).

Прототипирование. Практическое руководство

Рис. 11.4. Окончательный HTML-прототип с записью в блоге и комментариями

Прототипирование. Практическое руководство

РИС. 11.5. HTML-прототип с подсвеченным новым сообщением в блоге

Я называю эти переходы в духе AJAX «постепенным раскрытием». Это отличный метод, если элементы экрана взаимосвязаны или их показ ограничен определенными условиями (выбор элемента на экране приводит к изменению содержимого в другой части экрана).

В 2008 году я использовал этот метод прототипирования при усовершенствовании онлайновой формы для университета. Приложение занимало 13 полных экранов, на заполнение требовалось не меньше 20 минут. Ниже я расскажу, как использовал метод постепенного раскрытия для доработки приложения и размещения его на двух экранах. В итоге на заполнение формы стало уходить в среднем 2,5 минуты.

Практический пример: как прототипирование снизило потери времени на 85%

Тодд Заки Варфел.

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

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

Когда мы изменяем систему, то всегда проводим основные тесты на удобство использования. Изучение результатов дает нам возможность не только обнаружить серьезные проблемы, но и провести ключевые измерения для ROI. Единственный способ достоверно измерить успех или провал – сравнение с предыдущим вариантом.

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

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

Мы хотели объединить всю текущую информацию и все заполняемые в форме поля методом постепенного открытия в духе AJAX. Сначала на экран выводился бы минимум информации, необходимый для начала процесса. Потом содержимое и функции открывались бы постепенно в зависимости от действий участника.

Мы надеялись, что новый дизайн решит следующие проблемы:

• Снизит страх. Вместо экрана с 20–30 полями и индикатором, что это первый экран процесса, состоящего из 13 стадий, мы вывели 5 полей с контактной информацией и индикатор, показывающий, что участники находятся в начале процесса из двух шагов.

• Предотвращение ошибок. Удалите с экрана все несвязанные поля. Начните с необходимого (рис. 11.6). Исключите возможность ошибки.

• Создайте более четкий интерфейс. Когда выбор сделан, выведите на экран удобочитаемый текст, а не множество полей и для показа следующих вопросов используйте метод постепенного появления (рис. 11.7–11.8).

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

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

Как мы это делали? Мы сохранили ту же информацию, но использовали переходы в духе AJAX, чтобы свести 13 страниц к двум экранам – 85%-ное улучшение. В среднем время заполнения уменьшилось с 25 минут до менее чем 2,5 минуты – 1000%-ное улучшение.

Прототипирование. Практическое руководство

РИС. 11.6. Выбор уровня образования, постепенное появление

Прототипирование. Практическое руководство

РИС. 11.7. Выбор варианта программы, постепенное появление

Прототипирование. Практическое руководство

РИС. 11.8. Выбор специализации, постепенное появление

Количество ошибок тоже было снижено с 2,5 в исходной модели до 0 в прототипе. Участники отмечали бо́льшую аккуратность нового интерфейса по сравнению с исходным. Некоторые пришли в восторг, когда увидели постепенное появление полей, и отмечали, что им очень понравился вариант с выводом информации только после того, как сделан выбор.

Наконец, доля общей удовлетворенности увеличилась с 60 до 95% для прототипа.

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

Дополнительные ресурсы.

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

Инструменты.

Dreamweaver. Сайт и среда для разработки приложений от компании Adobe. Разделенный экран и модели анимированного предварительного просмотра дают приблизительное представление, на что будет похож прототип в браузере, когда вы выйдете из программы. А таким пуристам, как я, можно не беспокоиться, что эта программа перепишет ваш сверстанный вручную HTML-файл. www.adobe.com/products/dreamweaver/.

TextMate. TextMate отражает подход компании Apple к операционным системам, примененный к текстовому редактору. TextMate совмещает основы UNIX и графический интерфейс и предоставляет лучшие наработки и экспертам-программистам, и новичкам: macromates.com/.

Coda. Отличный небольшой «инструмент разработки в одном окне» от компании Panic Software[34]. www.panic.com/coda/.

Фреймворки.

960 Grid System. Система 960 Grid облегчает процесс разработки веб-приложений. Предоставляет фреймы наиболее часто используемых размеров с шириной 960 пикселей. Существует два варианта – 12 и 16 колонок. Каждый из них можно использовать отдельно; возможно также применять оба варианта одновременно. 960.gs.

Blueprint. CSS-фреймворк, цель которого – сократить время разработки. Он дает серьезную основу для создания проектов с легкой в использовании сеткой, толковой разметкой текста, полезными дополнениями и даже стилями для печати. www.blueprintcss.org.

jQuery. Это быстрая и лаконичная JavaScript-библиотека, которая упрощает действия в HTML, обработку событий, анимацию и взаимодействия в духе AJAX для быстрой веб-разработки. Она предоставляет новый способ написания команд на JavaScript. jquery.com/.

Prototype. JavaScript-фреймворк, цель которого – легкая разработка динамических веб-приложений. www.prototypejs.org.

Script.aculo.us. Используется вместе с Prototype, предоставляет простые в использовании кроссбраузерные интерфейсные библиотеки для создания сайтов и быстрых веб-приложений. script.aculo.us.

Protonotes. Маленькая JavaScript-библиотека, которая дает возможность добавлять комментарии к прототипам в окошках, внешне напоминающих листочки-стикеры. www.protonotes.com.

Статьи.

Гаррет Даймон, «Просто сделай: HTML-прототипирование и гибкая разработка»[35]: www.digital-web.com/articles/just_build_it_html_prototyping_and_agile_development/.

Джулия Стэнфорд, «Каркасные модели и прототипы в HTML без всяких хлопот»[36]: www.boxesandarrows.com/view/html_wireframes_and_prototypes_all_gain_and_no_pain.

Резюме.

Иногда нет ничего лучше настоящей вещи. Потратьте немного времени на изучение HTML, CSS и основ JavaScript. Это целый новый мир. У HTML есть ряд достоинств, делающих его удобным инструментом для прототипирования:

• это гораздо проще, чем кажется;

• есть много доступных CSS– и JavaScript-фреймворков, которые будут полезны новичку;

• это бесплатно;

• это позволяет оценить реализуемость и стоимость проекта;

• это один из немногих доступных инструментов и методов, который обеспечивает возможность совместной работы;

• он дает возможность экспортировать полученный код в рабочую версию, заметно сократив сроки вывода продукта на рынок.

Глава 12. Тестирование прототипа.

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

Тестирование удобства использования – целая отрасль промышленности. У нее есть свои профессиональные организации: UPA (Usability Professionals Organization – организация профессионалов в области удобства использования) и SIGCHI[37]. На эту тему написано много книг, наиболее заметные из них – «Проектирование с учетом удобства использования» Джекоба Нильсена и «Практическое руководство по тестированию удобства использования» Джозефа Думаса и Дженис Редиш[38]. Есть даже сайт американского правительства, посвященный этой теме: usability.gov.

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

Частые ошибки.

Существуют различные методы, например личное и удаленное тестирование. Есть разные инструменты, такие как Silverback, Morae или обычная видеокамера, закрепленная на штативе. А способов провести тестирование и составить отчет больше, чем разновидностей мороженого.

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

Ошибка № 1: тестирование – процесс, а не событие.

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

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

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

Ошибка № 2: неграмотное планирование.

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

Для начала задайте себе вопрос: «Зачем мы проводим тестирование?» Ответ прост: мы хотим выяснить, как работает продукт, на основании оценок времени, усилий и удовлетворенности.

Если вы хотите получить отзывы о чем-то не очень объективном и измеряемом, например мнение о погоде, вариантах дизайна А и Б, то такое тестирование в качестве основного метода исследования – не лучший метод. Эти вопросы можно задать в конце теста.

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

Выберите даты тестирования и опирайтесь на них. У нас в Messagefirst цикл тестирования составляет обычно 3–4 недели – от начала планирования до создания отчета. Типичный график выглядит примерно так:

• Неделя 1: выбор человека, который будет проводить отсев участников тестирования, разработка сценариев.

• Неделя 2: набор участников, окончание тестирования сценариев и создание прототипа.

• Неделя 3: тестирование прототипа и начало анализа.

• Неделя 4: окончание анализа и отчет о результатах.

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

Ошибка № 3: выбор неподходящих участников.

Исследователи часто говорят: «Введешь плохие данные – получишь плохой результат». Цель тестирования – посмотреть на продукт глазами людей, которые будут его использовать. Если набрать неподходящих участников (или не набрать подходящих), то вы получите ошибочные данные.

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

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

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

Лучший способ убедиться в высокой квалификации участников – или подбирать их самому в соответствии с подробным списком требований, или нанять профессионала. В настоящее время в Messagefirst мы подбираем участников сами. Пример списка наших требований можно найти здесь: rosenfeldmedia.com/downloads/prototyping/Sample_Screener.doc.

Ошибка № 4: плохо сформулированные вопросы.

Правильная формулировка вопросов – одна из самых сложных задач при тестировании на удобство использования. Задача – получить ответ на вопрос, не задавая самого вопроса. Сложно, не правда ли?

Рассмотрим пример сайта, посвященного развлечениям в Лос-Анджелесе в выходные. В прототипе, который мы тестировали, были представлены анонсы фильмов, концертов, местных мероприятий и список ресторанов.

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

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

Мы не спрашивали: «Как бы вы спланировали обед и поход в кино с друзьями с помощью этого сайта?» Мы спросили: «Как бы вы с помощью этого сайта нашли занятие себе и друзьям на эти выходные?».

Чувствуете разницу? В первом вопросе есть прямое указание на обед и кино; результат будет предсказуемым. Второй вопрос более неопределенный, дающий возможность выяснить, как они стали бы использовать сайт. Так мы можем понять, как сайт поможет им, когда они окажутся дома, вдали от нас, в привычной обстановке.

Ошибка № 5: неграмотная модерация.

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

Что делает человека хорошим модератором? Умение находить равновесие.

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

Самые серьезные ошибки модераторов – длинные и частые реплики, ответы за участников, наводящие вопросы. Поприсутствуйте на нескольких тестированиях, и уровень модератора станет вам понятен.

Лучший способ улучшить свои навыки модерирования – найти наставника, тренироваться, прислушиваться к критике и снова практиковаться. Можно записывать свои разговоры, а потом по аудио– или видеозаписи оценивать себя. Увиденное и услышанное может вас удивить.

Ошибка № 6: выбор неправильного метода для объявления результатов и рекомендаций.

Никто не будет читать ваш 10–20-страничный отчет. Единственное его назначение – служить подтверждением того, что работа проведена. Он останется набором цифр и букв. Такова жизнь. Но отчет составить все-таки нужно.

Если люди не хотят читать ваш отчет, как донести до них ценную информацию? Все зависит от условий и команды, с которой вы работаете.

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

Презентация в PowerPoint или Keynote с резюме данных отчета – тоже хороший вариант. Эффективны видеоклипы, показывающие ключевые моменты тестирования. Услышать о том, что делают участники в ходе тестирования, – хорошо. Но увидеть это на экране – просто отлично. Это один из лучших способов получить информацию из первых уст.

Подготовка тестирования.

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

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

Пример можно найти по адресу: rosenfeldmedia.com/downloads/prototyping/Sample_Screener.doc. Вы можете отредактировать его в соответствии со своими нуждами и свободно использовать.

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

Пример такого документа можно найти по ссылке: rosenfeldmedia.com/books.downloads/prototyping/Waiver.doc. Вы можете его редактировать и свободно использовать.

Цели тестирования влияют на сценарии, изучаемые вопросы и прототип. Эти три элемента взаимосвязаны.

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

Имеет смысл ограничивать продолжительность сеансов тестирования 45–60 минутами. Это позволит изучить 5–6 ключевых сценариев и не утомить участников. Мы обычно проводим 45-минутные сессии с получасовыми перерывами. При таком формате можно проводить 6–8 тестовых сессий в день.

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

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

Создание сценариев тестирования.

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

В приведенном выше примере сайт использовался для поиска развлечений в Лос-Анджелесе на выходные. Цель была не в том, чтобы найти подходящий ресторан или даже концерт. Участникам требовалось что-то интересное для них самих и их друзей. Поиск ресторана или концерта был только процессом для достижения цели – приятного времяпрепровождения с друзьями.

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

Если цель в том, чтобы найти развлечение для компании на выходные, то тестовый сценарий можно определить так:

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

Вместо […] нужно вставить ключевую контекстную информацию, собранную во время открытого обсуждения с участниками.

Затем можно было бы включить несколько ключевых вопросов или наблюдений.

• Как они начинают действовать (поиск, переход по страницам)?

• Ищут ли они первым место для развлечений или место, где можно поесть?

• Как они определяют, в какой ресторан пойти?

• Как они выбирают вид развлечений?

• Как они согласовывают план (например, по телефону, с помощью СМС, электронной почты, в Twitter)?

• Видят ли они расположение объектов на карте? Что думают?

Возможно, вы захотите включить в сценарий некоторую систему оценок. Мы предпочитаем шкалу от 1 до 5 для оценки сценария как участником тестирования, так и модератором.

Тестирование прототипа.

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

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

Когда участники расслаблялись, я начинал вводный диалог, прося их описать их опыт, относящийся к тому, что́ мы собирались тестировать. Например, если я хотел узнать, как они будут использовать сайт, чтобы найти развлечение на выходные в Лос-Анджелесе, я просил их рассказать мне о том, как в последний раз они планировали вечер с друзьями.

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

Собрав информацию во время вводного диалога, используйте ее для создания контекста.

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

Во время вводного диалога участник рассказал вам, что он хотел зайти в ресторан In-N-Out Burger[39], а затем на концерт местной группы. Превосходно. Вы можете использовать эту информацию, чтобы задать рамки сценария и дать участнику реальный контекст.

Я мог бы начать так: «Вы сказали, что собирались пойти в In-N-Out Burger, а потом на концерт местной группы. Вот страница. Покажите на ней, как вы стали бы искать ресторан и что-нибудь еще неподалеку, что вас могло бы заинтересовать».

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

Это тонкий нюанс. Однако он отражает сбалансированный подход к постановке вопроса: участника просят поискать что-нибудь неподалеку от In-N-Out Burger, не давая прямых указаний.

Совет.

Руками не трогать.

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

Запись наблюдений и отзывов.

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

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

Как я уже упоминал, и участники, и модераторы используют одну и ту же шкалу для оценки каждого сценария. По завершении работы модератор задает примерно такие вопросы: «Как бы вы оценили поиск развлечений на выходные в Лос-Анджелесе по шкале от 1 до 5, где 1 – очень трудно, а 5 – очень легко?».

Оценки участников записываются, модератор указывает свою оценку отдельно, не сообщая ее участникам.

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

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

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

Методы фиксации заметок варьируют: от записи на бумаге до использования таблиц Excel и специально разработанных для этой цели программ.

Программа Morae имеет встроенные возможности записи заметок и пометки флажками ключевых точек во время записи. Эти функции хороши, но я считаю, что интерфейс и взаимодействия в этой программе сложны и неудобны. Кроме того, она не работает на компьютерах Mac. Если в вашей аудитории только пользователи Windows, то она вам подойдет. Но наша работа часто требует участия в тестировании пользователей и Mac, и PC, поэтому для нас такая программа непригодна.

Качество наших выводов имеет первостепенное значение, и мы стараемся отфильтровать все, что не относится непосредственно к тестируемой системе. Опыт использования Firefox на Windows не то же самое, что опыт использования Firefox на Mac. Поэтому мы предоставляем в распоряжение пользователей Mac компьютеры Mac, а пользователей Windows – компьютеры с Windows.

Мы используем компьютеры iMac с процессорами Intel и программу Silverback, чтобы вести аудио– и видеозапись. Это позволяет нам запускать и Mac, и Windows на одной машине. Функция общего доступа к изображению на экране, встроенная в Mac OS X, позволяет видеть экраны удаленных компьютеров; при этом не нужно использовать дополнительное оборудование или ПО.

При удаленном тестировании можно обеспечить общий доступ к экрану с помощью ряда программ, в том числе NetMeeting, WebEx и Adobe Acrobat Connect.

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

• наблюдение: услышанное или увиденное;

• время: в какой момент это произошло;

• теги: ключевые слова, описывающие наблюдение.

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

Анализ и определение следующих шагов.

В большинстве случаев, когда я начинаю процесс анализа, у меня есть короткий список важных проблем (их я уже обдумываю). Обычно сюда входят моменты, которые я не раз наблюдал в ходе тестирования. Этот короткий список – точка отсчета.

Недавно мы провели некоторое количество тестов для клиента как на месте, так и удаленно. Мы знали, что собрали много информации. Но насколько много ее было – мы даже не задумывались, пока не распечатали все заметки на листах клейкой бумаги и не повесили на стену. Оказалось, что мы записали более 1000 фрагментов данных (см. рис. 12.1).

Прототипирование. Практическое руководство

РИС. 12.1. Тысяча фрагментов данных

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

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

Когда темы определены, можно оценить их важность и выводы по каждой из них. Как это сделать?

Я знаю несколько способов определения важности проблем. Вероятно, самый распространенный основывается на частоте (как часто возникала), тяжести или изучаемости (становится ли это проблемой всякий раз, и позволяет ли система снизить ее сложность).

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

Заключение.

Несколько лет назад я участвовал в дискуссии с консультантом по удобству использования, который сослался на итоговое тестирование (проводимое на финальном этапе). Я сомневаюсь в ценности такого тестирования, поскольку не верю в то, что процесс разработки продукта когда-нибудь заканчивается. Это непрерывный цикл.

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

Я надеюсь, книга помогла вам понять, что прототипирование – итеративный процесс. Вы создаете концепции проекта. Потом создаете прототип. Затем его тестируете. Вы выясняете, какие идеи работают, какие требуют уточнения и какие новые идеи могут появиться.

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

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

Резюме.

Тестирование прототипа – ключевой этап прототипирования. Во время тестов не забывайте о следующем:

• это процесс, а не событие;

• полученные результаты хороши настолько, насколько хороши участники. Убедитесь, что вы привлекли нужных людей;

• управление тестированием – навык, на развитие которого уходят годы. Поэтому практикуйтесь, и чем чаще – тем лучше;

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

• выберите правильный метод сообщения о результатах;

• видеозапись – очень мощный инструмент.

Благодарности.

В создании этой книги мне очень помогла поддержка разных людей. Прежде всего хочу поблагодарить Лу Розенфельда и консультативный совет издательства Rosenfeld Media. Я пришел к Лу с тремя темами для будущей книги. Он выбрал ту из них, к которой я был готов меньше всего (так обычно и бывает). Спасибо издательству, что подтолкнуло меня к написанию этой книги. Во время этой работы я многому научился.

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

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

Я благодарен этим людям, внесшим вклад в эту книгу: Биллу Скотту из компании Netflix, Андерсу Рэмси, независимому консультанту по взаимодействию с пользователями, Дэвиду Вербе из Adaptive Path, Роберту Рейману из агентства Frog Design, Крису Палле, независимому консультанту по взаимодействию с пользователями, Виктору Шу из Axure, Скотту Мэттьюзу из Xplane, Тому Хамбергеру из iRise, Роберту Хекману-младшему из Miskeeto, Джо Соколу из Regular Joe Consulting, Натану Кертису из Eight Shapes, Хэнку Вижнолзу и Стефану Уоббену из Concept7, Джонатану Бейкер-Бейтсу из Expedia и Фреду Бичеру из Evantage.

Несколько замечательных людей отрецензировали главы, где я описывал конкретные методы и инструменты, чтобы уточнить детали. Я благодарю Джефа Пэттона, независимого консультанта по взаимодействию с пользователями и консультанта по Agile, за рецензирование главы о прототипировании на бумаге; Андерса Рамси за рецензирование глав, посвященных Visio и HTML; Алана Массельмана, ведущего разработчика интерфейсов и приверженца Fireworks в компании Adobe, за рецензирование главы о Fireworks и Фреда Бичера за рецензирование главы об Axure RP Pro.

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

Об авторе.

Прототипирование. Практическое руководство

Тодд Заки Варфел – основатель и главный проектировщик компании Messagefirst – консультационного агентства по проектированию, оказывающего помощь компаниям в усовершенствовании, повышении полезности и удобства пользования их продуктов. Спросите у Тодда, на что он тратит свою жизнь, и он ответит: «Я просто проектировщик». Он считает, что проектирование – комплексное умение, ремесло, и, как любой великий мастер, очень гордится своими творениями. Он не из тех, кто обсуждает замысловатые различия между архитектурой информационных систем, разработкой взаимодействия, обоснованным проектированием и созданием услуг. Для него все это – «большой дизайн». Любую проблему Тодд рассматривает как вызов, возможность исправить ошибку. Тодд – мастер-наладчик. Иначе он не умеет. Он редко удовлетворен существующим положением дел и верит, что всегда смог бы сделать работу лучше. И это одна из причин, по которым он стал проектировщиком.

Тодд – проектировщик по профессии, а не по образованию. Он имеет диплом по когнитивной психологии и писательству (английский язык). Когда он окончил колледж, всемирной сетью управляли терминалы VAX, а книги печатались только на бумаге.

Тодд проектировал, создавал и ломал вещи в течение более 15 лет. Ему посчастливилось разрабатывать сайты, веб-приложения и другие программные системы для таких клиентов, как AT&T Wireless, Bankrate, Citi, Comcast, Cornell, Numara и Нью-Йоркский университет. Он признан одним из лидеров отрасли в области исследований и проектирования, неоднократно выступал на конференциях и проводил занятия в разных уголках земного шара. Он входит в состав участников Оперативной группы по обучению разработке веб-стандартов (Web Standards Project Education Task Force) и составляет расписание курсов обучения прототипированию.

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

Сейчас Тодд живет в Филадельфии со своей прекрасной женой Анжелой, сыном Элией и английским бульдогом по кличке Дачесс. Тодд ведет блог по адресу www.zakiwarfel.com и пишет в Twitter под именем @zakiwarfel.

Примечания.

1.

OmniGraffle – приложение по созданию диаграмм, разработанное Omni Group для компьютеров Mac. Выпускается с июня 2012 года.

Balsamiq – графический пользовательский интерфейс для создания макетов. Онлайновая версия вышла в 2008 году. Прим. ред.

2.

Snyder C. Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces. Morgan Kaufmann, 2003.

3.

Специалисты используют для описания этого метода термин «вайрфрейм» (wireframe). Прим. науч. ред.

4.

AJAX (от англ. Asynchronous JavaScript and XML, асинхронный JavaScript и XML) – использование «фонового» обмена данными браузера с веб-сервером в интерактивных пользовательских интерфейсах веб-приложений (позволяет ускорить и повысить удобство работы). Термин появился в 2005 году. Прим. ред.

5.

Подробнее см.: http://developer.yahoo.com/ypatterns/richinteraction/transition/selfhealing.html. Прим. науч. ред.

6.

Генеральный директор. Прим. ред.

7.

См.: http://www.youtube.com/watch?v=j5tFFIBDzVs.

8.

www.flickr.com/photos/soxiam/2532060829/.

9.

www.flickr.com/photos/soxiam/2532060829/.

10.

Эскизы можно зафиксировать с помощью фотоаппарата или интерактивных досок Smartboard.

11.

Подкаст – аудио– или видеофайл в стиле радио-/телепередачи, распространяемый в интернете. Прим. ред.

12.

Web 2.0 – сетевые проекты, информацию для которых подбирают и уточняют непосредственно пользователи. Прим. ред.

13.

www.teehanlax.com/blog/?p=293.

14.

Каскадная модель (waterfall model) – модель последовательной разработки программного обеспечения. Впервые описана У. У. Ройсом в 1970 году. Прим. науч. ред.

15.

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

16.

Участникам опроса разрешали, но не требовали от них выбирать несколько чаще всего используемых ими инструментов, не более трех – например, бумагу, Visio и HTML. Поэтому общая сумма процентных значений превышает 100. Источник: http://goo.gl/OAjRR.

17.

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

18.

Я использую термин «в духе AJAX», поскольку пуристы стали бы утверждать, что AJAX переносит информацию на сервер и обратно. Но во многих случаях эффект достигается без фактического обмена данными с сервером.

19.

www.istartedsomething.com/20071014/microsoft-prototpying-powerpoint/. Обратите внимание, что при наборе этой ссылки слово «prototyping» надо написать с ошибкой.

20.

Под трафаретами здесь и далее понимаются «стенсилы» (stencils) – схематичные элементы интерфейса. Прим. науч. ред.

21.

Caitlin Gannon, Creating an Interactive PDF Prototyping with Visio.

22.

Karen Bachmann and Whitney Quesenbery, Prototyping and Usability Testing with Visio.

23.

Текущая версия Fireworks CS6, вышла в 2012 году. Прим. ред.

24.

Jim Babbage, Creating an interactive PDF file from a multipage document in Fireworks CS4.

25.

Nick Myers, Designing interactive products with Fireworks.

26.

David Hogue, Fireworks Tips & Tricks – Creating Interactive Prototypes.

27.

Learn Fireworks CS4 – Creating Interactive Prototypes for Review.

28.

Prototyping Adobe AIR Applications with Fireworks CS4.

29.

Kumar Vivek, Designing for Mobile Devices Using Fireworks CS4.

30.

В 2012 году вышла версия 6.5. Прим. ред.

31.

World Wide Web Consortium – Консорциум всемирной сети. Прим. ред.

32.

Resource Description Framework – среда описания ресурса (модель для представления данных). Прим. ред.

33.

Речь о фильме 1931 года, режиссер – Джеймс Уэйл, в одной из главных ролей Борис Карлофф. Прим. ред.

34.

Panic Software – американская компания по производству программного обеспечения для Mac OS X. Первый продукт компании (Transmit) выпущен в 1998 году. Прим. ред.

35.

Garrett Dimon, Just Build It: HTML Prototyping and Agile Development.

36.

Julie Stanford, HTML Wireframes and Prototypes: All Gain and No Pain.

37.

SIGCHI (Special Interest Group on Computer – Human Interaction) – специализированная группа по пользовательскому взаимодействию, подразделение Ассоциации вычислительного оборудования (Association for Computing Machinery, ACM). Прим. ред.

38.

Nielsen J. Usability Engineering. Morgan Kaufmann, 1993; Dumas J. S., Redish J. C. A Practical Guide to Usability Testing. Intellect Ltd; Rev Sub edition, 1999.

39.

In-N-Out Burger – американская региональная частная сеть ресторанов быстрого обслуживания в пяти западных штатах. Включает 282 филиала, основана в 1948 году. Прим. ред.