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

 Юзабилити – это странная штука.  
   Почему Юзабилити? Это часть планировалась мной как провакационо-агрессивная сократическая беседа. Вы помните, что Сократ общаясь со своими учениками, задавал им стимулирующие вопросы. Они искали на них ответы, и так рождались трактаты, которые дошли до нас. Но я, конечно, не Сократ, а вы не Платоны.  
Но мне хотелось бы спровоцировать вас на размышление. Я планировал мысленно это как разговор с вами, но вас много, а я один, поэтому полноценной беседы получится не может по техническим причинам.
В качестве эпиграфа здесь приведена цитата из статьи Скотта Беркуна "О силе юзабилити-лаборатории": - Нам нужны более смекалистые пользователи!
- Нет! Нам нужны более заботливые разработчики! Многое из того, что я буду рассказывать, будет основано на его статьях, которые переведены нами на русский язык. Их вы тоже можете найти по ссылкам. Теперь, собственно, провокация: А вы в таргете? Вы разрабатываете продукты. Уверены ли вы, что у них удобные интерфейсы? Конечно, уверены! Разве мы можем делать что-то плохое?
Мы все умные люди. Я говорю это без иронии и сарказма, я всех вас априорно уважаю, как и вы уважаете меня. Мы все представители информационных технологий, которые требуют от нас таких знаний, которые есть не у многих.
Мы меньшинство, которое зачастую делает несчастным большинство, диктуя им свою волю. Наши пользователи, несмотря на то, что многие из нас гениальны, называют нашу работу отстоем. Я человек деликатный, и стараюсь не использовать шокирующих слов. Но здесь я его сохранил - это слова Беркуна - why software sucks?
Так почему же то, что мы разрабатываем, получается отстоем? Откуда вы знаете, что именно говорят пользователи о ваших сайтах и программах, которые вы им поставляете. И как вы решаете для себя, удобно ли то, что вы создаете, или нет? Почему пользователи называют наши системы отстоем? Ну, потому что они им кажутся слишком сложными. Потому что пользователи не понимают, как с ними работать. Потому что программы нестабильны, часто ломаются.
Пользователи говорят: "Меня тошнит! Пойду поищу что-нибудь попроще". Мы заставляем пользователей менять их мировосприятие, и не можем встроить нашу систему в их жизнь. Мы часто предлагаем продукт и предполагаем, что пользователь должен наслаждаться, взаимодействуя с ним. А на самом деле наслаждение пользователя лежит за рамками взаимодействия с нашим продуктом.
Пользователь хочет купить что-то за 5 минут в нашем интернет-магазине, или закончить работу, написать письмо и т.д., и пойти, наконец, наслаждаться. Поэтому всё, что мы должны сделать, это создать незаметные и эффективные интерфейсы, позволяющие за короткое время решить задачи, заплатить нам за это денег, и может быть расстаться навсегда, а может встретиться вновь, если у нас грамотная программа лояльности. Как же это получается? Никто из нас ничего плохого специально не делает. Мы всё делаем из благих побуждений.
Я уверен, что среди нас нет профессиональных злодеев. И каждое решение мы принимаем во благо. Но каждый из нас эгоцентричен. Что значит эгоцентричность? Это психологическое понятие - когда человек считает, что люди хотят того же, что и он сам, что они думают, так же как он сам, чувствуют то же, что и он и т.д.
Это в большей мере присуще детям, взрослый человек постепенно в течение жизни преодолевает этот эгоцентризм, сталкиваясь с проявлением того, что люди отличаются от него, он научается смотреть на вещи чужими глазами. Но присущий нам с детства эгоцентризм остаётся до самой старости, не изжитый в полной мере. И о своих пользователях мы часто думаем не то, кем они являются на самом деле. И считаем свои решения удобными, стандартными или гениальными. Но нужно же вовлечь пользователя! Нужно привести его и спросить, что он об этом думает, и сможет ли он с этим работать.
Мы делаем частые допущения, которые сбивают наши проекты с верного пути. И наши усилия оборачиваются негативным опытом наших пользователей. Перестаньте гадать! Соберите данные и решите - хорошо то, что вы делаете, или нет! Если вы не проводите юзабилити-тестирование, а, забегая вперед скажу, что юзабилити-тестирование - это выполнение задач, для которых создавался продукт, конечным пользователем в какой-то наблюдаемой среде.
Юзабилити-тестирование можно провести за 20 долларов, можно потратить 10-ки тысяч долларов - это зависит от серьезности решаемых вопросов и доступных средств, но нет ограничений - это миф, что юзабилити-тестирование - это дорого - диапазон от 0 долларов до бесконечности, если мы делаем интерфейс управления атомной станцией, где критичность человеческой ошибки очень высока, то там не грех провести исследование продолжительностью в несколько месяцев.
Ну так вот - не проводя работу с пользователем вы точно не знаете - в каком направлении вы идете. Может быть, вообще, не туда. И, может быть, вы тратите усилия на то, что пользователю не нужно. Я, так же как и вы, работаю во многих интернет проектах, и до этих представлений дошел через какой-то опыт и в моей истории, в моей личной истории, были моменты принятия решений без обращения к каким-либо пользователям.
У меня много примеров из индустрии знакомств - прекрасная вещь функциональность "подмигнуть". Бесплатная, и не предполагающая каких-либо обязательств. Мужчина может подмигнуть женщине - как это происходит и в реальном мире. Эта функциональность реализована на сайте лидера в этой индустрии match.com. Но пользователь приходит на юзабилити тестирование и спрашивает - а это как? А что последует - нет я, конечно, понимаю в физическом мире, что означает - подмигнуть, но только в вашей системе-то что произойдет - я ведь глазами не моргаю? Я должен нажать на какую-то кнопку? И в результате подобного непонимания этой функции он либо не использует её вообще (т.е. игнорирует), либо начинает ею злоупотреблять, и тогда служба поддержки начинает получать сообщения - "У вас что там, тик с глазами? Что они мне все подмигивают?" Потому что пользователь, не зная ценности данной функции, и к чему она приводит, пользуется ею неправильно. Это лишь один пример, когда мы додумали за пользователя, и пользователю оказалось это совершенно не нужным.
Необходимо проводить регулярные юзабилити тестирования, чтобы все наши усилия были не напрасны. Отличным инструментом контроля рисков в тех проектах, которые вы разрабатываете, является прототипирование. Это второе правило юзабилити - разработать макет, который можно проверить с пользователями ещё до начала серьезной разработки. Никаких структур баз данных еще нет - они не определены, ни строчки кода не написано.
Прототип может быть сделан на бумаге, может быть сделан в HTML, но вы его должны сделать максимум за неделю, а то и за два дня - все зависит от степени детализации, вытекающей и задач, которые стоят перед прототипом. И сразу же вы получаете очень много ясности - вы не тратите средства до того, как приняли решение - нужно ли их вообще тратить в этом направлении или нет. В сочетании с юзабилити тестированием прототипирование позволяет нам экономить время и деньги. Как улучшить продукт и процессы? Умные проектные команды устраняют ошибки до того, как продукт попадет в руки пользователя, используя прототипы.
В сочетании с юзабилити тестированием прототипы не дают команде сбиться с верного курса. Вторая вещь, с которой мне часто приходится сталкиваться, это следующая позиция: "Хорошо! Ты говоришь очень правильные слова, но мы не можем нашему заказчику/руководству, который выделяет деньги, сказать - нужно потратить ещё время и ещё денег, т.е. увеличить бюджет и сроки проекта, для того, чтобы включить в проект вас - таких вот чудаков юзабилистов". В корне неверное понимание.
Юзабилити приводит к сокращению времени и к сокращению ресурсов, необходимых для выполнения проекта. Но в таком случае, правда, бывают курьезы. В России очень развит аутсорсинговый бизнес и много хороших программистов работает над западными проектами. Мне тогда говорят project менеджеры: "Ну, вообще-то, в сокращении мы тоже не очень заинтересованы, потому что у нас есть ватага программистов, которых нужно кормить. И если бюджет вдруг сократиться, то чем же они будут заниматься?"
В таком случае у нас появляется конфликт, стратегический, и выходом из него является принятие стратегического решения - что лучше: накормить ватагу программистов или иметь удовлетворенных и лояльных заказчиков, которым за короткое время поставляется качественный продукт, качественное решение? Я думаю, что это особенность России, но бизнесмены, работающие здесь - в России, и следящие за бюджетом, должны быть безусловно заинтересованы в том, чтобы это происходило быстро и качественно. Зачем всё это нужно? Теперь собственно про деньги, я чуть-чуть уже говорил про это.
Цифры, которые вы видите на экране: "1 доллар приносит от 10 до 100 долларов прибыли или сэкономленных средств". У каждого проекта есть скрытые траты, не запланированные в бюджете. Это траты на переделку, затраты на поддержку пользователей, и т.д. Когда определяют бюджет на разработку и ставят сроки, часто не очень понимают, что за этим могут быть траты в два-три раза большие на то, чтобы продукт жил, чтобы адаптировать его к реальному миру. Таким цифрам некоторые из юзабилистов, которых, как сказал Федор, мало, не верят этим цифрам - и это поразительно! Возможно потому, что они работают консультантами и не близки тому бизнесу, для которого они работают. Эти цифры берутся из статистики, но я лично могу подписаться под ними, поскольку я работаю в компании, которая, в том числе, разрабатывает свои проекты.
Позитивный вклад юзабилити: Разработка: Снижение расходов и уменьшение времени; Продажи: Увеличение доходов; Пользователи: Повышение эффективности, продуктивности и удовлетворенности; Снижение затрат на внедрение (за счет сокращения обучения) и на поддержку пользователей. Поскольку доклад был изначально ориентирован для разработческой конференции, для РИТа, здесь представлен слайд, который чуть более детально описывает позитивный вклад юзабилити в разработку, но на этом месте мог бы быть другой слайд - почему это влияет на продажи, и прочее - думаю, нет смысла снова здесь все перечислять.
  Вы, наверное, мне уже верите. Влияние на разработку: Снижение затрат на разработку. Сокращение времени на разработку Снижение расходов на поддержку продукта Сокращение затрат на переделку продукта Заключение первой части. Большинство людей - и это цитата Скотта Беркуна (UI дизайнер из Microsoft, который вырос из юзабилиста в project менеджера). Большинство людей не умеют дарить подарки даже себе. Мы не всегда знаем, как сделать счастливыми себя, не то, что других. Все хорошее в этом мире создается щедрым умом. Если вы творите для других, вы дарите им то, за что они готовы платить".

Только зарегистрированные и авторизованные пользователи могут оставлять комментарии. Авторизуйтесь, пожалуйста.