wave

Процесс и результат

Теория и практика -
Share Button

Недооценивание важности процесса и переоценивание важности результата

О слове “юзабилити” мы узнали относительно недавно, но оно уже успело изрядно подзатаскаться. Юзабилити-специалисты напрочь забыли об удовлетворённости, думая только об эффективности и продуктивности (для бизнеса), называя всё это “удобством”, хотя все эти три термина (эффективность, продуктивность и удовлетворённость) равноправно стоят в определении слова “юзабилити” в стандарте ISO 9241-11. Все мы употребляем приставку UX в названии должности, как бы намекая, что занимаемся чем-то, что связано с user experience, хотя о самом-то experience (что в переводе с англ. означает “опыт” и, что более важно в контексте данной статьи, “переживание”) мы немного позабыли, превратившись в оптимизаторов конверсии.

1  2

3  4

Скорее всего, одна или несколько из представленных фотографий заставят биться сердце чаще у некоторых читателей, хотя они иллюстрируют скорее процесс, а не результат. Результат без процесса был бы скучен и куда менее приятен. Но мы почему-то забываем об этом, создавая наши цифровые продукты. Особенно отчётливо эта тенденция прослеживается в e-commerce, где абсолютная фокусировка на результат (конверсия любой ценой) отодвигает процесс взаимодействия даже не на второй план. Мы всеми усилиями пытаемся сократить это взаимодействие, пытаясь максимально увеличить процент тех, кто дойдёт “до конца”, и не берём во внимание то, что возвращаться к нам снова у них не будет никаких причин. Клиентам интернет-магазинов уже давно не предлагают что-либо выбирать и принимать какие-либо решения самостоятельно, оставляя каталог только для привлечения трафика. Ну, ещё, наверное, потому что магазин без каталога будет выглядеть как минимум странно. Всё что нам нужно – это лиды (чаще всего нам нужно получить всего лишь номер телефона потенциального покупателя). Мы говорим: “Просто позвони, мы всё выберем сами. Платить сейчас не нужно, отдашь курьеру, когда тот привезёт товар”. Люди охотно соглашаются на это, ведь так проще и быстрее, а времени в интернете (да и в жизни) у нас всегда катастрофически мало, ведь за наше внимание в соседних вкладках воюют ещё с десяток сайтов, плюс в телефоне десяток приложений. А где же шоппинг? Где радость выбора и удовольствие от процесса покупки? Как же возможность самостоятельно реализовать поставленную задачу и получить удовлетворение от достигнутого результата?

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

Всецело ориентируясь на результат путём “оптимизации” процесса (читай: сводя весь процесс на “нет”), мы получаем что-то вроде того же Foursquare, в котором чек-ины происходят автоматически (насколько это возможно) в зависимости от нашего месторасположения. Несомненно, такая “оптимизация” существенно повысила бы один из основных KPI приложения: активность пользователей, которая может выражаться в количестве чек-инов на одного пользователя за определённый период времени. Но смысл такой системы тут же теряется. Поэтому мы получили бы краткосрочный позитивный эффект без всякого дальнейшего развития.

Если ресурс нацелен на точечное/случайное взаимодействие с клиентом/пользователем, то модель “выжать конверсию при использовании системы любым путём” может подойти. Но это тупиковый ход, так как продукт стаёт в один ряд с тысячами  других таких же. Если же мы нацелены на долгосрочное сотрудничество с клиентом, то ему должно быть интересно взаимодействовать с нашим ресурсом, он должен испытывать радость от процесса. Для этого система должна быть историей, частью которой станет клиент (пользователь). Модель пассивного потребления давно изжила себя (нам больше не интересно смотреть телевизор), сейчас люди хотят принимать активное участие (почувствовать себя ломо-фотографом, загружая фотографии в Instagram, или музыкантом, создавая музыку в Garage Band).

Радость взаимодействия

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

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

  1. агон – активность, построенная по принципу соревнования;
  2. алеа – занятия, в основе которых лежит фактор случая;
  3. илинкс или вертиго – деятельность, которая нарушает нормальное восприятие реальности;
  4. мимикрия – занятия, создающие альтернативную реальность.

К примеру, весь gamification – это класс агон (рейтинги, балы, бейджи), а также частично мимикрия (звания вроде “мэр”, “эксперт” и т.д.).

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

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

