Дмитрий Сатин

27 октября Высшая школа маркетинга и развития бизнеса ГУ-ВШЭ провела on-line конференцию «Портрет on-line покупателя, или есть ли отличия от традиционного потребителя».

Я выступал последним с часовым докладом “Как создать интернет-ресурс с учетом особенностей пользователей”.

Послушать аудиозапись выступления (60 минут)

• Видеозапись конференции
• Фотографии
• Скачать файл (MP3, 24 Mb)

Семинар “Что такое юзабилити?” на конференции Интернет и Бизнес 2007

Фёдор Вирин: Самым интересным, по крайней мере для меня, докладом является доклад о юзабилити, и о том что это такое, Дмитрия Сатина, руководителя UsabilityLab.

Юзабилити – это странная штука. Компаний, которые занимаются юзабилити и только юзабилити в России три. Это UsabilityLab, Usethics и UIDesign. И всё! Ну и соответственно, Дмитрий Сатин, который руководит UsabilityLab, я думаю, более чем достойная кандидатура для рассказа о том, что такое юзабилити.

Дмитрий Сатин: Спасибо, Федор! Федор выставил меня этаким чудаком, каких мало.

Фёдор Вирин: Можно еще два слова? Надо сказать, что поскольку по долгу службы я занимаюсь аналитикой в Mail.ru, когда Яндекс купил Мой Круг, я стал интересоваться, что это такое, и зарегистрировался там. Я считаю, что я знаю очень много народа, но у Дмитрия там 440 контактов, или около того! Т.е. это чуть ли не больше, чем у всех остальных.

Дмитрий Сатин: Таким в Моём Круге занимаются только HR’ы, спамеры, и я, но мне, в отличие от других, верят. Причиной такой кажущейся популярности является то, что в феврале этого года я стал издавать Юзабилити Бюллетень. Это открытое электронное издание, и вы на него можете подписаться, или не подписываться, а читать через RSS-ленту. Ну и чтобы привлечь внимание публики, я искал в интернете всех у кого в описании встречается слово юзабилити, и приглашал их в свои друзья, и, соответственно, подписывал их, таким дружественным, а иногда и недружественным образом, на Бюллетень. Теперь аудитория Бюллетеня уже больше 10 тысяч человек. Я надеюсь, что многие из вас тоже станут его подписчиками. Он выходит два раза в месяц, там все актуальные новости.

И в том числе, в 6-ом выпуске Юзабилити Бюллетеня, который выйдет через пару недель, будут опубликованы видео-материалы того, что вы сейчас услышите. Дело в том, что два дня назад, в понедельник была конференция РИТ. И я тоже был туда приглашен в качестве ведущего мастер-класса. И я делал там аж три разных события: круглый стол, мастер-класс, и выступление на секции “Качество”. Поэтому, как вы понимаете, за два дня мне трудно создать что-то совсем уж уникальное. Поэтому много из того, что я буду говорить, уже существует в записи и доступно на сайте UsabilityLab. Поэтому, если вам это понравится, и вы захотите показать это своим коллегам, то им можно сообщить ссылку на соответствующий ресурс.

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

Еще два предваряющих слова. Одно в адрес Федора, но оно будет вторым.

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

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

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

• Почему Юзабилити
• Зрелость Юзабилити
• Понятия и Процессы

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

Почему Юзабилити?

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

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

В качестве эпиграфа здесь приведена цитата из статьи Скотта Беркуна “О силе юзабилити-лаборатории”:

- Нам нужны более смекалистые пользователи!
- Нет! Нам нужны более заботливые разработчики!

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

Теперь, собственно, провокация: А вы в таргете?

Вы разрабатываете продукты. Уверены ли вы, что у них удобные интерфейсы? Конечно, уверены! Разве мы можем делать что-то плохое? Мы все умные люди. Я говорю это без иронии и сарказма, я всех вас априорно уважаю, как и вы уважаете меня. Мы все представители информационных технологий, которые требуют от нас таких знаний, которые есть не у многих. Мы меньшинство, которое зачастую делает несчастным большинство, диктуя им свою волю.

