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

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

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

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

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

16

О месте юзабилити-тестирований

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

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

Вот основные из них. «Юзабилити-тестирование» — это:

  • Отдельная, весьма важная услуга, предлагаемая юзабилити-компаниями и одиночными специалистами;
  • Если не обязательный, то крайне желательный начальный этап ЛЮБОГО проекта по переработке интерфейса;
  • Основной и часто единственный способ гарантировать качество работ по разработке/переработке интерфейса;
  • Максимально достоверный прием для оценки качества интерфейса — как на разных этапах его создания, так и при завершении разработки.

Выскажу свое мнение по каждому утверждению.

Юзабилити-тестирование как отдельная услуга

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

Так вот. Тестирование — это не услуга, это инструмент. «Проектирование интерфейса», например — услуга, «аудит интерфейса» — тоже услуга. В нашем случае, как правило, говоря о «тестировании», имеют в виду именно аудит.

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

  1. Понять, какие требования предъявляются к интерфейсу. Фактически, провести этап исследований. Некоторые «профессионалы», к сожалению, опускают эту часть работы, предлагая «оценить» интерфейс сразу, исходя их эмпирических соображений: «посмотрел — нашел ошибки». Но это ущербный подход. Так можно обнаружить в основном микродизайнерские проблемы (неуклюжую компоновку экранных элементов, неоптимальное использование контролов и т.д.). Оценить же соответствие интерфейса сценариям работы пользователей, контексту, бизнес-требованиям можно, лишь собрав предварительно соответствующие данные. Даже с продуктами, рассчитанными на широкую аудиторию, где, казалось бы, все уже давно ясно «и тебе, и мне», этот этап необходим, пусть и в усеченном виде. Структурированные требования много полезней в работе, нежели общие представления, которые «вертятся» в голове. Что уж говорить об узкоспециализированных продуктах: там без сбора и фиксации требований просто нельзя.
    В качестве инструментов на этом этапе могут применяться интервью, анкетирования, полевые наблюдения, фокус-группы и т.д.
  2. Изучить текущую реализацию интерфейса. Вот здесь наиболее популярным и действенным инструментом и является юзабилити-тестирование. Но при этом также можно (и нужно) использовать и другие инструменты: экспертную оценку, например, или анализ логов. Причем иногда вместе, а иногда – вместо тестирования.
    А само тестирование, если копать дальше, может проводиться с использованием множества разных методик: Observation, Thinking Aloud, Co-Discovery и т.п.
  3. Подготовить отчет с перечнем проблем интерфейса, рекомендациями по их исправлению. Для создания такого отчета необходимы и собранные требования (что на самом деле нужно?), и результаты оценки интерфейса (как оно реализовано?). Отсюда мы сможем сделать вывод, что не так, и к чему нам следует стремиться.
    Отчет может создаваться также с помощью различных инструментов: тут и статистическая обработка информации, и аналитика, и визуализация данных.

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

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

Юзабилити-тестирование как необходимый начальный этап перепроектирования

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

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

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

Юзабилити-тестирование как основная гарантия конечного качества

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

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

Проиллюстрирую идею картинкой:

Цифрами 1-2-3-4 показаны локальные максимумы качества в рамках разных концепций.

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

Весь вопрос лишь в том, как выбрать эту самую, правильную.

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

«Юзабилити-тестирование» — важное, но недостаточное условие качества конечного результата. Лишь полноценный цикл может гарантировать нужный результат. При этом я прекрасно осознаю, что для разных проектов и сам цикл, и важность его этапов может быть разной: где-то, например, критичнее более глубоко исследовать, где-то — тестировать. А где-то (о, ужас!) тестирование практически не даст результатов.

Юзабилити-тестирование как главный способ оценки качества

Здесь я хочу еще раз повторить мысль, высказанную мной в статье «Интуитивная понятность: панацея ли?».

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

Пример: отработка нештатных ситуаций в отраслях с высокой ценой ошибки — атомная энергетика, авиация и т.д.

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

Получается, с помощью юзабилити-тестирования в ходе (или по завершении) работы для оценки нам доступна только часть качеств. А чтобы оценить остальные, необходимо тестировать в процессе не только СОЗДАНИЯ, но и последующего ИСПОЛЬЗОВАНИЯ продукта, причем этот процесс может растянуться на месяцы и годы.

«Юзабилити-тестирование» — прекрасный способ оценки качества интерфейса, но он не всегда объективен.

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

Главное, на что я стремлюсь обратить внимание:

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

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

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

RSS feed for comments on this post | TrackBack URI

1

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

2

Александр,
Конечно, я это осознаю, об этом написано еще в статье про ROI (http://www.gui.ru/platon/?p=14).
Здесь я сознательно не копаю вглубь, иначе статья растянется на целую книгу :)

3

Дмитрий, пора бы уже и книгу! Я думаю меня поддержат все читатели этого блога!

Книгу, книгу, книгу! Даешь книгу по юзабилити-тестированию в Новом Году!

Кстати, с Новым Годом тебя и весь uidesign group! Успехов вам!

