Careerlab – центр профессионального развития

Человек, посвятивший 40 лет дизайну и юзабилити. Автор применяемой во всем мире методики расчета возврата инвестиций (ROI) в юзабилити. Автор более 100 концепций пользовательских интерфейсов для смартфонов, в том числе для iPhone (Apple). Основатель и президент AM+A, более 25 лет осуществляющей консалтинг и проектирование для Microsoft, Oracle, Adobe Systems, eBay, Nokia, Samsung, Hewlett-Packard, Siemens и других.

Кэтрин Гэдди и Аарон Маркус
Азбука анализа задач в веб-дизайне

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если анализ задач — такая простая и полезная вещь, почему клиенты (а зачастую даже профессионалы в области исследований эргономики и юзабилити) часто не понимают, зачем вообще нужен какой-то анализ?

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

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

Причина вторая: Отсутствует контакт с пользователями
Нам всегда печально слышать такой ответ от клиентов. Однако в последнее время, когда пользователям и потребителям продукта уделяется большое внимание, мы все реже слышим от своих клиентов, что им запрещается вступать в контакт с пользователями разрабатываемых ими продуктов. Проблема, которая до сих пор волнует наших клиентов, — это суммы, в которые им обойдется проведение интервью.
Однако, как пишет Якоб Нильсен в одной из своих публикаций в блоге Alertboxes (http://www.useit.com/alertbox/), «Эта мысль может шокировать, но… исключение пользователей из этого процесса гарантирует полное отсутствие какого-либо понимания ситуации и каких-либо значимых результатов». Но если вы получите тестовые данные хотя бы от одного пользователя, вы смело можете сказать, что вы получили уже 30% необходимой информации, помогающей оценить ваш дизайн с точки зрения удобства использования. Думаю, мне не придется объяснять, насколько огромна разница между 0 и 30%«.
Проводя подробные личные интервью с пользователями, вы можете увидеть собственными глазами, что именно они делают; в противном случае вам остается лишь догадываться об этом на основании старых данных или данных, которые будут получены в будущем. В результате вы будете меньше беспокоиться о разнице между тем, что они хотели бы делать и что они делают на самом деле. Один из моих коллег однажды сказал: «Пользователи могут не знать, чего они хотят, но они знают, что они делают».

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

Причина третья: Результаты анализа запутанные и непонятные, и интерпретировать их очень сложно
Один из специалистов в области эргономики и юзабилити привел пример анализа одной оборонительной системы, в которой каждое элементарное действие, выполняемое пользователем, включало запрос к базе данных, а объем возвращаемой информации превышал 60 разных полей таблицы. Иногда приходится анализировать и регистрировать информацию с такой степенью детализации; однако для большинства случаев столь детального анализа не потребуется. Хотя данные, полученные в результате анализа задач, помогут вам при разработке прототипа, избегайте излишней детализации на этом этапе, иначе вы рискуете прийти к ситуации «аналитического паралича».

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

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

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

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

Представьте, что вы оказались в незнакомом вам городе и составьте список того, что вам необходимо знать, чтобы решить, в какой ресторан пойти. В этом списке может оказаться и то, где расположен ресторан, и сколько до него добираться, в каком направлении нужно двигаться, чтобы добраться до него, меню, цены, а также множество других вещей. Рядом с каждым пунктом вашего списка проставьте цифры, обозначающие порядок, в котором вы хотите получать необходимую информацию; выбирайте сначала самые важные данные, постепенно переходя к менее важным, либо сначала ограничьтесь теми ресторанами, которые находятся поблизости, продвигаясь затем все дальше и дальше. Затем просмотрите сайты, на которых опубликована нужная вам информация, чтобы составить список ресторанов, из которых вы сможете выбрать один. Постарайтесь выполнять это задание так, как если бы вы действительно оказались в подобной ситуации — вам нужно было бы пойти в ресторан в этом городе. Насколько полную информацию предоставляют вам веб-сайты? Какой из сайтов наилучшим образом отвечал вашим требованиям и почему? Какой из сайтов больше всего разочаровал вас и почему? Как вы оцениваете сайты, которые вы посещали, с точки зрения производительности — например, оцените время, которое вы потратили на поиски необходимой информации. Были ли среди просмотренных вами сайтов такие, которые лучше помогали экспертам (тем, кто знает этот город), чем новичкам (т.е. вам)? При выполнении реальных исследований вам придется провести индивидуальные интервью как минимум с пятью-шестью потенциальными пользователями, и не полагаться на мнение только одного пользователя, а также на свое собственное мнение.