Наши пользователи, несмотря на то, что многие из нас гениальны, называют нашу работу отстоем. Я человек деликатный, и стараюсь не использовать шокирующих слов. Но здесь я его сохранил – это слова Беркуна – why software sucks? Так почему же то, что мы разрабатываем, получается отстоем? Откуда вы знаете, что именно говорят пользователи о ваших сайтах и программах, которые вы им поставляете. И как вы решаете для себя, удобно ли то, что вы создаете, или нет?

Почему пользователи называют наши системы отстоем? Ну, потому что они им кажутся слишком сложными. Потому что пользователи не понимают, как с ними работать. Потому что программы нестабильны, часто ломаются. Пользователи говорят: “Меня тошнит! Пойду поищу что-нибудь попроще”. Мы заставляем пользователей менять их мировосприятие, и не можем встроить нашу систему в их жизнь. Мы часто предлагаем продукт и предполагаем, что пользователь должен наслаждаться, взаимодействуя с ним. А на самом деле наслаждение пользователя лежит за рамками взаимодействия с нашим продуктом. Пользователь хочет купить что-то за 5 минут в нашем интернет-магазине, или закончить работу, написать письмо и т.д., и пойти, наконец, наслаждаться. Поэтому всё, что мы должны сделать, это создать незаметные и эффективные интерфейсы, позволяющие за короткое время решить задачи, заплатить нам за это денег, и может быть расстаться навсегда, а может встретиться вновь, если у нас грамотная программа лояльности.

Как же это получается? Никто из нас ничего плохого специально не делает. Мы всё делаем из благих побуждений. Я уверен, что среди нас нет профессиональных злодеев. И каждое решение мы принимаем во благо. Но каждый из нас эгоцентричен. Что значит эгоцентричность? Это психологическое понятие – когда человек считает, что люди хотят того же, что и он сам, что они думают, так же как он сам, чувствуют то же, что и он и т.д. Это в большей мере присуще детям, взрослый человек постепенно в течение жизни преодолевает этот эгоцентризм, сталкиваясь с проявлением того, что люди отличаются от него, он научается смотреть на вещи чужими глазами. Но присущий нам с детства эгоцентризм остаётся до самой старости, не изжитый в полной мере. И о своих пользователях мы часто думаем не то, кем они являются на самом деле. И считаем свои решения удобными, стандартными или гениальными. Но нужно же вовлечь пользователя! Нужно привести его и спросить, что он об этом думает, и сможет ли он с этим работать. Мы делаем частые допущения, которые сбивают наши проекты с верного пути. И наши усилия оборачиваются негативным опытом наших пользователей.

Перестаньте гадать! Соберите данные и решите – хорошо то, что вы делаете, или нет! Если вы не проводите юзабилити-тестирование, а, забегая вперед скажу, что юзабилити-тестирование – это выполнение задач, для которых создавался продукт, конечным пользователем в какой-то наблюдаемой среде. Юзабилити-тестирование можно провести за 20 долларов, можно потратить 10-ки тысяч долларов – это зависит от серьезности решаемых вопросов и доступных средств, но нет ограничений – это миф, что юзабилити-тестирование – это дорого – диапазон от 0 долларов до бесконечности, если мы делаем интерфейс управления атомной станцией, где критичность человеческой ошибки очень высока, то там не грех провести исследование продолжительностью в несколько месяцев. Ну так вот – не проводя работу с пользователем вы точно не знаете – в каком направлении вы идете. Может быть, вообще, не туда. И, может быть, вы тратите усилия на то, что пользователю не нужно.