Чтобы понять, как всё-таки спроектировать взаимодействие пользователя с системой таким образом, чтобы оно приносило удовольствие, давайте рассмотрим модель потока, разработанную профессором психологии Михайем Чиксентмихайи и описанной в его книге “Поток. Психология оптимального переживания” (“Flow: The Psychology of Optimal Experience”). Мы будем основываться на этой модели, так как, по моему мнению, она является наиболее понятной и жизнеспособной концепцией счастья.

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

Wikipedia

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

  1. ясность и определённость поставленных целей;
  2. постоянная обратная связь при выполнении задач;
  3. сложность решаемых задач должна соответствовать навыкам и умениям;
  4. полная концентрация на поставленной цели и вовлечение в выполняемые задачи.

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

Ясность целей

Цели пользователя – это первое, на чём мы должны фокусироваться при проектировании взаимодействия. Цели – это призма, сквозь которую нужно смотреть в течение всего проекта, так как именно цели мотивируют пользователя совершать определённые действия. Не зря мы встречаем соответствующую графу в любом шаблоне описания пользователей системы (http://wiki.fluidproject.org/display/fluid/Persona+Format), в любой методике исследования пользователей.

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

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

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

targets

Чтобы разобраться со всем этим многообразием целей, задач и функционала, мы можем воспользоваться методом storymapping, расположив все локальные цели и задачи на временной шкале и подобрав под каждую из задач соответствующие инструменты. Объединив данную технику с методом Кано или, скажем, MoSCow, мы сможем проранжировать функционал по важности в определённый момент времени (на определённом этапе взаимодействия). В итоге мы получим нечто подобное:

mumbo-jumbo

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

Постоянная обратная связь

Это условие очень сильно пересекается с несколькими эвристиками Нильсена, что является скорее подтверждением важности его выполнения. Вот только когда в эвристиках мы читаем “видимость состояния системы” или “информированность пользователя”, то почему-то сразу представляем себе что-то подобное плашке “Still working” или “Sending” в Gmail:

6

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

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

Сложность решаемых задач должна соответствовать навыкам пользователя

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

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

7

Если упростить данный график, то можно получить упрощённую модель с учётом времени:

8

Дайте человеку слишком простой функционал (читай: сделайте достижение цели слишком простым) и взаимодействие с системой покажется ему скучным, а, следовательно, удовлетворение от такого взаимодействия будет весьма сомнительным. Но ещё хуже, если мы сделаем процесс достижения цели слишком сложным. В этом случае впечатления от взаимодействия будут ещё менее приятными. Все же помнят главное правило при разработке интерфейсов: “не заставляйте пользователя чувствовать себя дураком”. Так вот, столкнувшись со слишком сложными задачами, весьма вероятно, что человек именно так и будет себя чувствовать. Также может возникнуть чувство тревоги, страха (что-то сделать не так, с чем-то не справиться), стыда и так далее.

Увлекаясь “повышением удобства” системы, мы очень часто стараемся максимально упростить задачи, которые ставятся перед пользователем для достижения цели. Тем самым растворяем наш сайт/приложение/что-либо-ещё среди большого количества скучных аналогов. Или же забываем объективно оценить уровень навыков людей, которые будут пользоваться нашей системой (читай: забываем провести исследования целевой аудитории) и делаем непосильной поставленную задачу. Приведя в пример ecommerce-сайты, в первом случае – это сбор контактной информации всеми способами без каких-либо дополнительных действий со стороны пользователя, так как добиться конверсии в покупателя (продать товар или услугу) значительно проще, общаясь с потенциальным клиентом по телефону; во втором случае – это отображение всевозможных характеристик, фильтров и т.д., которые не говорят пользователю ни о чём, но заставляют чувствовать себя дураком, или как минимум недостаточно осведомлённым. Обычно во втором случае мы руководствуемся фразой “а вдруг кому-то понадобится”, в очередной раз распыляясь на покрытие всех возможных потребностей всех возможных пользователей.

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

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

В качестве иллюстрирующего примера здесь опять же можно привести Foursquare. Все мои друзья, которые полгода назад были “мэрами” всего-чего-угодно и фигурировали на первых местах в списке по количеству баллов, сейчас занимают последние места с символическим рейтингом ~10 баллов (а это приблизительно 1 чек-ин в несколько дней)  и остаются “мэрами” только своей квартиры или любимого бара. Это произошло просто потому, что стало слишком скучно – время идёт, уровень сложности задач остаётся тем же. Например, Дмитрий Сатин как-то рассказал мне о том, что в какой-то момент времени стал чек-иниться только там, где можно сделать фото в Instagram. Тем самым, связав две соцсети, самостоятельно повысил уровень сложности задачи, добавив хоть какой-то дополнительный смысл этим действиям.

Полная концентрация и максимальная вовлечённость

На первый взгляд может показаться, что концентрация и вовлечённость уж точно никак не зависят от проектировщика взаимодействия. Это не совсем так, а точнее – совсем не так.

Во-первых, проектная команда должна изучить и учесть все факторы, которые отвлекают или могут отвлечь пользователя от работы с системой. Мы должны сделать так, чтобы возобновление взаимодействия после вынужденного прерывания происходило максимально комфортно и эффективно. Если бухгалтера прерывают перерывами на перекур или чай в среднем 6 раз в день, мы должны это учесть. Если у менеджера по продажам раз в 2-3 минуты звонит телефон, мы должны это учесть. Тут становится ясно, что изучение рабочей обстановки, окружающей среды, распорядка дня – это важно. В этом нам помогут наблюдения, контекстные исследования или анкетирование.

Во-вторых, нам необходимо проработать наиболее частые сценарии и контекст использования продукта. Хорошо проработанный customer journey может дать нам понимание, в какой последовательности возникают различные варианты использования продукта (задачи и контекст). Если мы понимаем, что один из наиболее частотных сценариев работы с сервисом просмотра видео-контента будет состоять из такой последовательности шагов:

  1. запуск эпизода сериала утром на ноутбуке дома;
  2. продолжение просмотра на планшете по дороге на работу;
  3. окончание просмотра по дороге домой;

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

В-третьих, само содержание экранов системы должно быть таковым, чтобы концентрировать внимание пользователя, а не рассеивать его. И тут мы в очередной раз осознаём важность проработки сценариев взаимодействия как одного из обязательных этапов проектирования. Чётко прописанные сценарии уберегут нас от соблазна отображать на экранах элементы по принципу “а вдруг пригодится”. Чтобы эффективно вовлечь пользователя и помочь ему дойти до поставленной цели (выполнить одну или комплекс задач), есть смысл придерживаться золотого правила: “один экран – одно действие”. Конечно, действий в большинстве случаев может быть несколько, а не одно, но должно быть одно наиболее приоритетное и важное – основное действие (купить, распечатать, экспортировать, отослать, позвонить, зачекиниться, опубликовать, загрузить и т.д.). Проведите серию “пятисекундных тестов”, чтобы понять, какой элемент на экране привлекает больше всего внимания, а потом сравните с тем основным действием, которые необходимо выполнить пользователю на данном этапе.

Эпилог

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

Если вы не хотите смешаться с тысячами себе подобных и единоразово возникнуть в жизни пользователя, создавайте приятные впечатления и способствуйте качественным переживаниям. Для этого ваш продукт должен рассказывать историю, которая гармонично вплетётся в историю жизни вашего пользователя и станет для него чем-то действительно важным. У вас в запасе огромное количество техник и методик, которые помогут справиться с этой задачей: storytelling, customer journey, storyboarding и пр. Здесь трудно переоценить важность исследования пользователей: их страхов, потребностей, поведения, привычек, желаний, целей.

Я полностью отдаю себе отчёт в том, что прочитав всё вышесказанное, многие из читателей подумают: “О-хо-хо! Уж как-то всё слишком идеально тут. Как же мы сможем учесть все потребности пользователей и понять всё что нужно предоставлять в определённый момент времени?”. Но ведь именно это и отличает проектирование взаимодействия от перемещения квадратиков на бумаге или в Axure – перед принятием каких-либо интерфейсных решений мы должны подумать о тех, кто этим интерфейсом будет пользоваться. “Но ведь мы всё равно не сможем учесть все (!) возможные варианты развития событий”. Тут могу только ответить, что вам и не нужно прорабатывать все варианты. Распыляясь на всеобъемлющий интерфейс, мы создаём очередное “сразу всё и ничего толком”. Сконцентрируйтесь на чём-то конкретном, создайте одну историю, проработайте один сценарий. Как бы мы правильно всё не делали, у нас всё равно не выйдет создать идеальный продукт за одну итерацию.  Но именно поэтому у нас есть целый арсенал мощных инструментов и методов изучения поведения, выявления ошибок и замера эффективности принятых решений: сплит-тестирвоания, изучение статистики Google Analytics, WebVisor, тестирование ожиданий, “пятисекундные тесты”, интервьюирование, юзабилити-тестирования.

Увлекательных интерфейсов вам!

Share Button