4

Александр,
От какого Дмитрия вы так ждете книгу? :)

5

Платон, предновогодняя суета дала о себе знать :) Извините ради бога. Конечно же я имел в виду вас!

Генндий Драгун05.01.2007 17:16
6

Хотелось бы ещё добавить по теме «Веб-юзабилити: экспертиза или тестирование, что эффективнее?» несколько очков в пользу экспертизы.

Ограничения юзабилити-тестирования:
1) Главные минус юзабилити тестирования - его стоимость, время и усилия необходимые для проведения.
Отсюда и многочисленные “дисконтные, партизанские” версии юзабилити-тестирования.

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

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

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

3) Большинство методов юзабилити тестирования направлено на исследование “опыта первого использования системы”. Методики тестирования “опыта длительного пользования” и “тестирования в ‘полевых’ условиях” ещё недостаточно разработаны (об этом пишет и Платон).

4) Юзабилити-тестирование претендует на объективность, но остается весьма субъективным. Очень многое зависит от способностей и опыта тестировщика, особенно в вопросе разпознавания и оценки проблем взаимодействия. Неправильный выбор контекста тестирования даст результаты вводящие в заблуждение.

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

7

Платон, на мой взгляд в целом очень верные замечания, только пока немного запутанно :)

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

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

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

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

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

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

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

Короче, пора свою статью писать :)

Геннадий Драгун08.01.2007 20:46
8

О-оо:
“- Подбор вопросов, которые мы хотим выяснить на тестировании”
Это вообще один из самых запутанных моментов в ю-т. Почти все руководства опускают объяснения по нему как “что-то самособою разумеющееся”, обращая больше внимания методике тестирования, чем постановке целей и задач исследования.

Чем более общий вопрос, тем более широкий круг проблем мы можем выявить.
Чем более конкретный, тем глубже копаем.

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

9

> О-оо:
> “- Подбор вопросов, которые мы хотим выяснить на тестировании”
Стандартный набор: что, где, как, когда, зачем и почему :)))

Дмитрий Сатин16.01.2007 10:40
10

Не совсем понятна мотивация написания этого текста. Хочется напомнить старую статью Скотта Беркуна (проджект менеджера Intrernet Explorer’a в Microsoft и известного usability-специалиста). Статья вроде бы на ту же тему, только выводы другие - http://www.scottberkun.com/essays/essay06.htm

11

Дима,
Мотивация, мне кажется, очевидна: высказать свою точку зрения, и частичное несогласие со сложившимися представлениями. Я часто встречаю мнение, что главное в (любом) проекте - юзабилити-тестирование, а все остальное уже можно “навертеть” вокруг по желанию.
Это все равно, что в автосервисе гайки закручивать: для хорошей работы это 100% необходимо, но никто же не говорит “Главное, что мы делаем - это закручивание гаек”, и как отдельную услугу это никто не продвигает. :) Хотя эта деятельность входит почти во все работы.
Что касается статьи - там, на мой взгляд, выводы те же: юзабилити-тестирование однозначно полезно, но для хорошей работы требуется еще множество других действий.

Филев Дмитрий16.01.2007 20:09
12

Всем привет!
Платон, отличная статья!
Мне кажется, что здесь можно нашу с вами работу сравнить с работой врача. Ведь для того, что бы назначить курс сначала необходимо поставить диагноз! Существуют лаборатории, специализирующиеся на диагностике, выявлении причин недомогания. Юзабилити-тестирование из этой серии. Долг любого специалиста предупредить клиента об опасности самолечения. Но, некоторые проекты имеют своей целью просто диагностику.
Хочу вот еще что отметить, Платон, Алексей, когда вы приедете к нам в гости? Давайте мы покажем, каким образом проводиться современное юзабилити-тестирование. Уверен, многие недоразумения и вопросы отпадут сами собой!

Дмитрий Сатин17.01.2007 02:27
13

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

Мы повторяем все время определение user centered design - подход, базирующийся на активном вовлечении пользователей в процесс разработки. Ценность такого подхода, вроде бы, специалистам очевидна. Но, не имея достаточных ресурсов, времени, сил, денег, технологий, усидчивости, и т.д., “специалисты” зачастую игнорируют важность user study.

Ты пишешь “«юзабилити-тестирование» — весьма «раскрученное» понятие”. Не могу согласиться с этим. Когда мы показываем коллегам, заказчикам, студентам и т.д. тестирование в действии, многие сообщают, что не представляли как это должно происходить, насколько это непросто, и насколько неожиданные проблемы продукта выявляет тестирование. А ты говоришь “гайки”…

Геннадий Драгун19.01.2007 18:24
14

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

Что объективнее: мнение 5 экспертов или 5 случайных пользователей?

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

Экспертиза и тестирование не конкуренты. Они не способны взаимозаменить друг друга. Они должны друг друга взаимодополнять. У каждого из методов - свои сильные и слабые стороны и свое место применения.

15

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

16

[…] Платон Днепровский. О месте юзабилити-тестирований […]

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

Anti-Spam Image