Поиск по сайту:

GUI.ruВзгляд изнутри

Теория и практика юзабилити: опыт показывает

Платон Днепровский
13.03.2006Платон Днепровский

Комментариев:

14

ROI или Где деньги, Зин?

Detrol For Sale Myambutol No Prescription Buy Exelon No Prescription Buy Online Glucophage Buy Nolvadex Online Cardizem For Sale Augmentin No Prescription Buy Plan B No Prescription Buy Online Imitrex Buy Lisinopril Online Lotensin For Sale Hgh No Prescription Buy Phentrimine No Prescription Buy Online Acticin Buy Lopressor Online Ayurslim For Sale Naprosyn No Prescription Buy Azulfidine No Prescription Buy Online Diarex Buy Prograf Online Sumycin For Sale Avodart No Prescription Buy Actos No Prescription Buy Online Glucotrol Buy Xeloda Online

Одним из наиболее обсуждаемых вопросов является рентабельность или ROI (Return on Investment – возврат инвестиций) услуг юзабилити. Почти каждый заказчик задается вопросом: а какую выгоду в количественном выражении принесет мне приглашение юзабилити-экспертов? Насколько увеличится моя прибыль и как скоро, после того, как я потрачусь на интерфейс? И на эти вопросы необходимо отвечать.

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

Рассмотрим подробнее, что, как и когда можно спрогнозировать.

Отметим для начала, что имеется разница, когда интерфейс системы переделывается и когда – разрабатывается «с нуля». В случае редизайна все более-менее понятно: замеряем характеристики «до» и «после», и делаем нужные выводы. В идеале перед началом работы оговаривается, что результат считается успешным, если, например, скорость выполнения сценариев А, Б и В не менее чем на 20% выше, а удельное количество ошибок на 10% ниже, чем в существующей системе. Однако подводных камней и тут хватает.

  • Во-первых, не следует забывать и о корректном определении тех самых критериев, значения которых нам говорят о качестве проделанной работы. Например: для интернет-магазина основным может показаться отношение числа купивших товар к числу зашедших на сайт. Но это не совсем верно: на эту величину, помимо качества интерфейса, сильно влияют и другие факторы. Ведь если владелец сайта неправильно проведет рекламную кампанию и «нагонит» на него незаинтересованных пользователей, они будут сразу же уходить, не покупая товар. И если такая кампания совпадет по времени со стартом новой версии (а обычно так и бывает), это сильно подпортит статистику. Более того – хороший интерфейс в этом случае приведет к более быстрому оттоку «непокупателей» (пользователи сразу будут понимать, что здесь им «ловить» нечего, а не блуждать в тщетных поисках несуществующих товаров). Корректнее будет оценивать соотношение числа купивших товар к числу начавших процесс заказа. И/или числа просмотревших описание товара к числу зашедших по определенному запросу.
  • Во-вторых, получить данные об изменении эффективности после редизайна хотят все, а тратить на это средства готовы отнюдь не многие. Ведь для четкой фиксации значений этих самых характеристик требуется их замерить и на старой версии системы, и на новой. Но если уже принято окончательное решение переделывать систему, то полноценное тестирование старой версии не всегда необходимо для корректной разработки, а значит, вроде бы и тратиться незачем.
    В случае переработки веб-систем можно, например, сделать сравнительный анализ серверных логов «до» и «после» - это хоть и не юзабилити-тестирование, но некоторые тенденции позволяет отследить.
  • В-третьих, до сих пор вообще не всегда есть возможность протестировать систему, старую или новую, как это не прискорбно.
  • В-четвертых, что не совсем очевидно, часто полноценную информацию об эффективности интерфейса можно собрать много позже завершения не только его разработки, но и запуска/внедрения самой системы. Сразу оценить можно лишь «интуитивно понятную» систему (см. мою статью про интуитивную понятность). Но если интерфейс рассчитан на длительное обучение, то и на нужный уровень навыков пользователи могут выйти только через полгода, например. Что толку замерять скорость работы на прототипе, если в реальной жизни нужно учиться и учиться, прежде чем начать полноценно работать с системой?

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

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

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

Подытоживая вышесказанное:

Прописать в договоре на разработку или переработку интерфейса количественные обязательства, касающиеся его качества, практически нереально. Для этого, как минимум, нужно проводить сравнительные исследования, но и это решает проблему лишь в небольшом количестве случаев. Следовательно, подавляющему большинству клиентов придется довериться выбранному юзабилити-подрядчику без «железных» гарантий, потому как их не бывает. На самом деле, такая ситуация характерна не только для нашей дисциплины, очень многие услуги продаются именно так: оговариваются в основном качественные критерии результата. Это справедливо не только для IT, но для рынка услуг вообще. Замеченная среди заказчиков юзабилити-услуг повышенная требовательность – результат неполного доверия к этой дисциплине, и к ее представителям в частности. Что, кстати, схоже с ситуацией на других молодых рынках. Наша задача – повышать это доверие.