Я, так же как и вы, работаю во многих интернет проектах, и до этих представлений дошел через какой-то опыт и в моей истории, в моей личной истории, были моменты принятия решений без обращения к каким-либо пользователям. У меня много примеров из индустрии знакомств – прекрасная вещь функциональность “подмигнуть”. Бесплатная, и не предполагающая каких-либо обязательств. Мужчина может подмигнуть женщине – как это происходит и в реальном мире. Эта функциональность реализована на сайте лидера в этой индустрии match.com. Но пользователь приходит на юзабилити тестирование и спрашивает – а это как? А что последует – нет я, конечно, понимаю в физическом мире, что означает – подмигнуть, но только в вашей системе-то что произойдет – я ведь глазами не моргаю? Я должен нажать на какую-то кнопку? И в результате подобного непонимания этой функции он либо не использует её вообще (т.е. игнорирует), либо начинает ею злоупотреблять, и тогда служба поддержки начинает получать сообщения – “У вас что там, тик с глазами? Что они мне все подмигивают?” Потому что пользователь, не зная ценности данной функции, и к чему она приводит, пользуется ею неправильно. Это лишь один пример, когда мы додумали за пользователя, и пользователю оказалось это совершенно не нужным. Необходимо проводить регулярные юзабилити тестирования, чтобы все наши усилия были не напрасны.

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

Как улучшить продукт и процессы?

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

Вторая вещь, с которой мне часто приходится сталкиваться, это следующая позиция: “Хорошо! Ты говоришь очень правильные слова, но мы не можем нашему заказчику/руководству, который выделяет деньги, сказать – нужно потратить ещё время и ещё денег, т.е. увеличить бюджет и сроки проекта, для того, чтобы включить в проект вас – таких вот чудаков юзабилистов”. В корне неверное понимание. Юзабилити приводит к сокращению времени и к сокращению ресурсов, необходимых для выполнения проекта. Но в таком случае, правда, бывают курьезы. В России очень развит аутсорсинговый бизнес и много хороших программистов работает над западными проектами. Мне тогда говорят project менеджеры: “Ну, вообще-то, в сокращении мы тоже не очень заинтересованы, потому что у нас есть ватага программистов, которых нужно кормить. И если бюджет вдруг сократиться, то чем же они будут заниматься?” В таком случае у нас появляется конфликт, стратегический, и выходом из него является принятие стратегического решения – что лучше: накормить ватагу программистов или иметь удовлетворенных и лояльных заказчиков, которым за короткое время поставляется качественный продукт, качественное решение? Я думаю, что это особенность России, но бизнесмены, работающие здесь – в России, и следящие за бюджетом, должны быть безусловно заинтересованы в том, чтобы это происходило быстро и качественно.

Зачем всё это нужно? Теперь собственно про деньги, я чуть-чуть уже говорил про это. Цифры, которые вы видите на экране: “1 доллар приносит от 10 до 100 долларов прибыли или сэкономленных средств”. У каждого проекта есть скрытые траты, не запланированные в бюджете. Это траты на переделку, затраты на поддержку пользователей, и т.д. Когда определяют бюджет на разработку и ставят сроки, часто не очень понимают, что за этим могут быть траты в два-три раза большие на то, чтобы продукт жил, чтобы адаптировать его к реальному миру. Таким цифрам некоторые из юзабилистов, которых, как сказал Федор, мало, не верят этим цифрам – и это поразительно! Возможно потому, что они работают консультантами и не близки тому бизнесу, для которого они работают. Эти цифры берутся из статистики, но я лично могу подписаться под ними, поскольку я работаю в компании, которая, в том числе, разрабатывает свои проекты. В пятницу вы увидите на докладах нашей секции выступление Анны Галаховой из IT-Online, которая расскажет, как перевыполняется план продаж за счёт юзабилити, при стагнирующем маркетинге. Там у нас получились “чистые” условия, поскольку были трудности с маркетингом и были успехи в юзабилити. В этих чистых условиях очень хорошо удалось показать какой огромный ресурс содержится в том, чтобы улучшить user experience и качество жизни нашего пользователя, – и что он за это нам платит.

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

Позитивный вклад юзабилити:

• Разработка: Снижение расходов и уменьшение времени;
• Продажи: Увеличение доходов;
• Пользователи: Повышение эффективности, продуктивности и удовлетворенности;
• Снижение затрат на внедрение (за счет сокращения обучения) и на поддержку пользователей.

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

Влияние на разработку:

• Снижение затрат на разработку
• Сокращение времени на разработку
• Снижение расходов на поддержку продукта
• Сокращение затрат на переделку продукта

