2.8 Элементы опыта взаимодействия на практике

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

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

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

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

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

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

• Дизайн по умолчанию имеет место, когда структура опыта взаимодействия диктуется структурой вашей организации или ее технологических процессов. Хранение истории заказов вашего клиента и информации об оплате заказов в отдельных базах данных, возможно, хорошо подходит для существующей у вас технической системы, но отсюда не следует, что такое их разделение при взаимодействии пользователя с сайтом будет удачным решением. Аналогичным образом контент, приходящий из разных подразделений вашей фирмы, лучше послужит пользователю, если будет представлен не по отдельности, а целостно.
• Мимикрический дизайн возникает, когда организация опыта взаимодействия следует соглашениям, принятым на других сайтах, в публикациях или приложениях, независимо от уместности этих соглашений для вашей аудитории (и вообще для Сети). Одним из примеров этого явления может служить широко распространенное и беспорядочное применение вкладок в качестве системы навигации в конце 90 х годов.
• Дизайн по указанию сверху отличается тем, что в основе решений в области опыта взаимодействия лежат личные предпочтения, а не потребности пользователей или цели сайта. Если оранжевый цвет доминирует в вашей палитре из за того, что он нравится одному из вице-президентов фирмы, или если в качестве навигационных элементов применяются только раскрывающиеся списки, потому что их предпочитает ваш ведущий инженер, это означает, что из вашего поля зрения исчезли стратегические цели, которые должны были определять ваши решения.

Пример: реализация механизма поиска

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

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

Удовлетворение этой потребности является ключевым стратегическим решением.

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

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

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

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

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

Как задать правильный вопрос

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

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

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

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

В некоторых организациях предпочитают именно такой подход, называя его «тестированием пользовательского признания» (user acceptance testing). Здесь очень показательно слово «признание»: акцент делается не на том, нравится ли сайт пользователям и будут ли они его использовать, а на том, признают ли они его. Это тестирование не редко проводится на самом последнем этапе разработки, когда бесчисленные допущения уже оказали свое влияние на опыт взаимодействия без какой бы то ни было проверки. При пользовательском тестировании очень трудно обнаружить эти допущения, потому что они спрятаны под слоями интерфейса и дизайна взаимодействия.

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

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

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

Марафон и спринт

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

Когда я описываю проблемы разработки опыта взаимодействия своим клиентам, я часто прибегаю к спортивной метафоре: марафон и спринт – разные дистанции. Отдавайте себе отчет, в какой гонке вы участвуете, и бегите соответствующим образом.

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

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

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

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

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

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

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

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

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

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

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