А именно:

  • Правильно и красочно объяснять, почему вообще следует обращать внимание на пользовательские характеристики продукта, и почему стоит выделять на это ресурсы.
  • Что касается ROI – оперировать общедоступной статистикой на эту тему, хотя конкретно для данной пары заказчик-подрядчик эти цифры ничего не гарантируют. Такую статистику можно найти в Интернете, например, у того же Нильсена в Алертбоксе (подробные данные содержатся в платных отчетах, которые NNG продает по ~150-250$).
  • Самое эффективное средство – оперировать собственной накопленной статистикой, и, по возможности, проводить параллели между прошлыми проектами и обсуждаемым сейчас. Это значительно повышает доверие заказчика к конкретному подрядчику. Поэтому старайтесь всегда (если есть возможность) замерять эффективность своей работы, даже если этого не требует клиент в данном проекте. Помимо того, что это просто необходимо для корректного выполнения работы, эти цифры в дальнейшем не раз помогут вам. А там, глядишь, и приторговывать ими можно будет, чем мы хуже Нильсена :) .

Публикнуть: Добавить на News2.ru Добавить на Newsland.ru Добавить на Хабрахабр Добавить на Moikrug Заложить: Забобрить эту страницу! Добавить на Memori.ru Добавить на Delicious

Комментарии (14)

RSS feed for comments on this post | TrackBack URI

PM13.03.2006 15:45
1

В разделе “а именно” явно не хватает пункта о том, что нужно создавать и продвигать success stories.

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

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

Также хочется задать вопрос – есть какие-нибудь данные о том, какой процент бюджета нужно выделять на ПИ/юзабилити?

По другим составляющим проекта такие данные есть. Например, на управление – порядка 10-15%, на обеспечение качества – 15-20%, на требования – около 20%, на риски – чем больше тем лучше и т.д. (естественно данные разняться у разных авторов, для разных типов ПО, но есть МНОГО исследований на этот счет, сослаться всегда есть на что).

2

В разделе “А именно” этот пункт - 3-й :)
Там как раз и говорится о том, что необходимо на собственных данных иллюстрировать.

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

В “тяжелых” приложениях не так, конечно. Здесь в среднем 10-20%, на мой взгляд. Конечно, я не имею в виду совсем “дохлые” проекты, где вся работа заключаеися в лихорадочном “причесывании” готовой системы в последний месяц.

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

PM14.03.2006 11:15
3

Гм…

То ли не заметил, то ли третий пункт был дописан позже.
Но в любом случае, а почему он тогда третий, раз “самое эффективное”?

4

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

PM16.03.2006 10:15
5

Проблема реально есть. “Слишкаммногабуква” проблема не только “падонков”, но и просто сильно занятых людей (руководителей, например).

Что стоило главный вывод статьи выделить визуально от остального текста? Вы же, юзабилисты, сами везде кричите, что в интернете люди не читают, а просматривают инфу…

krbltik22.03.2006 18:32
6

Хмм, странно, а что разве методика GOMS (глава “Квантификация” в книге Джефа Раскина) не может быть одним из критериев оценки эффективности интерфейса ? Количество щелчков мышью и нажатий клавиш всегда можно подсчитать))

7

krbltik,

Конечно может. Но как это расходится с оговоренными тезисами?

Чтобы до _переработки_ интерфейса зафиксировать требования в формате GOMS - надо их специально измерить, об этом написано.

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

Разве не так?

krbltik22.03.2006 21:01
8

Платон Днепровский ,
Почему же нельзя написать оценки скорости работы с ещё несуществующей системой ? На мой взгляд это как раз проще чем с редизайном. Если уж заказчик решил потратиться на юзабилити так разве нельзя привести в качестве аргумента что с новым продуктом скорость работаты возрастёт раз 3-5 чем у конкурентов ? И в конце концов, если уж заказчик к вам пришёл это уже что то значит))
Понятно, что другие параметры, такие как эффективность восприятия информации сложно оценить количественно, ну так в этом случае и должен прийти на помощь опыт специалиста по юзабилити, как заметил автор в статье))

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

9

krbltik,

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

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

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

krbltik23.03.2006 14:30
10

Платон Днепровский ,

Хорошо, с новыми системами разобрались))

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

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

11

krbltik,

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

12

[…] ачество работы. Как я уже упоминал ранее в статье про ROI, гарантировать качество результата (настоящего […]

13

[…] вопрос о необходимости инвестиций занимаются как российские так и зарубежные […]

14

[…] вопрос о необходимости инвестиций занимаются как российские так и зарубежные […]

Оставить комментарий

Anti-Spam Image