Заключение первой части. Большинство людей – и это цитата Скотта Беркуна (UI дизайнер из Microsoft, который вырос из юзабилиста в project менеджера) “Большинство людей не умеют дарить подарки даже себе. Мы не всегда знаем, как сделать счастливыми себя, не то, что других. Все хорошее в этом мире создается щедрым умом. Если вы творите для других, вы дарите им то, за что они готовы платить”.

Литература:

Скотт Беркун:

• Искусство разработки прототипов пользовательских интерфейсов
• Почему большинство программ такие отстойные
• Сила юзабилити лаборатории
• Почему замечательные технологии не создают столь же замечательные продукты

http://scottberkun.it-online.ru/articles/

Аарон Маркус:

• The ROI of Usability

http://www.upassoc.org/usability_resources/
usability_in_the_real_world/roi_of_usability.html

Реплика на одной из западных e-commerce конференций

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

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

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

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

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

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

Юзабилити тестирование

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

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

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

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

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

Здесь кроется опасность! Менеджер, программист, маркетолог, как любой другой участник проекта, не являются пользователями того ресурса, который они разрабатывают или продвигают.

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

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

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

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

Оценка юзабилити по критериям

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

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

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

Критерии должны быть определены заранее, иначе остаётся высоким риск, что «эксперт» обратит внимание на мелочи, и пропустит что-то действительно важное.

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

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

Вот перечень объектов, подвергаемых проверке:

• Информационная архитектура и Навигация
• Структура страниц и Дизайн
• Содержание (контент)
• Формы и Диалоги
• Графика
• Цвета
• Оформление текста
• Устойчивость к ошибкам
• Браузерная совместимость и Особенности реализации

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

Оценка юзабилити по сценариям

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

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

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

Наглядность представления состояния системы

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

Связь с реальным миром

Сайт должен «говорить» на языке пользователей, слова, фразы и понятия должны быть знакомы пользователям. Информация должна быть представлена естественным и логичным образом.

Управляемость и свобода действий

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

Согласованность и стандарты

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

Предотвращение ошибок

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

Узнавание против запоминания

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

Гибкость и эффективность использования

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

Эстетика и минимализм дизайна

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

Предвидение и восстановление после ошибок

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

Справочная система и документация

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

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

Системный подход к юзабилити

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

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

Чтобы избежать таких разочарований в конце, а заодно и снизить расходы на разработку сайта, целесообразно использовать UCD (user-centered design), подход, основывающийся на раннем вовлечении пользователей в процесс разработки.

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

Анализ целевых пользователей

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

Составление пользовательских сценариев

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

Разработка прототипа

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

Юзабилити тестирование или оценка

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

Спецификация прототипа

После внесения изменений на основании  результатов тестирования и оценки, прототип специфицируется. Появляется документ, соответствующий понятию ТЗ, но описывающий только взаимодействие пользователя с сайтом.

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

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

Итеративность не значит – бесконечность. На все работы по проектированию в среднем уходит не больше месяца. Больше времени могут занять согласования с заказчиком (внутренним или внешним).

Кроме юзабилити эффекта, такой подход имеет, как минимум, два дополнительных положительных аспекта:

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

Всё это позволяет уложиться в сроки и бюджет проекта.

Пример

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

«Свобода», которая губит бизнес

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

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

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

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

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

Можно воссоздать то, что происходило у пользователя, стремящегося купить, например, мобильный телефон, и видевшего рекламу mp3-плеера. «Кстати, Таня давно просит купить ей плеер. Может быть этот? Посмотрим. Нет, откуда мне знать, какой плеер лучше. Поищу ещё!» И пользователь уходил с сайта, забыв, зачем приходил. И пользователь не сделал то, что хотел, и магазин остался ни с чем.

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

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

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

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

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

Этот пример хорошо иллюстрирует правило, не спрашивать пользователя, как он предпочитает, а следить за его поведением.

Call-центр играет ключевую роль в контактах между клиентами и компаниями. От качества работы call-центра зависит не только имидж компании, но и эффективность её бизнеса. Независимо от того, специализируется ли call-центр на обслуживании входящих или исходящих кампаний, от качества информационных систем, которыми пользуются его операторы, зависит, как скорость их работы, так и customer experience (удовлетворенность клиентов от работы компании).

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

* * *

Воскресный вечер. Звонок телефона:
– Алло, это квартира?
– Да, квартира, – изумляюсь я.
– Это агентство (называет известную компанию). Мы проводим опрос о предпочтениях автомобилей. У Вас есть 10 минут?
– Постарайтесь уложиться в 5, – отвечаю я, заставляя себя не повесить трубку.
– Мне нужно поговорить с тем, кто у Вас чаще всего водит машину.
– Это я, Вы уже говорите со мной, – понимаю, что сценарий разговора с респондентами не отлажен.
– Собираетесь ли Вы в ближайшем будущем менять автомобиль?
– Да.
– Когда?
– В течение года, или двух.
– Так… (пауза) 13-18 месяцев?
– Наверно.
– Какой автомобиль Вы рассматриваете? Мне нужно три названия.
– Honda Element, Toyota RAV4 и Mitsubishi Pinin, – говорю быстро, без запинки.
– Подождите. Я записываю… (пауза) У меня программа тормозит. Вы сказали Toyota?
– Да. Toyota RAV4.
– Нет. Мне сейчас только марки нужны. Toyota, Mitsubishi… И кто был третий?
– Honda.
– (пауза) А какие модели?
– Honda Element, Toyota RAV4 и Mitsubishi Pinin, – ложусь на диван, набравшись терпения, понимаю, что разговор будет длинным.
– У меня просто программа тормозит… Element, (пауза) RAV4…(пауза) Секунду… (пауза). Mitsubishi? Не Pajero?
– Pinin – это маленький Pajero, – приходит мысль начать расспрашивать, какой программой она пользуется.
– Да! Вижу её в списке. Спасибо! У меня больше нет вопросов, – раздаются короткие гудки.

* * *

Call-центры в современном бизнесе становятся точкой контакта (интерфейсом) организации со своими клиентами. Зачастую сотрудник call-центра является единственным представителем компании, с которым клиент общается «вживую». Поэтому альтернативное название – контакт-центр, точнее выражает функцию call-центра в современном бизнесе. Обеспечивая взаимодействие бизнеса с клиентом, контакт-центр выполняет ключевую роль в управлении отношений с клиентом (Customer Relationship Management).

Юзабилити входящих кампаний

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

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

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

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

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

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

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

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

Представим себе такую ситуацию: клиент позвонил в контакт-центр с вопросом, на который оператор не может ответить. Например, звонок в контакт-центр интернет-провайдера: «Я купил беспроводную точку доступа, которая поддерживает стандарт Power over Ethernet (PoE). Поддерживают ли ваши свитчи этот стандарт? Подаётся ли по кабелям дополнительное напряжение для таких точек доступа?» Такой вопрос для оператора из числа трудных. Худшее, что он может сделать, это ответить что-то недостаточно конкретное, например, «У нас стандартное оборудование», т.к. этот ответ не удовлетворит клиента, и возможно, подвигнет его обратиться к другому интернет-провайдеру.

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

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

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

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

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

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

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

У клиента, который замечает, что независимо от того, с каким оператором он общался, другие операторы понимают контекст проблемы, создается хорошее впечатление, что он имеет дело с интегрированной и организованной системой, а не с разрозненными людьми, выполняющими изолированную рутинную работу. Тем самым преодолевается одна из основных проблем call-центров – нелюбовь людей к общению с call-центрами из-за частных случаев «некомпетентности» операторов, их неспособности помочь в решении проблемы клиента.

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

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

Юзабилити исходящих кампаний

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

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

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

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

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

Этот текст может и должен быть организован в виде настраиваемых диалогов (сценариев), которые позволят адаптировать разговор к тем ответам, которые даёт клиент.

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

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

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

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

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

Поэтому сценарий разговора с клиентом должен быть представлен в виде диалога.

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

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

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

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

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

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

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

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

Заключение

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

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

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

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